ZF2 modules tutorial (with screenshots!)

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

ZF2 modules tutorial (with screenshots!)

EvanDotPro
Hi all,

I decided to put together a little tutorial on modules in their
current incarnation to help illustrate various use-cases and give
people a starting point for trying out different ideas for things like
module installation, etc. If you're interested in getting a better
grasp of where we stand on modules today, you may find this helpful!

The tutorial, complete with screenshots, walks you through setting up
a working copy of my zf2-sandbox repository and installing the user
authentication & registration module I wrote this weekend.
Additionally, it covers installing Matthew's Guestbook module. By the
end of the tutorial, you'll have a functional site with a guestbook
and user registration/authentication, having only modified a couple of
config files.

If you have a few minutes, please run through the tutorial and let me
know if you run into any snags or spot any steps that are unclear,
etc.

https://github.com/EvanDotPro/zf2-sandbox/blob/master/docs/module-tutorial.md

Enjoy!

---
Evan Coury
http://blog.evan.pro/

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

weierophinney
Administrator
-- Evan Coury <[hidden email]> wrote
(on Sunday, 11 September 2011, 10:47 AM -0700):

> I decided to put together a little tutorial on modules in their
> current incarnation to help illustrate various use-cases and give
> people a starting point for trying out different ideas for things like
> module installation, etc. If you're interested in getting a better
> grasp of where we stand on modules today, you may find this helpful!
>
> The tutorial, complete with screenshots, walks you through setting up
> a working copy of my zf2-sandbox repository and installing the user
> authentication & registration module I wrote this weekend.
> Additionally, it covers installing Matthew's Guestbook module. By the
> end of the tutorial, you'll have a functional site with a guestbook
> and user registration/authentication, having only modified a couple of
> config files.
>
> If you have a few minutes, please run through the tutorial and let me
> know if you run into any snags or spot any steps that are unclear,
> etc.
>
> https://github.com/EvanDotPro/zf2-sandbox/blob/master/docs/module-tutorial.md

Wow -- it "just worked"!

Actually, not entirely, but mostly! The two issues I had were:

 * Guestbook currently uses a SQLite database. As such, you need to
   ensure its data/ subdir is rwX for all users.
 * I had a configuration issue with the User mysql database, and simply
   got a 500 error... which leads me to a new point:

We likely need some sort of exception and/or error handler around the
call to $controller->dispatch() in the Application class. This way, we
can provide an error page to users -- which will also aid in debugging
(the only reason I was able to track down the above two errors was based
on an educated guess).

Other things we may want to think about:

 * While I see you have the modules setting up their own autoloading,
   one thing to consider is that if they are using a ClassMapAutoloader
   strategy, we may want to merge the map with an existing one --
   instead of registering an additional autoloader. Alternately, that
   may be a task for an installer (creating a merged classmap).

 * Like Paddy, I wonder about the merged configuration, and being able
   to override. I honestly think the best solution would likely be to
   have an application-level config file in which import statements to
   module configs are placed. This would then allow overriding
   module-specific configuration in the application level, essentially
   allowing us to leave git submodules pristine.

   As an example:

    <?xml version="1.0"?>
    <config>
        <production>
            <import name="modules/Application/configs/application.config.php" />
            <import name="modules/User/configs/user.config.php" />
            <import name="modules/Guestbook/configs/guestbook.config.php" />

            <routes>
                <guestbook>
                    <type>Zf2Mvc\\Router\\Http\\LiteralRoute</type>
                    <options>
                        <route>/guestbook</route>
                        <defaults>
                            <controller>controller-guestbook</controller>
                            <action>index</action>
                        </defaults>
                    </options>
                </guestbook>
            </routes>
        </production>
        <development extends="production">
    </config>

   If possible, it'd be awesome if we could mix and match config types
   using imports (as I've done above). The above would import the named
   configuration, merging each into the object. Any configuration
   following imports would then be merged -- basically allowing for
   local overrides.

   Alternately, we could have a "module" directive that would grab
   configuration from the module at runtime.

All this said, it doesn't solve the problem of large configuration -
we'd still end up with a large configuration object in the end. So, we
may want to start thinking on how we could do optimistic configuration -
i.e., only loading configuration for the requested module. If anybody
has ideas, I'd love to hear them!
   
--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

padraicb
> All this said, it doesn't solve the problem of large configuration -
> we'd still end up with a large configuration object in the end. So, we
> may want to start thinking on how we could do optimistic configuration -
> i.e., only loading configuration for the requested module. If anybody
> has ideas, I'd love to hear them!

Optimistic loading would be the best strategy:

1. Create configuration objects per Module merged to, I suppose, the Application/Global config

2. Map inter-Module dependencies

I'm assuming the config cache is manually rebuilt whenever a base configuration file is edited.

3. Cache per Module (all merged configs for current/dependency Modules + Application)

4. Ensure there's a task available to quickly assess whether a cache is out of sync
5. Profit or go bust trying?

Paddy

 
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

Benoît Durand
In reply to this post by weierophinney
Le 12 sept. 11 à 16:28, Matthew Weier O'Phinney a écrit :

> Actually, not entirely, but mostly! The two issues I had were:
>
> * Guestbook currently uses a SQLite database. As such, you need to
>   ensure its data/ subdir is rwX for all users.
Install script with php or phing? It seems that git is able to manage  
the write permission for a file.

> * I had a configuration issue with the User mysql database, and simply
>   got a 500 error... which leads me to a new point:
>
> We likely need some sort of exception and/or error handler around the
> call to $controller->dispatch() in the Application class. This way, we
> can provide an error page to users -- which will also aid in debugging
> (the only reason I was able to track down the above two errors was  
> based
> on an educated guess).
It seems logical that the code 500 is redirected to an error page as  
the code 404. I want to have a more detailed error page to help  
understand the error.

>   As an example:
>
>    <?xml version="1.0"?>
>    <config>
>        <production>
>            <import name="modules/Application/configs/
> application.config.php" />
>            <import name="modules/User/configs/user.config.php" />
>            <import name="modules/Guestbook/configs/
> guestbook.config.php" />
>
>            <routes>
>                <guestbook>
>                    <type>Zf2Mvc\\Router\\Http\\LiteralRoute</type>
>                    <options>
>                        <route>/guestbook</route>
>                        <defaults>
>                            <controller>controller-guestbook</
> controller>
>                            <action>index</action>
>                        </defaults>
>                    </options>
>                </guestbook>
>            </routes>
>        </production>
>        <development extends="production">
>    </config>
I hope that all configuration files (yaml, xml and ini) have a cache  
or dump an array for performance in the production environment.

> All this said, it doesn't solve the problem of large configuration -
> we'd still end up with a large configuration object in the end. So, we
> may want to start thinking on how we could do optimistic  
> configuration -
> i.e., only loading configuration for the requested module. If anybody
> has ideas, I'd love to hear them!
Prefix config by module name?

--
Benoît Durand


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

Gregory
In reply to this post by weierophinney
> All this said, it doesn't solve the problem of large configuration -
> we'd still end up with a large configuration object in the end. So, we
> may want to start thinking on how we could do optimistic configuration -

This is were things are getting gray for me. In trying to sub-divide
the ZF2 library into modules, and then having to rebuild them via
configuration, just seems somewhat cumbersome and not without
introducing new issues? I think namely it might be in regard to the
autoloader and the module locations, i.e. will some modules be
extracted and placed into a central namespaced directory so as not to
have to have a multitude of namespace autoloader configurations?

> i.e., only loading configuration for the requested module.

And if the requested (assuming non-http request) module is a core
aspect (or component) of the application project, that wouldn't sound
appealing for base/core modules?



--
Greg

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

Sascha-Oliver Prolic
In reply to this post by EvanDotPro
Hi,

first of all, GREAT WORK!

I will need some more time to take a closer look at the prototype, but
one point that stepped to my eye was the used namespaces: Zf2Mvc and
Zf2Module.

Wouldn't be ZendModules\Mvc and ZendModules\Module be a better name?
For me, I expect everything coming from Zend Framework being in a Zend
Namespace (or ZendTest and in this case ZendModules), instead of:
"everything prefixed with Zf2 comes from Zend Framework" (Zf2Mvc,
Zf2Module, Zf2NextGoodIdea, ...).

On the other hand: Currently I don't see enough reasons for MVC and
Module being a module and nore library component. All information I
got, is that Matthew spoke with Rob Allen and they thought it was a
good idea. Can't find any details about pros and cons, so perhabs
someone can elaborate that a bit.

Best Regards

Sascha-Oliver Prolic


2011/9/11 Evan Coury <[hidden email]>:

> Hi all,
>
> I decided to put together a little tutorial on modules in their
> current incarnation to help illustrate various use-cases and give
> people a starting point for trying out different ideas for things like
> module installation, etc. If you're interested in getting a better
> grasp of where we stand on modules today, you may find this helpful!
>
> The tutorial, complete with screenshots, walks you through setting up
> a working copy of my zf2-sandbox repository and installing the user
> authentication & registration module I wrote this weekend.
> Additionally, it covers installing Matthew's Guestbook module. By the
> end of the tutorial, you'll have a functional site with a guestbook
> and user registration/authentication, having only modified a couple of
> config files.
>
> If you have a few minutes, please run through the tutorial and let me
> know if you run into any snags or spot any steps that are unclear,
> etc.
>
> https://github.com/EvanDotPro/zf2-sandbox/blob/master/docs/module-tutorial.md
>
> Enjoy!
>
> ---
> Evan Coury
> http://blog.evan.pro/
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

EvanDotPro
On Mon, Sep 12, 2011 at 11:51 AM, Sascha-Oliver Prolic
<[hidden email]> wrote:
> Wouldn't be ZendModules\Mvc and ZendModules\Module be a better name?
> For me, I expect everything coming from Zend Framework being in a Zend
> Namespace (or ZendTest and in this case ZendModules), instead of:
> "everything prefixed with Zf2 comes from Zend Framework" (Zf2Mvc,
> Zf2Module, Zf2NextGoodIdea, ...).

As far as I understand it, Matthew only demonstrated the MVC prototype
as a module to help show off some of the ideas in the modules RFC, not
because that's how it will ultimately be distributed. This holds true
for my Zf2Module 'module' as well. Both of these will most likely
ultimately live under the Zend namespace.

To quote Matthew from an earlier thread:

> The usage of a module was as much an idea to prototype as the MVC was
> itself. The main things it enabled for me were as follows:
>
>  * Ease of testing and prototyping. I could include only the exact new
>   code I wanted to try out, and test it separately from the ZF2 library
>   itself.
>
>  * Enabled me to show off how one could build an MVC using the "building
>   blocks" provided in the ZF2 library. This could serve as a blueprint
>   for others with specific needs that lie outside what we deliver.
>
>  * Provide documentation specific to a suite of functionality, rather
>   than individual components.
>
> The format is not unlike what is being discussed with the modules RFC:
> http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+ZF2+Modules -- and,
> in point of fact, I chose the format for the prototype based on a
> discussion I was having with Rob Allen last week -- we felt it might
> help show off some of the ideas surrounding the RFC in a more concrete
> way.
>
> All this said, I'm not necessarily advocating components as modules --
> I'm simply prototyping two ideas:
>
>  * A potential MVC that could exist parallel to the ZF1-style
>   implementation currently in the core, and
>
>  * A potential layout for a module, one that contains primarily library
>   code.

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

Sascha-Oliver Prolic
Hi Evan,

thanks for your explanation.

Best Regards

Sascha-Oliver Prolic

2011/9/12 Evan Coury <[hidden email]>:

> On Mon, Sep 12, 2011 at 11:51 AM, Sascha-Oliver Prolic
> <[hidden email]> wrote:
>> Wouldn't be ZendModules\Mvc and ZendModules\Module be a better name?
>> For me, I expect everything coming from Zend Framework being in a Zend
>> Namespace (or ZendTest and in this case ZendModules), instead of:
>> "everything prefixed with Zf2 comes from Zend Framework" (Zf2Mvc,
>> Zf2Module, Zf2NextGoodIdea, ...).
>
> As far as I understand it, Matthew only demonstrated the MVC prototype
> as a module to help show off some of the ideas in the modules RFC, not
> because that's how it will ultimately be distributed. This holds true
> for my Zf2Module 'module' as well. Both of these will most likely
> ultimately live under the Zend namespace.
>
> To quote Matthew from an earlier thread:
>> The usage of a module was as much an idea to prototype as the MVC was
>> itself. The main things it enabled for me were as follows:
>>
>>  * Ease of testing and prototyping. I could include only the exact new
>>   code I wanted to try out, and test it separately from the ZF2 library
>>   itself.
>>
>>  * Enabled me to show off how one could build an MVC using the "building
>>   blocks" provided in the ZF2 library. This could serve as a blueprint
>>   for others with specific needs that lie outside what we deliver.
>>
>>  * Provide documentation specific to a suite of functionality, rather
>>   than individual components.
>>
>> The format is not unlike what is being discussed with the modules RFC:
>> http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+ZF2+Modules -- and,
>> in point of fact, I chose the format for the prototype based on a
>> discussion I was having with Rob Allen last week -- we felt it might
>> help show off some of the ideas surrounding the RFC in a more concrete
>> way.
>>
>> All this said, I'm not necessarily advocating components as modules --
>> I'm simply prototyping two ideas:
>>
>>  * A potential MVC that could exist parallel to the ZF1-style
>>   implementation currently in the core, and
>>
>>  * A potential layout for a module, one that contains primarily library
>>   code.
>
> --
> Evan Coury
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

EvanDotPro
In reply to this post by weierophinney
On Mon, Sep 12, 2011 at 7:28 AM, Matthew Weier O'Phinney
<[hidden email]> wrote:

>  * Like Paddy, I wonder about the merged configuration, and being able
>   to override. I honestly think the best solution would likely be to
>   have an application-level config file in which import statements to
>   module configs are placed. This would then allow overriding
>   module-specific configuration in the application level, essentially
>   allowing us to leave git submodules pristine.
>
>   As an example:
>
>    <?xml version="1.0"?>
>    <config>
>        <production>
>            <import name="modules/Application/configs/application.config.php" />
>            <import name="modules/User/configs/user.config.php" />
>            <import name="modules/Guestbook/configs/guestbook.config.php" />
>
>            <routes>
>                <guestbook>
>                    <type>Zf2Mvc\\Router\\Http\\LiteralRoute</type>
>                    <options>
>                        <route>/guestbook</route>
>                        <defaults>
>                            <controller>controller-guestbook</controller>
>                            <action>index</action>
>                        </defaults>
>                    </options>
>                </guestbook>
>            </routes>
>        </production>
>        <development extends="production">
>    </config>
>
>   If possible, it'd be awesome if we could mix and match config types
>   using imports (as I've done above). The above would import the named
>   configuration, merging each into the object. Any configuration
>   following imports would then be merged -- basically allowing for
>   local overrides.

I think this would be a very useful feature, regardless of the
direction we got with modules. I may hack on Zend\Config and see if I
can put something together for this. I've looked over ZF2-5, but I'm
not sure if the adapter specific method is the best approach there.

>   Alternately, we could have a "module" directive that would grab
>   configuration from the module at runtime.

What I like about this approach is that the config doesn't have to
statically point to the paths to each module's config files (which may
be installed locally, globally, etc); loading the config can be simply
by module name, which keeps thing a bit more flexible all around.
There should be a way to retain this, and still allow application
level overrides. Currently, if you just made your main 'Application'
module the last one in the list, you'd essentially have that, but it's
not by design at the moment.

> All this said, it doesn't solve the problem of large configuration -
> we'd still end up with a large configuration object in the end. So, we
> may want to start thinking on how we could do optimistic configuration -
> i.e., only loading configuration for the requested module. If anybody
> has ideas, I'd love to hear them!

I thought about this quite a bit and it's a challenging issue to say
the least. For this to work, the system needs an intricate
understanding of what modules are required to dispatch a request
(http/cli/etc); and unfortunately that can be completely dynamic and
is not necessarily 1:1. The only thing I can think of is somehow
having modules themselves work within a sort of DI container
themselves, which just knows _of_ the modules, but doesn't actually
load them or their config until they're called via a 'get()' or
something along those lines. The idea is too abstract for me to even
begin trying to implement something like that. However that seems like
a bad idea to me, and I'm not confident it'll actually work in
practice, or be worth the complication even if it were possible.

If performance of the deserialization / merging process is the concern
here, caching the merged config is simple enough. Same goes for
autoloaders. Is there any reason we can't have a method for
creating/using a single master classmap recommended for production,
with the slower runtime resolving being used for convenience in
development?

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

EvanDotPro
In reply to this post by Benoît Durand
2011/9/12 Benoît Durand <[hidden email]>:
> It seems logical that the code 500 is redirected to an error page as the
> code 404. I want to have a more detailed error page to help understand the
> error.

 Perhaps a debug module with a really nice 500 page with super clean
 exception / stack trace dumping like Symfony? Just an idea... Could
 have other things in such a module such as a floating profiler, etc.

 --
 Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

weierophinney
Administrator
In reply to this post by Gregory
-- Greg <[hidden email]> wrote
(on Monday, 12 September 2011, 01:17 PM -0500):

> > All this said, it doesn't solve the problem of large configuration -
> > we'd still end up with a large configuration object in the end. So, we
> > may want to start thinking on how we could do optimistic configuration -
>
> This is were things are getting gray for me. In trying to sub-divide
> the ZF2 library into modules, and then having to rebuild them via
> configuration, just seems somewhat cumbersome and not without
> introducing new issues? I think namely it might be in regard to the
> autoloader and the module locations, i.e. will some modules be
> extracted and placed into a central namespaced directory so as not to
> have to have a multitude of namespace autoloader configurations?

Extracting into modules will only be for code you intend to re-use, or
code you are re-using from others. As examples:

 * Evan's "User" module, which handles authentication. (This could be
   the start of a "Security" module, which provides event listeners that
   compose the authentication identity and an ACL, and which do tests
   against requested actions to see if the user has access.)
 * Drop-in modules like a "blog" module, or a "news" module, or a
   "forums" module, etc.

I would expect most sites would likely compose one or two modules, and
have one "main" module that composes the majority of the site
functionality. As such, the whole need for optimistic configuration may
be a moot point.

However, for larger projects, where you may have many teams working on
parallel features, modules may also be another good fit -- and this is
where the problem may crop up. However, those same sites likely would
have issues under ZF1 as well -- with complexity and size usually come
performance issues as well. It's good for us to keep these issues in
mind, but we shouldn't choose _not_ to explore a given path only because
of them.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

weierophinney
Administrator
In reply to this post by EvanDotPro
-- Evan Coury <[hidden email]> wrote
(on Monday, 12 September 2011, 02:15 PM -0700):

> On Mon, Sep 12, 2011 at 7:28 AM, Matthew Weier O'Phinney
> <[hidden email]> wrote:
> >  * Like Paddy, I wonder about the merged configuration, and being able
> >   to override. I honestly think the best solution would likely be to
> >   have an application-level config file in which import statements to
> >   module configs are placed. This would then allow overriding
> >   module-specific configuration in the application level, essentially
> >   allowing us to leave git submodules pristine.
> >
> >   As an example:
> >
> >    <?xml version="1.0"?>
> >    <config>
> >        <production>
> >            <import name="modules/Application/configs/application.config.php" />
> >            <import name="modules/User/configs/user.config.php" />
> >            <import name="modules/Guestbook/configs/guestbook.config.php" />
> >
> >            <routes>

<snip>

> >
> >   If possible, it'd be awesome if we could mix and match config types
> >   using imports (as I've done above). The above would import the named
> >   configuration, merging each into the object. Any configuration
> >   following imports would then be merged -- basically allowing for
> >   local overrides.
>
> I think this would be a very useful feature, regardless of the
> direction we got with modules. I may hack on Zend\Config and see if I
> can put something together for this. I've looked over ZF2-5, but I'm
> not sure if the adapter specific method is the best approach there.

I think there needs to be support per-adapter (as the syntax is going to
be per-adapter), but that each one, as it detects an import, would pass
the argument to a factory. This allows us to mix-and-match types.

When the full configuration is discovered, it should then cache it as a
straight PHP configuration, and use the mtime of the original _master_
configuration file as the indicator of when to re-parse. In production,
this setting could be overridden, effectively telling it to never check
for changes and only use the cached variant. (On the flip-side, in
development, we could tell it to _never_ check for a cache hit.)

> >   Alternately, we could have a "module" directive that would grab
> >   configuration from the module at runtime.
>
> What I like about this approach is that the config doesn't have to
> statically point to the paths to each module's config files (which may
> be installed locally, globally, etc); loading the config can be simply
> by module name, which keeps thing a bit more flexible all around.
> There should be a way to retain this, and still allow application
> level overrides.

I would argue it would work exactly like imports -- it's just that the
source of the configuration would be the module's metadata class.
If we get back a Config object, we merge it, if we get back an array, we
merge that. Again, once all imports are complete, we then continue
processing the configuration, which allows for overriding.

> Currently, if you just made your main 'Application' module the last
> one in the list, you'd essentially have that, but it's not by design
> at the moment.

I'm not quite sure I get your point here...

> > All this said, it doesn't solve the problem of large configuration -
> > we'd still end up with a large configuration object in the end. So, we
> > may want to start thinking on how we could do optimistic configuration -
> > i.e., only loading configuration for the requested module. If anybody
> > has ideas, I'd love to hear them!
>
> I thought about this quite a bit and it's a challenging issue to say
> the least. For this to work, the system needs an intricate
> understanding of what modules are required to dispatch a request
> (http/cli/etc); and unfortunately that can be completely dynamic and
> is not necessarily 1:1. The only thing I can think of is somehow
> having modules themselves work within a sort of DI container
> themselves, which just knows _of_ the modules, but doesn't actually
> load them or their config until they're called via a 'get()' or
> something along those lines. The idea is too abstract for me to even
> begin trying to implement something like that. However that seems like
> a bad idea to me, and I'm not confident it'll actually work in
> practice, or be worth the complication even if it were possible.

It may not even be an issue. It's something for us to consider if we see
performance degradations with larger projects. I'd argue at this point
that it goes on the back-burner, with config imports/module-specific
config being a priority for now.

> If performance of the deserialization / merging process is the concern
> here, caching the merged config is simple enough.

Exactly.

> Same goes for autoloaders. Is there any reason we can't have a method
> for creating/using a single master classmap recommended for
> production, with the slower runtime resolving being used for
> convenience in development?

This can definitely be done -- create a dummy classmap file returning an
empty array, and seed the autoloader factory with that first. The bigger
question is how we create the classmap, and how we tell the modules to
stop attaching autoloaders to spl_autoload (though that may not be a
huge issue, considering that a master classmap registered first will
return a positive lookup first, too).

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

EvanDotPro
On Mon, Sep 12, 2011 at 8:20 PM, Matthew Weier O'Phinney
<[hidden email]> wrote:
> When the full configuration is discovered, it should then cache it as a
> straight PHP configuration, and use the mtime of the original _master_
> configuration file as the indicator of when to re-parse. In production,
> this setting could be overridden, effectively telling it to never check
> for changes and only use the cached variant. (On the flip-side, in
> development, we could tell it to _never_ check for a cache hit.)

One interesting note about caching config objects that I just discovered:

Due to the recursive nature of Zend\Config\Config, a lot of time is
actually spent on the Config object's __construct() (and in the module
manager's case, merge()). While caching to a PHP file (I'm assuming
you meant an array), would eliminate the need to "parse" the config
file (xml, ini, yml, etc), it's still going to have to spend all of
that time recursively re-building the Config objects. I did a very
unscientific benchmark really quickly, where I simply ran my
zf2-sandbox project normally, and then again with
loading/unserializing a serialized copy of the merged config object:

Normal merging of configs via Module->getConfig():
480 different functions called in 76 milliseconds

Loading Config from a pre-merged, serialized Config:
465 different functions called in 48 milliseconds

I'll be the first to admit that It's not fairest of benchmarks, but in
general, there seems to be a pretty low threshold where $config =
unserialize(file_get_contents('foo')) starts to outperform $config =
new Zend\Config\Config(array(...));

So my question: is caching the merged config as the serialized
Zend\Config\Config object a viable option, rather than storing the
array, then re-converting it back to a Zend\Config\Config? Or is there
any reason we _wouldn't_ want to do that?

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

weierophinney
Administrator
-- Evan Coury <[hidden email]> wrote
(on Tuesday, 13 September 2011, 02:29 PM -0700):

> On Mon, Sep 12, 2011 at 8:20 PM, Matthew Weier O'Phinney
> <[hidden email]> wrote:
> > When the full configuration is discovered, it should then cache it as a
> > straight PHP configuration, and use the mtime of the original _master_
> > configuration file as the indicator of when to re-parse. In production,
> > this setting could be overridden, effectively telling it to never check
> > for changes and only use the cached variant. (On the flip-side, in
> > development, we could tell it to _never_ check for a cache hit.)
>
> One interesting note about caching config objects that I just discovered:
>
> Due to the recursive nature of Zend\Config\Config, a lot of time is
> actually spent on the Config object's __construct() (and in the module
> manager's case, merge()). While caching to a PHP file (I'm assuming
> you meant an array), would eliminate the need to "parse" the config
> file (xml, ini, yml, etc), it's still going to have to spend all of
> that time recursively re-building the Config objects. I did a very
> unscientific benchmark really quickly, where I simply ran my
> zf2-sandbox project normally, and then again with
> loading/unserializing a serialized copy of the merged config object:
>
> Normal merging of configs via Module->getConfig():
> 480 different functions called in 76 milliseconds
>
> Loading Config from a pre-merged, serialized Config:
> 465 different functions called in 48 milliseconds
>
> I'll be the first to admit that It's not fairest of benchmarks, but in
> general, there seems to be a pretty low threshold where $config =
> unserialize(file_get_contents('foo')) starts to outperform $config =
> new Zend\Config\Config(array(...));
>
> So my question: is caching the merged config as the serialized
> Zend\Config\Config object a viable option, rather than storing the
> array, then re-converting it back to a Zend\Config\Config? Or is there
> any reason we _wouldn't_ want to do that?

So, above, you have:

 * Merging of configs via Module->getConfig()
 * Loading config from a pre-merged, serialized Config

What about the case of:

 * Instantiating a Config object from a PHP array

What I'm getting at is:

    // Create a file returning a config...
    // $config is the merged Config from Module->getConfig()
    $content = "<?php\n\return " . var_export($config->toArray(), 1) . ";";
    file_put_contents($cacheFile, $content);

    // Deserialization is:
    $array = include $cacheFile;
    $config = new Config($array);

    // or:
    $config = new Config($array[APPLICATION_ENV]);

How does this compare to the other two?

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

EvanDotPro
On Tue, Sep 13, 2011 at 2:47 PM, Matthew Weier O'Phinney
<[hidden email]> wrote:

> So, above, you have:
>
>  * Merging of configs via Module->getConfig()
>  * Loading config from a pre-merged, serialized Config
>
> What about the case of:
>
>  * Instantiating a Config object from a PHP array
>
> What I'm getting at is:
>
>    // Create a file returning a config...
>    // $config is the merged Config from Module->getConfig()
>    $content = "<?php\n\return " . var_export($config->toArray(), 1) . ";";
>    file_put_contents($cacheFile, $content);
>
>    // Deserialization is:
>    $array = include $cacheFile;
>    $config = new Config($array);
>
>    // or:
>    $config = new Config($array[APPLICATION_ENV]);
>
> How does this compare to the other two?

Alright, I'm on a different computer now, so I'm running all of the
benchmarks again. I'll try to make it a little more scientific this
time:

PHP 5.3.8
nginx/1.0.5 + php-fpm on Fedora 15
HP TouchSmart tm2 i5 w/ 8gb ram
Stats collected with xdebug and webgrind.

This is using my zf2-sandbox project as it stands at the end of the
tutorial I posted over the weekend with the Application, Sample, User,
and Guestbook modules installed.

* $config = $modules->getMergedConfig(); (control)
  0) 478 different functions called in 92 milliseconds
  1) 478 different functions called in 92 milliseconds
  2) 478 different functions called in 99 milliseconds
  3) 478 different functions called in 95 milliseconds
  4) 478 different functions called in 100 milliseconds
  5) 478 different functions called in 96 milliseconds
  6) 478 different functions called in 93 milliseconds
  7) 478 different functions called in 98 milliseconds
  8) 478 different functions called in 96 milliseconds
  9) 478 different functions called in 97 milliseconds

>1ms calls:
  Zend\Loader\StandardAutoloader->loadClass ~22ms (74 invocations)
  Zend\Config\Config->__construct ~14ms (365 invocations, geeze)
  Zend\Config\Config->merge ~7ms (36 invocations)
  Zend\Loader\ClassMapAutoloader->autoload ~5ms (108 invocations)
  Zend\Di\Definition\RuntimeDefinition->getInjectionMethods ~3ms (22
invocations)
  Zend\Config\Config->toArray ~3ms (265 invocations)
  Zend\Loader\StandardAutoloader->autoload  ~3ms (83 invocations)


* $config = unserialize(file_get_contents('config.cache'));
  0) 465 different functions called in 78 milliseconds
  1) 465 different functions called in 72 milliseconds
  2) 465 different functions called in 64 milliseconds
  3) 465 different functions called in 65 milliseconds
  4) 465 different functions called in 61 milliseconds
  5) 465 different functions called in 67 milliseconds
  6) 465 different functions called in 65 milliseconds
  7) 465 different functions called in 64 milliseconds
  8) 465 different functions called in 62 milliseconds
  9) 465 different functions called in 63 milliseconds

>1ms calls:
  Zend\Loader\StandardAutoloader->loadClass ~24ms (74 invocations)
  Zend\Loader\ClassMapAutoloader->autoload ~5ms (108 invocations)
  Zend\Loader\StandardAutoloader->autoload ~3ms (83 invocations)
  Zend\Di\Definition\RuntimeDefinition->getInjectionMethods ~3ms (22
invocations)


* $config = new \Zend\Config\Config(include 'config.php');
  0) 464 different functions called in 68 milliseconds
  1) 464 different functions called in 72 milliseconds
  2) 464 different functions called in 74 milliseconds
  3) 464 different functions called in 66 milliseconds
  4) 464 different functions called in 72 milliseconds
  5) 464 different functions called in 69 milliseconds
  6) 464 different functions called in 71 milliseconds
  7) 464 different functions called in 63 milliseconds
  8) 464 different functions called in 65 milliseconds
  9) 464 different functions called in 64 milliseconds

>1 ms calls:
  Zend\Loader\StandardAutoloader->loadClass ~22ms (74 invocations)
  Zend\Loader\ClassMapAutoloader->autoload ~5ms (108 invocations)
  Zend\Di\Definition\RuntimeDefinition->getInjectionMethods ~3ms (22
invocations)
  Zend\Loader\StandardAutoloader->autoload ~3ms (83 invocations)
  Zend\Config\Config->__construct ~2ms (42 invocations)

Long story short, it looks like the difference between the caching
methods is negligible at best. Forget I said anything. :)

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

weierophinney
Administrator
-- Evan Coury <[hidden email]> wrote
(on Tuesday, 13 September 2011, 06:17 PM -0700):

> On Tue, Sep 13, 2011 at 2:47 PM, Matthew Weier O'Phinney
> <[hidden email]> wrote:
> > So, above, you have:
> >
> >  * Merging of configs via Module->getConfig()
> >  * Loading config from a pre-merged, serialized Config
> >
> > What about the case of:
> >
> >  * Instantiating a Config object from a PHP array
> >
> > What I'm getting at is:
> >
> >    // Create a file returning a config...
> >    // $config is the merged Config from Module->getConfig()
> >    $content = "<?php\n\return " . var_export($config->toArray(), 1) . ";";
> >    file_put_contents($cacheFile, $content);
> >
> >    // Deserialization is:
> >    $array = include $cacheFile;
> >    $config = new Config($array);
> >
> >    // or:
> >    $config = new Config($array[APPLICATION_ENV]);
> >
> > How does this compare to the other two?

<snip - benchmarks>

So, what I'm seeing here is:

 * Merging configs at the modules level is slowest (avg ~95ms)
 * Using serialize/unserialize is faster (avg ~66ms)
 * Instantiating Config from a cached, merged array is faster
   (avg ~66ms)

In both cases, the "caching" solution is around 30% faster, which
definitely is a worthwhile increase. Clearly, serialize/unserialize is
the _simplest_ solution, but the merged array provides a _readable_
artifact. One thing to note: we could also potentially cache to
in-memory caching solutions such as memcached, Zend Server, APC, etc.
These would provide the fastest solution, but we'd also potentially need
to worry about memory limits. I'd expect this would be an as-needed
optimization that developers would implement on their own.

So, the question is: which basic caching should we go with? Let the
opinions begin!

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

EvanDotPro
On Wed, Sep 14, 2011 at 6:43 AM, Matthew Weier O'Phinney
<[hidden email]> wrote:
> One thing to note: we could also potentially cache to
> in-memory caching solutions such as memcached, Zend Server, APC, etc.
> These would provide the fastest solution, but we'd also potentially need
> to worry about memory limits. I'd expect this would be an as-needed
> optimization that developers would implement on their own.

+1, leave this up to developers, or even an "UberPerformance" module
or something. ;)

> So, the question is: which basic caching should we go with? Let the
> opinions begin!

+1 for instantiating the Config object from a simple var_export of the
merged array. There seems to be no measurable performance difference
compared with serialization, and the human-readable result could prove
useful in debugging, etc. Also, the var_export method's performance
would probably improve even further with the use of of a PHP opcode
cache (APC).

--
Evan Coury

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

Mischosch
In reply to this post by weierophinney
Hi there,

talked to Evan on irc. So according to his response I'm sending an email here too.

I started to check out the new mvc approach by building a base app with the help of Evans tutorial.

Some problems I got while setting things up:
- If you have more than one "IndexController" in different modules you could use different aliases to make them accessible. But I dont like the idea of aliasing different IndexController to get them working (or should thinking about good aliases the new creative part of my work?). There should be a real module based approach to separate the calls. It should handle it out of the route and the route needs a module parameter. I tried to port the "Module" Route from "old" mvc setup and I got it working in some ways (problem is to get informations about the possible modules in the route match method) - https://gist.github.com/c08635648a43e698be57.

Fetching the right controller based on the module param could be solved like this: $controller = $locator->get($moduleName . '_' . $controllerName); aliases needed to setup like this: admin_index - https://gist.github.com/9f226c2ce591c0dbf3e1.
View rendering is problematic, there are more ScriptPaths set up, and it picks up the first match. So there should be an option to render the view script in a special module view path or manipulating the used script paths. Dont know where to plugin.

I think a real module based approach would make some things more easy and separated, how they should be - perhaps for people coming from zf1 too :) … I only see the benefits of a clear structure. If you build a UserController in your module but also using Evans User module - I mean, there absolutly seems to be a need for it. Even if you only have two modules! (I hope, that solution should work with just _many_ modules having all a UserController without any collisions)

- /attribute/value/attribute/value notation for get params should be integrated in some way (my module loader approach supports notation of params already)


Last I would like to add my opinion to: Optimistic loading / Dynamic bootstrap.

There should be a solution for it. This topic was the biggest problem in zf1 modules with using Zend_Application. All modules were bootstrapped by request. I know many people running in crazy problems because of thinking, only there one module would be bootstrapped by request. Instead of implementing caching mechanism for big configurations I definitely would prefer finding a good way to do bootstrapping in connection to the request. Would be great to see some solution like Evan was talking about:

> I thought about this quite a bit and it's a challenging issue to say
> the least. For this to work, the system needs an intricate
> understanding of what modules are required to dispatch a request
> (http/cli/etc); and unfortunately that can be completely dynamic and
> is not necessarily 1:1. The only thing I can think of is somehow
> having modules themselves work within a sort of DI container
> themselves, which just knows _of_ the modules, but doesn't actually
> load them or their config until they're called via a 'get()' or
> something along those lines. The idea is too abstract for me to even
> begin trying to implement something like that. However that seems like
> a bad idea to me, and I'm not confident it'll actually work in
> practice, or be worth the complication even if it were possible.

Doesn't seem to be a bad idea, I would love having a solution where a ModuleManager bootstraps all things needed for a requested module.


If I compare Zend_Application Module approach to module approach right now, the one big difference is getting things loaded by di and based on events. In the end for building applications it not soo much change compared to zf1. You get fat configurations/bootstrap, all modules are bootstrapped by request. Im missing the points we complain about zf1 modules all the time.

Matthew:

> I would expect most sites would likely compose one or two modules, and
> have one "main" module that composes the majority of the site
> functionality. As such, the whole need for optimistic configuration may
> be a moot point.
>
> However, for larger projects, where you may have many teams working on
> parallel features, modules may also be another good fit -- and this is
> where the problem may crop up. However, those same sites likely would
> have issues under ZF1 as well -- with complexity and size usually come
> performance issues as well. It's good for us to keep these issues in
> mind, but we shouldn't choose _not_ to explore a given path only because
> of them.

I think, a new ZF2MVC approach should handle modules connected to a request. And it should be clear separated.
If you dont want to deal with all that module stuff no one is keeping you from doing only one or perhaps two modules.
But the general idea of modules, being plugable and all that stuff, I dont get the point, why we shouldnt have this issue straight before our eyes and not somewhere backuped in our minds. Otherwise we could just forget it perhaps on our ways to a final zf2.


Cheers

Mischosch

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

till-2
In reply to this post by weierophinney
On Tue, Sep 13, 2011 at 5:11 AM, Matthew Weier O'Phinney
<[hidden email]>wrote:
(...)

I would expect most sites would likely compose one or two modules, and

> have one "main" module that composes the majority of the site
> functionality. As such, the whole need for optimistic configuration may
> be a moot point.
>
> However, for larger projects, where you may have many teams working on
> parallel features, modules may also be another good fit -- and this is
> where the problem may crop up. However, those same sites likely would
> have issues under ZF1 as well -- with complexity and size usually come
> performance issues as well. It's good for us to keep these issues in
> mind, but we shouldn't choose _not_ to explore a given path only because
> of them.
>

I disagree a lot here. For starters, people always advocate seperating
concerns and while of course you can have multiple features live in the same
module, IMHO different modules take this one step further.

And I still hope that ZF2 had a cleaner module architecture/approach. Our
largest issues with ZF1 were module bootstrapping which is currently
un-usable for us (with Zend_Application) or the distribution of libraries
along with it.

Generally, I thinkt the lack of clarity here led to virtually no module
contributions in general. I'm not aware of any site distributing modules for
ZF1 currently and I think most people copy and paste examples from blog
posts and then the code evolves. There's no ecosystem here to e.g. provide
and distribute general purpose modules like blog, forum and user. Look at
Symfony bundles – that's the sort of thing I'm talking about.

Our application currently utilizes about 30 different modules and we're
breaking of more and more code from 'default' as we get around to
refactoring it. Having that much in default was a huge mistake to begin
with.

The benefits for us are:
 * trimming the code-base itself
 * breaking off tests (smaller test suites and easier integration of new
features along with it)
 * we keep it simple

These are all no-brainers, I think.

Another advantage is that when we work with external parties they develop a
module for a certain feature which we just link into our main application
for integration. Take svn:externals or a build script to import the files.
This is great for many reasons e.g. IP and also for the developer themselves
– they need a simple/basic ZF app to get started and don't need to worry
about the entire application we developed over the last five years.

In my eyes, these things are very important and even though they are not
exactly out of the box features in ZF1 I appreciate that it's still
possible, and I had hoped they could be streamlined for ZF2.

We've written some custom code for integration, examples include:

 * distribution of routes with a module
 * module-specific configuration files (and loading)
 * module library folder (and class loading)
 * distributing of assets (js, css, img)
 * distribution of acl

I'm happy to help to push these changes back. I hope the general consensus
is not already that ZF2 is not for me.

Food for thoughts.

Till
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 modules tutorial (with screenshots!)

Tomáš Fejfar
In reply to this post by Mischosch
Only problem with JIT bootstraping is that the routing is usually set up in
the bootstrap itself. So you'll still need to bootstrap routing. But that
might and might not need module's DB access, or some other things. And
voila, you end up bootstraping the whole module. So you would need to
separate the routing from bootstrap. But that would not work as you might be
missing some dependencies for router setup (say db access).

On Sat, Sep 17, 2011 at 10:08 PM, Michael Scholl <[hidden email]> wrote:

> Hi there,
>
> talked to Evan on irc. So according to his response I'm sending an email
> here too.
>
> I started to check out the new mvc approach by building a base app with the
> help of Evans tutorial.
>
> Some problems I got while setting things up:
> - If you have more than one "IndexController" in different modules you
> could use different aliases to make them accessible. But I dont like the
> idea of aliasing different IndexController to get them working (or should
> thinking about good aliases the new creative part of my work?). There should
> be a real module based approach to separate the calls. It should handle it
> out of the route and the route needs a module parameter. I tried to port the
> "Module" Route from "old" mvc setup and I got it working in some ways
> (problem is to get informations about the possible modules in the route
> match method) - https://gist.github.com/c08635648a43e698be57.
>
> Fetching the right controller based on the module param could be solved
> like this: $controller = $locator->get($moduleName . '_' . $controllerName);
> aliases needed to setup like this: admin_index -
> https://gist.github.com/9f226c2ce591c0dbf3e1.
> View rendering is problematic, there are more ScriptPaths set up, and it
> picks up the first match. So there should be an option to render the view
> script in a special module view path or manipulating the used script paths.
> Dont know where to plugin.
>
> I think a real module based approach would make some things more easy and
> separated, how they should be - perhaps for people coming from zf1 too :) …
> I only see the benefits of a clear structure. If you build a UserController
> in your module but also using Evans User module - I mean, there absolutly
> seems to be a need for it. Even if you only have two modules! (I hope, that
> solution should work with just _many_ modules having all a UserController
> without any collisions)
>
> - /attribute/value/attribute/value notation for get params should be
> integrated in some way (my module loader approach supports notation of
> params already)
>
>
> Last I would like to add my opinion to: Optimistic loading / Dynamic
> bootstrap.
>
> There should be a solution for it. This topic was the biggest problem in
> zf1 modules with using Zend_Application. All modules were bootstrapped by
> request. I know many people running in crazy problems because of thinking,
> only there one module would be bootstrapped by request. Instead of
> implementing caching mechanism for big configurations I definitely would
> prefer finding a good way to do bootstrapping in connection to the request.
> Would be great to see some solution like Evan was talking about:
>
> > I thought about this quite a bit and it's a challenging issue to say
> > the least. For this to work, the system needs an intricate
> > understanding of what modules are required to dispatch a request
> > (http/cli/etc); and unfortunately that can be completely dynamic and
> > is not necessarily 1:1. The only thing I can think of is somehow
> > having modules themselves work within a sort of DI container
> > themselves, which just knows _of_ the modules, but doesn't actually
> > load them or their config until they're called via a 'get()' or
> > something along those lines. The idea is too abstract for me to even
> > begin trying to implement something like that. However that seems like
> > a bad idea to me, and I'm not confident it'll actually work in
> > practice, or be worth the complication even if it were possible.
>
> Doesn't seem to be a bad idea, I would love having a solution where a
> ModuleManager bootstraps all things needed for a requested module.
>
>
> If I compare Zend_Application Module approach to module approach right now,
> the one big difference is getting things loaded by di and based on events.
> In the end for building applications it not soo much change compared to zf1.
> You get fat configurations/bootstrap, all modules are bootstrapped by
> request. Im missing the points we complain about zf1 modules all the time.
>
> Matthew:
>
> > I would expect most sites would likely compose one or two modules, and
> > have one "main" module that composes the majority of the site
> > functionality. As such, the whole need for optimistic configuration may
> > be a moot point.
> >
> > However, for larger projects, where you may have many teams working on
> > parallel features, modules may also be another good fit -- and this is
> > where the problem may crop up. However, those same sites likely would
> > have issues under ZF1 as well -- with complexity and size usually come
> > performance issues as well. It's good for us to keep these issues in
> > mind, but we shouldn't choose _not_ to explore a given path only because
> > of them.
>
> I think, a new ZF2MVC approach should handle modules connected to a
> request. And it should be clear separated.
> If you dont want to deal with all that module stuff no one is keeping you
> from doing only one or perhaps two modules.
> But the general idea of modules, being plugable and all that stuff, I dont
> get the point, why we shouldnt have this issue straight before our eyes and
> not somewhere backuped in our minds. Otherwise we could just forget it
> perhaps on our ways to a final zf2.
>
>
> Cheers
>
> Mischosch
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>
123