Modules & ZF2. What will they be?!

[Dolf Schimmel]

Hi folks,

The subject has been hinted on several times, but now it's getting its
very own thread. ZF1 already has modules (though I think they were
hacked in with 1.5?), but each module occurs at several places (a
default directory layout is assumed). There are the config files which
all reside in one common application directory, there are the
controllers/models/services/forms and viewscripts that reside in their
'module directory', and there is the javascript/images that comes with
it, and usually is stored in some random directory in public/.

[default & non modular]
Also, alongside of the modules are the non-modular controllers,
viewscripts, etc. This leads to inconsistencies in dispatching,
results in more code than would otherwise be required, and is weird
since all 'non modular stuff' can also be stored in the default
module. As such I'd propose to always put everything in a module, and
tell people that it's no problem to only utilize one module in total
if their app is too small to justify having multiple ones.

Since 'default' is a keyword to php we cannot call the default module
"default". My suggestion would be to call it Core instead. Even if PHP
allowed for it, I think the naming of Core would better fit with the
idea of modules being selfcontained (see below).

[a module?]
Then we come to what a module actually is. For the sake of scalability
and ease of sharing/distribution I would propose to put everything
that belongs to one module inside 1 module directory. Each module can
have its own config directory which Zend\App iterates over (this can
already be done through extending some of zend_app, but it's not
really you can expect from everybody), and media like javascript or
images can just be put in modules/modulename/public . If we choose to
do the latter we can simply document a default rewrite rule that maps
^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
cross operating system, and I suppose any decent kind of webserver (or
proxy/loadbalancer) supports something similar.

[component framework]
ZF's strength is that it's always been a component framework. Having a
loosely coupled component framework enables users to utilize just a
few components without having to bother with the rest. I'd say this is
a very appealing feature that only few (if any) other mature
frameworks provide. It happens time after time after time that a new
user starts integrating only one or two components in his/her
application, and that over time they start utilizing the entire fw. As
such, I'm thinking that although we should have modules that are
selfcontained (and as such may be easily moved across applications),
we should not try to build an application framework. This would take a
lot of time, but more importantly, the chances of losing the fact that
components can be utilized standalone would vastly increase. This
means that imho ZF should /not/ be aware of what a user is.

I do however think that building a layer /on top/ of ZF2 would be a
great thing. However time/resource wise I'd say we shouldn't do this
in ZF2.0.0, and it should probably be done as a standalone project. If
not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
Enrico), I see potential to revive Zym Engine (or have someone else
step up to take lead here) *. Allowing to build a layer on top of ZF
that converts it into an application framework should be a
consideration, and therefore I think we'd need to contemplate how one
can extend a module. Think of me building my Foo module that's meant
to be a blog, and someone - obviously not wanting to touch my code -
be able to just extend the module and override specific parts of it.

* Obviously several contributors could try independently from each
other to set up such a layer, but I'm thinking ultimately only one
would 'win' the battle this would create. As usual contributors are
encouraged to collaborate and share knowledge.

I've just noted down some ideas of my own - although inspired by
talking to lots of contributors. I'd be curious to know how you feel
above the points mentioned above. Also, feel free to address any
relevant issue when it comes to modularization that I have missed.

Dolf
-- Freeaqingme

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

[Anthony Shireman]

+3

I added a few extra because I've already done the same thing and called my
'default' module 'Core'. But with all the notes below, this is how I've been
trying to develop the modular parts of my application. I've developed
several applications that have only one module, then to create something
useful I usually merge multiple modules together. The process falls apart
just as suggested where certain shared resources are involved and the
placement of styles and scripts and configs. I would love the ability to be
able to drop in (which has been mentioned in the past) a module, add a
little bit to my existing application and gain all the functionality of an
additional module. Using something like git submodules would help with
dependencies and the ability to pull in updates, but would make it more
difficult to just 'start using' other modules.


Tony Shireman



On Wed, Jun 1, 2011 at 11:52 AM, Dolf Schimmel <[hidden email]>wrote:

> Hi folks,
>
> The subject has been hinted on several times, but now it's getting its
> very own thread. ZF1 already has modules (though I think they were
> hacked in with 1.5?), but each module occurs at several places (a
> default directory layout is assumed). There are the config files which
> all reside in one common application directory, there are the
> controllers/models/services/forms and viewscripts that reside in their
> 'module directory', and there is the javascript/images that comes with
> it, and usually is stored in some random directory in public/.
>
> [default & non modular]
> Also, alongside of the modules are the non-modular controllers,
> viewscripts, etc. This leads to inconsistencies in dispatching,
> results in more code than would otherwise be required, and is weird
> since all 'non modular stuff' can also be stored in the default
> module. As such I'd propose to always put everything in a module, and
> tell people that it's no problem to only utilize one module in total
> if their app is too small to justify having multiple ones.
>
> Since 'default' is a keyword to php we cannot call the default module
> "default". My suggestion would be to call it Core instead. Even if PHP
> allowed for it, I think the naming of Core would better fit with the
> idea of modules being selfcontained (see below).
>
> [a module?]
> Then we come to what a module actually is. For the sake of scalability
> and ease of sharing/distribution I would propose to put everything
> that belongs to one module inside 1 module directory. Each module can
> have its own config directory which Zend\App iterates over (this can
> already be done through extending some of zend_app, but it's not
> really you can expect from everybody), and media like javascript or
> images can just be put in modules/modulename/public . If we choose to
> do the latter we can simply document a default rewrite rule that maps
> ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
> cross operating system, and I suppose any decent kind of webserver (or
> proxy/loadbalancer) supports something similar.
>
> [component framework]
> ZF's strength is that it's always been a component framework. Having a
> loosely coupled component framework enables users to utilize just a
> few components without having to bother with the rest. I'd say this is
> a very appealing feature that only few (if any) other mature
> frameworks provide. It happens time after time after time that a new
> user starts integrating only one or two components in his/her
> application, and that over time they start utilizing the entire fw. As
> such, I'm thinking that although we should have modules that are
> selfcontained (and as such may be easily moved across applications),
> we should not try to build an application framework. This would take a
> lot of time, but more importantly, the chances of losing the fact that
> components can be utilized standalone would vastly increase. This
> means that imho ZF should /not/ be aware of what a user is.
>
> I do however think that building a layer /on top/ of ZF2 would be a
> great thing. However time/resource wise I'd say we shouldn't do this
> in ZF2.0.0, and it should probably be done as a standalone project. If
> not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
> Enrico), I see potential to revive Zym Engine (or have someone else
> step up to take lead here) *. Allowing to build a layer on top of ZF
> that converts it into an application framework should be a
> consideration, and therefore I think we'd need to contemplate how one
> can extend a module. Think of me building my Foo module that's meant
> to be a blog, and someone - obviously not wanting to touch my code -
> be able to just extend the module and override specific parts of it.
>
> * Obviously several contributors could try independently from each
> other to set up such a layer, but I'm thinking ultimately only one
> would 'win' the battle this would create. As usual contributors are
> encouraged to collaborate and share knowledge.
>
> I've just noted down some ideas of my own - although inspired by
> talking to lots of contributors. I'd be curious to know how you feel
> above the points mentioned above. Also, feel free to address any
> relevant issue when it comes to modularization that I have missed.
>
> Dolf
> -- Freeaqingme
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

[Kevin McArthur-2]

Hey Dolf, replies inline.

> The subject has been hinted on several times, but now it's getting its
> very own thread. ZF1 already has modules (though I think they were
> hacked in with 1.5?), but each module occurs at several places (a
> default directory layout is assumed). There are the config files which
> all reside in one common application directory, there are the
> controllers/models/services/forms and viewscripts that reside in their
> 'module directory', and there is the javascript/images that comes with
> it, and usually is stored in some random directory in public/.
The current concept of a module really needs to be scrapped. They were
just that--a bolted on solution. I'm not aware of anyone actually
distributing Zend Framework modules.

Things brings us back to 'what is a module'... and to me that looks like
a bundle/component/whatever else you want to call it...

It contains

- automatic configuration
- resources (images,scripts,css,etc)
- templates (views)
- controllers
- models
- tests
- etc

My concept for components (discussed briefly on the prior thread) is a
phar-based system where modules can plug into an already bootstrapped
site and inject itself into an existing site by adding routes, acl
hooks, etc..

However as discussed, the downside is that now components need to play
nice together and we need to actually define what an Interface looks
like for Zend_Auth/ACL, caching, routing, etc... eg the core
interoperability points in a way that is compatible with _multiple_
injections.

> [default&  non modular]
> Also, alongside of the modules are the non-modular controllers,
> viewscripts, etc. This leads to inconsistencies in dispatching,
> results in more code than would otherwise be required, and is weird
> since all 'non modular stuff' can also be stored in the default
> module. As such I'd propose to always put everything in a module, and
> tell people that it's no problem to only utilize one module in total
> if their app is too small to justify having multiple ones.
>
> Since 'default' is a keyword to php we cannot call the default module
> "default". My suggestion would be to call it Core instead. Even if PHP
> allowed for it, I think the naming of Core would better fit with the
> idea of modules being selfcontained (see below).

These modular issues should go away as we move from a 'site-as-a-module'
to a 'module-in-a-site' reference frame. Right now modules are
essentially just subdirectories on the default controller/action route.
Not really a component model.

> [a module?]
> Then we come to what a module actually is. For the sake of scalability
> and ease of sharing/distribution I would propose to put everything
> that belongs to one module inside 1 module directory. Each module can
> have its own config directory which Zend\App iterates over (this can
> already be done through extending some of zend_app, but it's not
> really you can expect from everybody), and media like javascript or
> images can just be put in modules/modulename/public . If we choose to
> do the latter we can simply document a default rewrite rule that maps
> ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
> cross operating system, and I suppose any decent kind of webserver (or
> proxy/loadbalancer) supports something similar.

This really depends on how we want to handle the packaging. If its
phar-based, then a bunch of phars can all sit in a components dir and no
one gets upset. If its file based, then hierarchy is really important.

Poll item 1) Do we use a phar based component packaging?

> [component framework]
> ZF's strength is that it's always been a component framework. Having a
> loosely coupled component framework enables users to utilize just a
> few components without having to bother with the rest. I'd say this is
> a very appealing feature that only few (if any) other mature
> frameworks provide. It happens time after time after time that a new
> user starts integrating only one or two components in his/her
> application, and that over time they start utilizing the entire fw. As
> such, I'm thinking that although we should have modules that are
> selfcontained (and as such may be easily moved across applications),
> we should not try to build an application framework. This would take a
> lot of time, but more importantly, the chances of losing the fact that
> components can be utilized standalone would vastly increase. This
> means that imho ZF should /not/ be aware of what a user is.

I believe we can have both a loosely coupled framework and a strong
component model. The component model (or ComponentManager) of course
would be the magic glue to tie it all together. You could decide not to
bootstrap this class and just use ZFW as you do today. I guess this is
the extension of the Zend_Application concept where certain integrations
are handled in a standardized way. Like Zend_Application though, you'd
not be forced to use it.

> I do however think that building a layer /on top/ of ZF2 would be a
> great thing. However time/resource wise I'd say we shouldn't do this
> in ZF2.0.0, and it should probably be done as a standalone project. If
> not initiated by Zend (more specifically the ZF team; Matthew, Ralph&
> Enrico), I see potential to revive Zym Engine (or have someone else
> step up to take lead here) *. Allowing to build a layer on top of ZF
> that converts it into an application framework should be a
> consideration, and therefore I think we'd need to contemplate how one
> can extend a module. Think of me building my Foo module that's meant
> to be a blog, and someone - obviously not wanting to touch my code -
> be able to just extend the module and override specific parts of it.

Its all about critical mass. If it doesn't make it into 2.0 I can't see
it becoming independently successful as it would have to sit on top and
build its own userbase up, and then it would be at the mercy of a lag
cycle between Zend release and updated Zym layer release.

If we do an application-framework model, it should be in the core ZF
framework IMO. Use if desired of course, but very much core.
> * Obviously several contributors could try independently from each
> other to set up such a layer, but I'm thinking ultimately only one
> would 'win' the battle this would create. As usual contributors are
> encouraged to collaborate and share knowledge.
I think this is a case of needing a standardized solution, rather than
several community solutions.
> I've just noted down some ideas of my own - although inspired by
> talking to lots of contributors. I'd be curious to know how you feel
> above the points mentioned above. Also, feel free to address any
> relevant issue when it comes to modularization that I have missed.
>
> Dolf
> -- Freeaqingme
>

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

[Court Ewing]

Howdy,

Doh.  I sent this originally to Dolf only.  Sorry for the duplicate, Dolf!

Modules, in my opinion, are the single greatest problem with Zend Framework
at this point, so I am ecstatic to see more discussion about them.  I talked
a bit with Matthew about my feelings on the matter at tek11, but
unfortunately we were never able to sit down to discuss in more detail.

The current implementation in ZF1 is so bad that it should not even be used
as basis for any new module system that is created.  At the moment, they
serve only to better organize large projects and have basically zero
reusability, and that sucks... a lot.  I hate to make the comparison, but I
think symfony2 _nailed_ the concept of modules (they call them bundles), and
I also think that is one of the biggest reasons why so many developers are
adopting symfony2 already.  The bundle system is so flexible, and creating
reusable "modules" that can be installed into any standard symfony2 app
structure with very little configuration is so easy that hundreds of third
party bundles are already on github.

The immediate benefit of this is that the community can focus on the best
bundle out there for any particular job, and you won't have thousands of
developers writing the same functionality over and over again.  A good
example of this is the UserBundle that is very popular on github right now
(offered by a community group called Friends Of Symfony) -- with it, you
will not have to write user login, logout, forget password, etc.
functionality again.  Sure, you all probably have this type of "module" for
your own ZF projects, but you most likely wrote your own, and I am supremely
confident that I couldn't drop your user module into my app.

My opinion about how modules should be implemented in ZF is slightly tainted
by my experiences working with symfony2 bundles, but I'll give a go at
pointing out the most important aspects of modules that I think must be
central to any planning of module support in ZF2:

   1. Modules are not simply independent libraries of PHP code.  They are
   all of the library code (controllers, models, forms, etc), api
   documentation, user documentation, unit tests, public resources (images,
   javascript, css, etc), configurations, command line tools, and any other
   tools, files, classes, etc. related to that module's functionality.  All of
   these things should be contained within a standardized module file format
   and in a single parent directory.
   2. Modules must have vendor namespaces.  I might create my own User
   module, and that should be clearly distinguished from someone else's user
   module.  Even though both of our modules are called User, the fact that mine
   is bundled with the Epixa vendor namespace should mean that there are no
   file naming conflicts nor are there any php namespace conflicts between the
   two modules.  An example directory structure for this could be:
   modules/Epixa/UserModule
   3. The actual PHP classes within the module should follow standard
   autoloading conventions so there are no restrictions on what types of
   classes you use in a module (as is the case with the current resource
   autoloader setup in zf1).  If I want an Epixa\UserModule\Entity\Session
   namespace, I should be able to create it without additional configuration.
    Same goes for an Epixa\UserModule\Foo\Bar namespace.
   4. Modules should be able to extend certain pieces of functionality from
   other modules.  This is likely to be a contentious issue, but I do think it
   makes modules immensely more flexible and reusable.  This allows for not
   only module dependency for open source modules, but it also allows the user
   to create an installation-specific module that performs very specific
   tweaking for the current application needs.
   5. Modules should be independent units that are contained in their own
   repositories.  Obviously there is no way to force people to make each of
   their modules a unique repo, but the practice should be highly encouraged.
    This is a fundamental requirement if we really want the community to come
   together around third party module development.  People need to be able to
   search for ZF2 modules on sites like github, and they should be finding blog
   modules, user modules, etc. that are independent of each other but that can
   work together.  Symfony handles this by specifically defining standards for
   bundle development including how bundles should be packaged in repositories.
   6. Application configuration should be able to import module
   configurations.  So if my module has a routes config (as all modules should
   have), then I should be able to import those routes into my application's
   routing config with a simple addition to the application configuration or
   bootstrapping.  Specifically with routes, I should be able to (but not
   required to) prefix module routing schemes so as to avoid any conflicts that
   might happen between module routes.  For example, in my application config,
   I should be able to import my UserModule routes and say that I want those
   routes prefixed by "/user" so that if I have a route defining something like
   /view/:id, I would access that via the uri scheme /user/view/:id so I know
   that does not conflict with a blog module's routes that may have a similar
   scheme for viewing blog articles.
   7. Copying or symlinking public module resources (images, css,
   javascript) should be possible through the command line.  Of course someone
   could get crazy with this and develop an entire UI in its own module for
   handling this sort of thing (and I imagine someone will), but I don't really
   think it is necessary for it to be a part of the ZF core.
   8. Ideally modules could add command line functionality without having to
   implement their own unique command line interfaces.
   9. Modules are not fundamentally functionality centered around
   controllers and views.  If a module exists solely to add command line
   functionality, that should be possible.
   10. The application itself should be little more than the glue necessary
   to bring all of the application's module functionality together.  If you
   don't want to use modules, that's cool.  Throw all of your functionality in
   a single module and call it a day.

I agree strongly with Kevin McArthur's point about a module/component system
being a core part of the framework without destroying the loosely coupled
nature that we're aiming for.  It can be done, and I think modules are such
an important aspect of building reusable web apps in an MVC framework that
we cannot settle for a mediocre implementation.  It's not just a matter of
helping me write my apps better, either.  When you have a strong module
system, it provides an extremely visible way for the community to get
involved in writing really good ZF-based functionality, and it attracts new
users as a result of that high visibility.  Symfony2 is still in beta and
there are hundreds of bundles out there.  In time, it will be difficult to
look for something like user-functionality or blog-functionality on github
without coming across standalone Symfony2 bundles for those very things.  I
desperately want the same to be true with Zend Framework.

-Court


On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel <[hidden email]>wrote:

> Hi folks,
>
> The subject has been hinted on several times, but now it's getting its
> very own thread. ZF1 already has modules (though I think they were
> hacked in with 1.5?), but each module occurs at several places (a
> default directory layout is assumed). There are the config files which
> all reside in one common application directory, there are the
> controllers/models/services/forms and viewscripts that reside in their
> 'module directory', and there is the javascript/images that comes with
> it, and usually is stored in some random directory in public/.
>
> [default & non modular]
> Also, alongside of the modules are the non-modular controllers,
> viewscripts, etc. This leads to inconsistencies in dispatching,
> results in more code than would otherwise be required, and is weird
> since all 'non modular stuff' can also be stored in the default
> module. As such I'd propose to always put everything in a module, and
> tell people that it's no problem to only utilize one module in total
> if their app is too small to justify having multiple ones.
>
> Since 'default' is a keyword to php we cannot call the default module
> "default". My suggestion would be to call it Core instead. Even if PHP
> allowed for it, I think the naming of Core would better fit with the
> idea of modules being selfcontained (see below).
>
> [a module?]
> Then we come to what a module actually is. For the sake of scalability
> and ease of sharing/distribution I would propose to put everything
> that belongs to one module inside 1 module directory. Each module can
> have its own config directory which Zend\App iterates over (this can
> already be done through extending some of zend_app, but it's not
> really you can expect from everybody), and media like javascript or
> images can just be put in modules/modulename/public . If we choose to
> do the latter we can simply document a default rewrite rule that maps
> ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
> cross operating system, and I suppose any decent kind of webserver (or
> proxy/loadbalancer) supports something similar.
>
> [component framework]
> ZF's strength is that it's always been a component framework. Having a
> loosely coupled component framework enables users to utilize just a
> few components without having to bother with the rest. I'd say this is
> a very appealing feature that only few (if any) other mature
> frameworks provide. It happens time after time after time that a new
> user starts integrating only one or two components in his/her
> application, and that over time they start utilizing the entire fw. As
> such, I'm thinking that although we should have modules that are
> selfcontained (and as such may be easily moved across applications),
> we should not try to build an application framework. This would take a
> lot of time, but more importantly, the chances of losing the fact that
> components can be utilized standalone would vastly increase. This
> means that imho ZF should /not/ be aware of what a user is.
>
> I do however think that building a layer /on top/ of ZF2 would be a
> great thing. However time/resource wise I'd say we shouldn't do this
> in ZF2.0.0, and it should probably be done as a standalone project. If
> not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
> Enrico), I see potential to revive Zym Engine (or have someone else
> step up to take lead here) *. Allowing to build a layer on top of ZF
> that converts it into an application framework should be a
> consideration, and therefore I think we'd need to contemplate how one
> can extend a module. Think of me building my Foo module that's meant
> to be a blog, and someone - obviously not wanting to touch my code -
> be able to just extend the module and override specific parts of it.
>
> * Obviously several contributors could try independently from each
> other to set up such a layer, but I'm thinking ultimately only one
> would 'win' the battle this would create. As usual contributors are
> encouraged to collaborate and share knowledge.
>
> I've just noted down some ideas of my own - although inspired by
> talking to lots of contributors. I'd be curious to know how you feel
> above the points mentioned above. Also, feel free to address any
> relevant issue when it comes to modularization that I have missed.
>
> Dolf
> -- Freeaqingme
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

[Dolf Schimmel]

> Doh.  I sent this originally to Dolf only.  Sorry for the duplicate, Dolf!

So far I've received 50% more emails on this thread than the rest of
the mailinglist, so don't be ashamed, you're not the only one ;)

As I mentioned, I thought it would be a bad idea if ZF itself had any
idea about what a user is, that should be left up to the application.
However, I do see opportunity to ship ZF with some default modules
(that can be disabled), of which the base of user registration &
logging in could be one. Realizing (now) that you could put those
responsibilities in modules, I think that as long as that's how you do
it I have no problem with ZF being an application (as well as a
component!!!) framework.

The fact that symfony is the only mature application framework out
there (besides drupal perhaps) makes it tempting to compare everything
with sf. I would however suggest to not blindly focus on the
functionality sf provides, but to try and look at the underlying
ideas... "Do not seek to follow in the footsteps of the wise. Seek
what they sought. " --- Matsuo Basho

Furthermore, I think some of your points have been addressed already,
replying inline.


> Modules must have vendor namespaces.

Agreed. But that's already been agreed on in PSR/0. So luckily we dont
have to worry about that. (url:
http://groups.google.com/group/php-standards/web/psr-0-final-proposal
)


> Copying or symlinking public module resources (images, css, javascript)
> should be possible through the command line.  Of course someone could get
> crazy with this and develop an entire UI in its own module for handling this
> sort of thing (and I imagine someone will), but I don't really think it is
> necessary for it to be a part of the ZF core.
Be aware that not all operatingsystems or filesystems
(*cough*FAT*cough*Windows*cough*) support symlinks. Therefore we
cannot solely rely on these, which is why I mentioned the rewrite rule
being an options to utilize as well.

> Application configuration should be able to import module configurations.
> So if my module has a routes config (as all modules should have), then
> I should be able to import those routes into my application's routing
> config with a simple addition to the application configuration or bootstrapping.
> Specifically with routes, I should be able to (but not required to) prefix
> module routing schemes so as to avoid any conflicts that might happen
> between module routes.

I'd like to actually extend this thought. One config should be able to
hookin to the other. Think of a navigation tree where you have an
admin menu in your 'root config' (whatever). A module should be able
to attach part of its navigation to that specific 'admin menu'. This
can already be done (see my github page), but obviously there's a need
to standardize this.

> I agree strongly with Kevin McArthur's point about a module/component system
> being a core part of the framework without destroying the loosely coupled
> nature that we're aiming for.  It can be done, and I think modules are such
> an important aspect of building reusable web apps in an MVC framework that
> we cannot settle for a mediocre implementation.  It's not just a matter of
> helping me write my apps better, either.

See the beginning of my email, as long as the  ZF core has no
recollection of what a user is, I think everything is perfectly fine.
Obviously, we don't settle with mediocre (if I'd had, I'd have used
another framework - CI perhaps?)

Regards,

Dolf
-- Freeaqingme

> On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel <[hidden email]>
> wrote:
>>
>> Hi folks,
>>
>> The subject has been hinted on several times, but now it's getting its
>> very own thread. ZF1 already has modules (though I think they were
>> hacked in with 1.5?), but each module occurs at several places (a
>> default directory layout is assumed). There are the config files which
>> all reside in one common application directory, there are the
>> controllers/models/services/forms and viewscripts that reside in their
>> 'module directory', and there is the javascript/images that comes with
>> it, and usually is stored in some random directory in public/.
>>
>> [default & non modular]
>> Also, alongside of the modules are the non-modular controllers,
>> viewscripts, etc. This leads to inconsistencies in dispatching,
>> results in more code than would otherwise be required, and is weird
>> since all 'non modular stuff' can also be stored in the default
>> module. As such I'd propose to always put everything in a module, and
>> tell people that it's no problem to only utilize one module in total
>> if their app is too small to justify having multiple ones.
>>
>> Since 'default' is a keyword to php we cannot call the default module
>> "default". My suggestion would be to call it Core instead. Even if PHP
>> allowed for it, I think the naming of Core would better fit with the
>> idea of modules being selfcontained (see below).
>>
>> [a module?]
>> Then we come to what a module actually is. For the sake of scalability
>> and ease of sharing/distribution I would propose to put everything
>> that belongs to one module inside 1 module directory. Each module can
>> have its own config directory which Zend\App iterates over (this can
>> already be done through extending some of zend_app, but it's not
>> really you can expect from everybody), and media like javascript or
>> images can just be put in modules/modulename/public . If we choose to
>> do the latter we can simply document a default rewrite rule that maps
>> ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
>> cross operating system, and I suppose any decent kind of webserver (or
>> proxy/loadbalancer) supports something similar.
>>
>> [component framework]
>> ZF's strength is that it's always been a component framework. Having a
>> loosely coupled component framework enables users to utilize just a
>> few components without having to bother with the rest. I'd say this is
>> a very appealing feature that only few (if any) other mature
>> frameworks provide. It happens time after time after time that a new
>> user starts integrating only one or two components in his/her
>> application, and that over time they start utilizing the entire fw. As
>> such, I'm thinking that although we should have modules that are
>> selfcontained (and as such may be easily moved across applications),
>> we should not try to build an application framework. This would take a
>> lot of time, but more importantly, the chances of losing the fact that
>> components can be utilized standalone would vastly increase. This
>> means that imho ZF should /not/ be aware of what a user is.
>>
>> I do however think that building a layer /on top/ of ZF2 would be a
>> great thing. However time/resource wise I'd say we shouldn't do this
>> in ZF2.0.0, and it should probably be done as a standalone project. If
>> not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
>> Enrico), I see potential to revive Zym Engine (or have someone else
>> step up to take lead here) *. Allowing to build a layer on top of ZF
>> that converts it into an application framework should be a
>> consideration, and therefore I think we'd need to contemplate how one
>> can extend a module. Think of me building my Foo module that's meant
>> to be a blog, and someone - obviously not wanting to touch my code -
>> be able to just extend the module and override specific parts of it.
>>
>> * Obviously several contributors could try independently from each
>> other to set up such a layer, but I'm thinking ultimately only one
>> would 'win' the battle this would create. As usual contributors are
>> encouraged to collaborate and share knowledge.
>>
>> I've just noted down some ideas of my own - although inspired by
>> talking to lots of contributors. I'd be curious to know how you feel
>> above the points mentioned above. Also, feel free to address any
>> relevant issue when it comes to modularization that I have missed.
>>
>> Dolf
>> -- Freeaqingme
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>
>

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

[Kevin McArthur-2]

+1 to all of this... I'm totally going to go check out Symphony2 bundles
now.

--

K

On 11-06-01 12:47 PM, Court Ewing wrote:

> Howdy,
>
> Doh.  I sent this originally to Dolf only.  Sorry for the duplicate, Dolf!
>
> Modules, in my opinion, are the single greatest problem with Zend Framework
> at this point, so I am ecstatic to see more discussion about them.  I talked
> a bit with Matthew about my feelings on the matter at tek11, but
> unfortunately we were never able to sit down to discuss in more detail.
>
> The current implementation in ZF1 is so bad that it should not even be used
> as basis for any new module system that is created.  At the moment, they
> serve only to better organize large projects and have basically zero
> reusability, and that sucks... a lot.  I hate to make the comparison, but I
> think symfony2 _nailed_ the concept of modules (they call them bundles), and
> I also think that is one of the biggest reasons why so many developers are
> adopting symfony2 already.  The bundle system is so flexible, and creating
> reusable "modules" that can be installed into any standard symfony2 app
> structure with very little configuration is so easy that hundreds of third
> party bundles are already on github.
>
> The immediate benefit of this is that the community can focus on the best
> bundle out there for any particular job, and you won't have thousands of
> developers writing the same functionality over and over again.  A good
> example of this is the UserBundle that is very popular on github right now
> (offered by a community group called Friends Of Symfony) -- with it, you
> will not have to write user login, logout, forget password, etc.
> functionality again.  Sure, you all probably have this type of "module" for
> your own ZF projects, but you most likely wrote your own, and I am supremely
> confident that I couldn't drop your user module into my app.
>
> My opinion about how modules should be implemented in ZF is slightly tainted
> by my experiences working with symfony2 bundles, but I'll give a go at
> pointing out the most important aspects of modules that I think must be
> central to any planning of module support in ZF2:
>
>     1. Modules are not simply independent libraries of PHP code.  They are
>     all of the library code (controllers, models, forms, etc), api
>     documentation, user documentation, unit tests, public resources (images,
>     javascript, css, etc), configurations, command line tools, and any other
>     tools, files, classes, etc. related to that module's functionality.  All of
>     these things should be contained within a standardized module file format
>     and in a single parent directory.
>     2. Modules must have vendor namespaces.  I might create my own User
>     module, and that should be clearly distinguished from someone else's user
>     module.  Even though both of our modules are called User, the fact that mine
>     is bundled with the Epixa vendor namespace should mean that there are no
>     file naming conflicts nor are there any php namespace conflicts between the
>     two modules.  An example directory structure for this could be:
>     modules/Epixa/UserModule
>     3. The actual PHP classes within the module should follow standard
>     autoloading conventions so there are no restrictions on what types of
>     classes you use in a module (as is the case with the current resource
>     autoloader setup in zf1).  If I want an Epixa\UserModule\Entity\Session
>     namespace, I should be able to create it without additional configuration.
>      Same goes for an Epixa\UserModule\Foo\Bar namespace.
>     4. Modules should be able to extend certain pieces of functionality from
>     other modules.  This is likely to be a contentious issue, but I do think it
>     makes modules immensely more flexible and reusable.  This allows for not
>     only module dependency for open source modules, but it also allows the user
>     to create an installation-specific module that performs very specific
>     tweaking for the current application needs.
>     5. Modules should be independent units that are contained in their own
>     repositories.  Obviously there is no way to force people to make each of
>     their modules a unique repo, but the practice should be highly encouraged.
>      This is a fundamental requirement if we really want the community to come
>     together around third party module development.  People need to be able to
>     search for ZF2 modules on sites like github, and they should be finding blog
>     modules, user modules, etc. that are independent of each other but that can
>     work together.  Symfony handles this by specifically defining standards for
>     bundle development including how bundles should be packaged in repositories.
>     6. Application configuration should be able to import module
>     configurations.  So if my module has a routes config (as all modules should
>     have), then I should be able to import those routes into my application's
>     routing config with a simple addition to the application configuration or
>     bootstrapping.  Specifically with routes, I should be able to (but not
>     required to) prefix module routing schemes so as to avoid any conflicts that
>     might happen between module routes.  For example, in my application config,
>     I should be able to import my UserModule routes and say that I want those
>     routes prefixed by "/user" so that if I have a route defining something like
>     /view/:id, I would access that via the uri scheme /user/view/:id so I know
>     that does not conflict with a blog module's routes that may have a similar
>     scheme for viewing blog articles.
>     7. Copying or symlinking public module resources (images, css,
>     javascript) should be possible through the command line.  Of course someone
>     could get crazy with this and develop an entire UI in its own module for
>     handling this sort of thing (and I imagine someone will), but I don't really
>     think it is necessary for it to be a part of the ZF core.
>     8. Ideally modules could add command line functionality without having to
>     implement their own unique command line interfaces.
>     9. Modules are not fundamentally functionality centered around
>     controllers and views.  If a module exists solely to add command line
>     functionality, that should be possible.
>     10. The application itself should be little more than the glue necessary
>     to bring all of the application's module functionality together.  If you
>     don't want to use modules, that's cool.  Throw all of your functionality in
>     a single module and call it a day.
>
> I agree strongly with Kevin McArthur's point about a module/component system
> being a core part of the framework without destroying the loosely coupled
> nature that we're aiming for.  It can be done, and I think modules are such
> an important aspect of building reusable web apps in an MVC framework that
> we cannot settle for a mediocre implementation.  It's not just a matter of
> helping me write my apps better, either.  When you have a strong module
> system, it provides an extremely visible way for the community to get
> involved in writing really good ZF-based functionality, and it attracts new
> users as a result of that high visibility.  Symfony2 is still in beta and
> there are hundreds of bundles out there.  In time, it will be difficult to
> look for something like user-functionality or blog-functionality on github
> without coming across standalone Symfony2 bundles for those very things.  I
> desperately want the same to be true with Zend Framework.
>
> -Court
>
>
> On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel<[hidden email]>wrote:
>
>> Hi folks,
>>
>> The subject has been hinted on several times, but now it's getting its
>> very own thread. ZF1 already has modules (though I think they were
>> hacked in with 1.5?), but each module occurs at several places (a
>> default directory layout is assumed). There are the config files which
>> all reside in one common application directory, there are the
>> controllers/models/services/forms and viewscripts that reside in their
>> 'module directory', and there is the javascript/images that comes with
>> it, and usually is stored in some random directory in public/.
>>
>> [default&  non modular]
>> Also, alongside of the modules are the non-modular controllers,
>> viewscripts, etc. This leads to inconsistencies in dispatching,
>> results in more code than would otherwise be required, and is weird
>> since all 'non modular stuff' can also be stored in the default
>> module. As such I'd propose to always put everything in a module, and
>> tell people that it's no problem to only utilize one module in total
>> if their app is too small to justify having multiple ones.
>>
>> Since 'default' is a keyword to php we cannot call the default module
>> "default". My suggestion would be to call it Core instead. Even if PHP
>> allowed for it, I think the naming of Core would better fit with the
>> idea of modules being selfcontained (see below).
>>
>> [a module?]
>> Then we come to what a module actually is. For the sake of scalability
>> and ease of sharing/distribution I would propose to put everything
>> that belongs to one module inside 1 module directory. Each module can
>> have its own config directory which Zend\App iterates over (this can
>> already be done through extending some of zend_app, but it's not
>> really you can expect from everybody), and media like javascript or
>> images can just be put in modules/modulename/public . If we choose to
>> do the latter we can simply document a default rewrite rule that maps
>> ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
>> cross operating system, and I suppose any decent kind of webserver (or
>> proxy/loadbalancer) supports something similar.
>>
>> [component framework]
>> ZF's strength is that it's always been a component framework. Having a
>> loosely coupled component framework enables users to utilize just a
>> few components without having to bother with the rest. I'd say this is
>> a very appealing feature that only few (if any) other mature
>> frameworks provide. It happens time after time after time that a new
>> user starts integrating only one or two components in his/her
>> application, and that over time they start utilizing the entire fw. As
>> such, I'm thinking that although we should have modules that are
>> selfcontained (and as such may be easily moved across applications),
>> we should not try to build an application framework. This would take a
>> lot of time, but more importantly, the chances of losing the fact that
>> components can be utilized standalone would vastly increase. This
>> means that imho ZF should /not/ be aware of what a user is.
>>
>> I do however think that building a layer /on top/ of ZF2 would be a
>> great thing. However time/resource wise I'd say we shouldn't do this
>> in ZF2.0.0, and it should probably be done as a standalone project. If
>> not initiated by Zend (more specifically the ZF team; Matthew, Ralph&
>> Enrico), I see potential to revive Zym Engine (or have someone else
>> step up to take lead here) *. Allowing to build a layer on top of ZF
>> that converts it into an application framework should be a
>> consideration, and therefore I think we'd need to contemplate how one
>> can extend a module. Think of me building my Foo module that's meant
>> to be a blog, and someone - obviously not wanting to touch my code -
>> be able to just extend the module and override specific parts of it.
>>
>> * Obviously several contributors could try independently from each
>> other to set up such a layer, but I'm thinking ultimately only one
>> would 'win' the battle this would create. As usual contributors are
>> encouraged to collaborate and share knowledge.
>>
>> I've just noted down some ideas of my own - although inspired by
>> talking to lots of contributors. I'd be curious to know how you feel
>> above the points mentioned above. Also, feel free to address any
>> relevant issue when it comes to modularization that I have missed.
>>
>> Dolf
>> -- Freeaqingme
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>

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

[Tomáš Fejfar]

I agree. 100%.  One important addition I have is that even though ZF is a
library of **loosely-coupled** classes, we should opt-out this concept for
the MVC part. The MVC core is so specific that it does not need to be so
loose. The MVC should be centered around extensibility, right...  but it
should not choose loose-coupling over speed (or developer-experience). I'm
bold enough to say 90% of developer out there **never** needed to extend any
of the core MVC classes (with the exception of Router). We don't need to
make the core super-customizable (say changing url separator from / to -),
but instead we shoud look for "good-working defaults".

Loose coupling is great thing but there are places where things like speed
matter much more.

If you know about any situations where developers needed only part of core
MVC, let me know. I don't know any.

P.S.: I've noticed now that I've been actually talking about the dispatch
process, not MVC. I don't know it that well as other parts of ZF, but the
only fact that empty request is much slower in ZF than in other frameworks
shows the problem.

On Wed, Jun 1, 2011 at 9:47 PM, Court Ewing <[hidden email]> wrote:

> Howdy,
>
> Doh.  I sent this originally to Dolf only.  Sorry for the duplicate, Dolf!
>
> Modules, in my opinion, are the single greatest problem with Zend Framework
> at this point, so I am ecstatic to see more discussion about them.  I
> talked
> a bit with Matthew about my feelings on the matter at tek11, but
> unfortunately we were never able to sit down to discuss in more detail.
>
> The current implementation in ZF1 is so bad that it should not even be used
> as basis for any new module system that is created.  At the moment, they
> serve only to better organize large projects and have basically zero
> reusability, and that sucks... a lot.  I hate to make the comparison, but I
> think symfony2 _nailed_ the concept of modules (they call them bundles),
> and
> I also think that is one of the biggest reasons why so many developers are
> adopting symfony2 already.  The bundle system is so flexible, and creating
> reusable "modules" that can be installed into any standard symfony2 app
> structure with very little configuration is so easy that hundreds of third
> party bundles are already on github.
>
> The immediate benefit of this is that the community can focus on the best
> bundle out there for any particular job, and you won't have thousands of
> developers writing the same functionality over and over again.  A good
> example of this is the UserBundle that is very popular on github right now
> (offered by a community group called Friends Of Symfony) -- with it, you
> will not have to write user login, logout, forget password, etc.
> functionality again.  Sure, you all probably have this type of "module" for
> your own ZF projects, but you most likely wrote your own, and I am
> supremely
> confident that I couldn't drop your user module into my app.
>
> My opinion about how modules should be implemented in ZF is slightly
> tainted
> by my experiences working with symfony2 bundles, but I'll give a go at
> pointing out the most important aspects of modules that I think must be
> central to any planning of module support in ZF2:
>
>   1. Modules are not simply independent libraries of PHP code.  They are
>   all of the library code (controllers, models, forms, etc), api
>   documentation, user documentation, unit tests, public resources (images,
>   javascript, css, etc), configurations, command line tools, and any other
>   tools, files, classes, etc. related to that module's functionality.  All
> of
>   these things should be contained within a standardized module file format
>   and in a single parent directory.
>   2. Modules must have vendor namespaces.  I might create my own User
>   module, and that should be clearly distinguished from someone else's user
>   module.  Even though both of our modules are called User, the fact that
> mine
>   is bundled with the Epixa vendor namespace should mean that there are no
>   file naming conflicts nor are there any php namespace conflicts between
> the
>   two modules.  An example directory structure for this could be:
>   modules/Epixa/UserModule
>   3. The actual PHP classes within the module should follow standard
>   autoloading conventions so there are no restrictions on what types of
>   classes you use in a module (as is the case with the current resource
>   autoloader setup in zf1).  If I want an Epixa\UserModule\Entity\Session
>   namespace, I should be able to create it without additional
> configuration.
>    Same goes for an Epixa\UserModule\Foo\Bar namespace.
>   4. Modules should be able to extend certain pieces of functionality from
>   other modules.  This is likely to be a contentious issue, but I do think
> it
>   makes modules immensely more flexible and reusable.  This allows for not
>   only module dependency for open source modules, but it also allows the
> user
>   to create an installation-specific module that performs very specific
>   tweaking for the current application needs.
>   5. Modules should be independent units that are contained in their own
>   repositories.  Obviously there is no way to force people to make each of
>   their modules a unique repo, but the practice should be highly
> encouraged.
>    This is a fundamental requirement if we really want the community to
> come
>   together around third party module development.  People need to be able
> to
>   search for ZF2 modules on sites like github, and they should be finding
> blog
>   modules, user modules, etc. that are independent of each other but that
> can
>   work together.  Symfony handles this by specifically defining standards
> for
>   bundle development including how bundles should be packaged in
> repositories.
>   6. Application configuration should be able to import module
>   configurations.  So if my module has a routes config (as all modules
> should
>   have), then I should be able to import those routes into my application's
>   routing config with a simple addition to the application configuration or
>   bootstrapping.  Specifically with routes, I should be able to (but not
>   required to) prefix module routing schemes so as to avoid any conflicts
> that
>   might happen between module routes.  For example, in my application
> config,
>   I should be able to import my UserModule routes and say that I want those
>   routes prefixed by "/user" so that if I have a route defining something
> like
>   /view/:id, I would access that via the uri scheme /user/view/:id so I
> know
>   that does not conflict with a blog module's routes that may have a
> similar
>   scheme for viewing blog articles.
>   7. Copying or symlinking public module resources (images, css,
>   javascript) should be possible through the command line.  Of course
> someone
>   could get crazy with this and develop an entire UI in its own module for
>   handling this sort of thing (and I imagine someone will), but I don't
> really
>   think it is necessary for it to be a part of the ZF core.
>   8. Ideally modules could add command line functionality without having to
>   implement their own unique command line interfaces.
>   9. Modules are not fundamentally functionality centered around
>   controllers and views.  If a module exists solely to add command line
>   functionality, that should be possible.
>   10. The application itself should be little more than the glue necessary
>   to bring all of the application's module functionality together.  If you
>   don't want to use modules, that's cool.  Throw all of your functionality
> in
>   a single module and call it a day.
>
> I agree strongly with Kevin McArthur's point about a module/component
> system
> being a core part of the framework without destroying the loosely coupled
> nature that we're aiming for.  It can be done, and I think modules are such
> an important aspect of building reusable web apps in an MVC framework that
> we cannot settle for a mediocre implementation.  It's not just a matter of
> helping me write my apps better, either.  When you have a strong module
> system, it provides an extremely visible way for the community to get
> involved in writing really good ZF-based functionality, and it attracts new
> users as a result of that high visibility.  Symfony2 is still in beta and
> there are hundreds of bundles out there.  In time, it will be difficult to
> look for something like user-functionality or blog-functionality on github
> without coming across standalone Symfony2 bundles for those very things.  I
> desperately want the same to be true with Zend Framework.
>
> -Court
>
>
> On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel <[hidden email]
> >wrote:
>
> > Hi folks,
> >
> > The subject has been hinted on several times, but now it's getting its
> > very own thread. ZF1 already has modules (though I think they were
> > hacked in with 1.5?), but each module occurs at several places (a
> > default directory layout is assumed). There are the config files which
> > all reside in one common application directory, there are the
> > controllers/models/services/forms and viewscripts that reside in their
> > 'module directory', and there is the javascript/images that comes with
> > it, and usually is stored in some random directory in public/.
> >
> > [default & non modular]
> > Also, alongside of the modules are the non-modular controllers,
> > viewscripts, etc. This leads to inconsistencies in dispatching,
> > results in more code than would otherwise be required, and is weird
> > since all 'non modular stuff' can also be stored in the default
> > module. As such I'd propose to always put everything in a module, and
> > tell people that it's no problem to only utilize one module in total
> > if their app is too small to justify having multiple ones.
> >
> > Since 'default' is a keyword to php we cannot call the default module
> > "default". My suggestion would be to call it Core instead. Even if PHP
> > allowed for it, I think the naming of Core would better fit with the
> > idea of modules being selfcontained (see below).
> >
> > [a module?]
> > Then we come to what a module actually is. For the sake of scalability
> > and ease of sharing/distribution I would propose to put everything
> > that belongs to one module inside 1 module directory. Each module can
> > have its own config directory which Zend\App iterates over (this can
> > already be done through extending some of zend_app, but it's not
> > really you can expect from everybody), and media like javascript or
> > images can just be put in modules/modulename/public . If we choose to
> > do the latter we can simply document a default rewrite rule that maps
> > ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
> > cross operating system, and I suppose any decent kind of webserver (or
> > proxy/loadbalancer) supports something similar.
> >
> > [component framework]
> > ZF's strength is that it's always been a component framework. Having a
> > loosely coupled component framework enables users to utilize just a
> > few components without having to bother with the rest. I'd say this is
> > a very appealing feature that only few (if any) other mature
> > frameworks provide. It happens time after time after time that a new
> > user starts integrating only one or two components in his/her
> > application, and that over time they start utilizing the entire fw. As
> > such, I'm thinking that although we should have modules that are
> > selfcontained (and as such may be easily moved across applications),
> > we should not try to build an application framework. This would take a
> > lot of time, but more importantly, the chances of losing the fact that
> > components can be utilized standalone would vastly increase. This
> > means that imho ZF should /not/ be aware of what a user is.
> >
> > I do however think that building a layer /on top/ of ZF2 would be a
> > great thing. However time/resource wise I'd say we shouldn't do this
> > in ZF2.0.0, and it should probably be done as a standalone project. If
> > not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
> > Enrico), I see potential to revive Zym Engine (or have someone else
> > step up to take lead here) *. Allowing to build a layer on top of ZF
> > that converts it into an application framework should be a
> > consideration, and therefore I think we'd need to contemplate how one
> > can extend a module. Think of me building my Foo module that's meant
> > to be a blog, and someone - obviously not wanting to touch my code -
> > be able to just extend the module and override specific parts of it.
> >
> > * Obviously several contributors could try independently from each
> > other to set up such a layer, but I'm thinking ultimately only one
> > would 'win' the battle this would create. As usual contributors are
> > encouraged to collaborate and share knowledge.
> >
> > I've just noted down some ideas of my own - although inspired by
> > talking to lots of contributors. I'd be curious to know how you feel
> > above the points mentioned above. Also, feel free to address any
> > relevant issue when it comes to modularization that I have missed.
> >
> > Dolf
> > -- Freeaqingme
> >
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
> >
> >
> >
>

[Dolf Schimmel]

Tomáš,

While designing and reiterating over existing MVC codebases a lot of
mistakes were made (in short: way too much functionality was added).
Therefore there's a new page describing the requirements for an mvc
component here:
http://framework.zend.com/wiki/display/ZFDEV2/ZF2+MVC+requirements+brainstorming

Performance is one of the main goals there, so I wouldnt be too scared
for that. If you aim to focus the discussion more specifically at the
MVC parts, I'd suggest you take your arguments to the page linked
above. Although MVC, location of resources, our definition of modules
and the way we package it all is tightly related to each other, we
will have to split it up somewhere to keep it manageable. This is
where I would propose to draw a line for the time being.

Dolf
-- Freeaqingme

2011/6/1 Tomáš Fejfar <[hidden email]>:

> I agree. 100%.  One important addition I have is that even though ZF is a
> library of **loosely-coupled** classes, we should opt-out this concept for
> the MVC part. The MVC core is so specific that it does not need to be so
> loose. The MVC should be centered around extensibility, right...  but it
> should not choose loose-coupling over speed (or developer-experience). I'm
> bold enough to say 90% of developer out there **never** needed to extend any
> of the core MVC classes (with the exception of Router). We don't need to
> make the core super-customizable (say changing url separator from / to -),
> but instead we shoud look for "good-working defaults".
>
> Loose coupling is great thing but there are places where things like speed
> matter much more.
>
> If you know about any situations where developers needed only part of core
> MVC, let me know. I don't know any.
>
> P.S.: I've noticed now that I've been actually talking about the dispatch
> process, not MVC. I don't know it that well as other parts of ZF, but the
> only fact that empty request is much slower in ZF than in other frameworks
> shows the problem.
>
> On Wed, Jun 1, 2011 at 9:47 PM, Court Ewing <[hidden email]> wrote:
>>
>> Howdy,
>>
>> Doh.  I sent this originally to Dolf only.  Sorry for the duplicate, Dolf!
>>
>> Modules, in my opinion, are the single greatest problem with Zend
>> Framework
>> at this point, so I am ecstatic to see more discussion about them.  I
>> talked
>> a bit with Matthew about my feelings on the matter at tek11, but
>> unfortunately we were never able to sit down to discuss in more detail.
>>
>> The current implementation in ZF1 is so bad that it should not even be
>> used
>> as basis for any new module system that is created.  At the moment, they
>> serve only to better organize large projects and have basically zero
>> reusability, and that sucks... a lot.  I hate to make the comparison, but
>> I
>> think symfony2 _nailed_ the concept of modules (they call them bundles),
>> and
>> I also think that is one of the biggest reasons why so many developers are
>> adopting symfony2 already.  The bundle system is so flexible, and creating
>> reusable "modules" that can be installed into any standard symfony2 app
>> structure with very little configuration is so easy that hundreds of third
>> party bundles are already on github.
>>
>> The immediate benefit of this is that the community can focus on the best
>> bundle out there for any particular job, and you won't have thousands of
>> developers writing the same functionality over and over again.  A good
>> example of this is the UserBundle that is very popular on github right now
>> (offered by a community group called Friends Of Symfony) -- with it, you
>> will not have to write user login, logout, forget password, etc.
>> functionality again.  Sure, you all probably have this type of "module"
>> for
>> your own ZF projects, but you most likely wrote your own, and I am
>> supremely
>> confident that I couldn't drop your user module into my app.
>>
>> My opinion about how modules should be implemented in ZF is slightly
>> tainted
>> by my experiences working with symfony2 bundles, but I'll give a go at
>> pointing out the most important aspects of modules that I think must be
>> central to any planning of module support in ZF2:
>>
>>   1. Modules are not simply independent libraries of PHP code.  They are
>>   all of the library code (controllers, models, forms, etc), api
>>   documentation, user documentation, unit tests, public resources (images,
>>   javascript, css, etc), configurations, command line tools, and any other
>>   tools, files, classes, etc. related to that module's functionality.  All
>> of
>>   these things should be contained within a standardized module file
>> format
>>   and in a single parent directory.
>>   2. Modules must have vendor namespaces.  I might create my own User
>>   module, and that should be clearly distinguished from someone else's
>> user
>>   module.  Even though both of our modules are called User, the fact that
>> mine
>>   is bundled with the Epixa vendor namespace should mean that there are no
>>   file naming conflicts nor are there any php namespace conflicts between
>> the
>>   two modules.  An example directory structure for this could be:
>>   modules/Epixa/UserModule
>>   3. The actual PHP classes within the module should follow standard
>>   autoloading conventions so there are no restrictions on what types of
>>   classes you use in a module (as is the case with the current resource
>>   autoloader setup in zf1).  If I want an Epixa\UserModule\Entity\Session
>>   namespace, I should be able to create it without additional
>> configuration.
>>    Same goes for an Epixa\UserModule\Foo\Bar namespace.
>>   4. Modules should be able to extend certain pieces of functionality from
>>   other modules.  This is likely to be a contentious issue, but I do think
>> it
>>   makes modules immensely more flexible and reusable.  This allows for not
>>   only module dependency for open source modules, but it also allows the
>> user
>>   to create an installation-specific module that performs very specific
>>   tweaking for the current application needs.
>>   5. Modules should be independent units that are contained in their own
>>   repositories.  Obviously there is no way to force people to make each of
>>   their modules a unique repo, but the practice should be highly
>> encouraged.
>>    This is a fundamental requirement if we really want the community to
>> come
>>   together around third party module development.  People need to be able
>> to
>>   search for ZF2 modules on sites like github, and they should be finding
>> blog
>>   modules, user modules, etc. that are independent of each other but that
>> can
>>   work together.  Symfony handles this by specifically defining standards
>> for
>>   bundle development including how bundles should be packaged in
>> repositories.
>>   6. Application configuration should be able to import module
>>   configurations.  So if my module has a routes config (as all modules
>> should
>>   have), then I should be able to import those routes into my
>> application's
>>   routing config with a simple addition to the application configuration
>> or
>>   bootstrapping.  Specifically with routes, I should be able to (but not
>>   required to) prefix module routing schemes so as to avoid any conflicts
>> that
>>   might happen between module routes.  For example, in my application
>> config,
>>   I should be able to import my UserModule routes and say that I want
>> those
>>   routes prefixed by "/user" so that if I have a route defining something
>> like
>>   /view/:id, I would access that via the uri scheme /user/view/:id so I
>> know
>>   that does not conflict with a blog module's routes that may have a
>> similar
>>   scheme for viewing blog articles.
>>   7. Copying or symlinking public module resources (images, css,
>>   javascript) should be possible through the command line.  Of course
>> someone
>>   could get crazy with this and develop an entire UI in its own module for
>>   handling this sort of thing (and I imagine someone will), but I don't
>> really
>>   think it is necessary for it to be a part of the ZF core.
>>   8. Ideally modules could add command line functionality without having
>> to
>>   implement their own unique command line interfaces.
>>   9. Modules are not fundamentally functionality centered around
>>   controllers and views.  If a module exists solely to add command line
>>   functionality, that should be possible.
>>   10. The application itself should be little more than the glue necessary
>>   to bring all of the application's module functionality together.  If you
>>   don't want to use modules, that's cool.  Throw all of your functionality
>> in
>>   a single module and call it a day.
>>
>> I agree strongly with Kevin McArthur's point about a module/component
>> system
>> being a core part of the framework without destroying the loosely coupled
>> nature that we're aiming for.  It can be done, and I think modules are
>> such
>> an important aspect of building reusable web apps in an MVC framework that
>> we cannot settle for a mediocre implementation.  It's not just a matter of
>> helping me write my apps better, either.  When you have a strong module
>> system, it provides an extremely visible way for the community to get
>> involved in writing really good ZF-based functionality, and it attracts
>> new
>> users as a result of that high visibility.  Symfony2 is still in beta and
>> there are hundreds of bundles out there.  In time, it will be difficult to
>> look for something like user-functionality or blog-functionality on github
>> without coming across standalone Symfony2 bundles for those very things.
>>  I
>> desperately want the same to be true with Zend Framework.
>>
>> -Court
>>
>>
>> On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel
>> <[hidden email]>wrote:
>>
>> > Hi folks,
>> >
>> > The subject has been hinted on several times, but now it's getting its
>> > very own thread. ZF1 already has modules (though I think they were
>> > hacked in with 1.5?), but each module occurs at several places (a
>> > default directory layout is assumed). There are the config files which
>> > all reside in one common application directory, there are the
>> > controllers/models/services/forms and viewscripts that reside in their
>> > 'module directory', and there is the javascript/images that comes with
>> > it, and usually is stored in some random directory in public/.
>> >
>> > [default & non modular]
>> > Also, alongside of the modules are the non-modular controllers,
>> > viewscripts, etc. This leads to inconsistencies in dispatching,
>> > results in more code than would otherwise be required, and is weird
>> > since all 'non modular stuff' can also be stored in the default
>> > module. As such I'd propose to always put everything in a module, and
>> > tell people that it's no problem to only utilize one module in total
>> > if their app is too small to justify having multiple ones.
>> >
>> > Since 'default' is a keyword to php we cannot call the default module
>> > "default". My suggestion would be to call it Core instead. Even if PHP
>> > allowed for it, I think the naming of Core would better fit with the
>> > idea of modules being selfcontained (see below).
>> >
>> > [a module?]
>> > Then we come to what a module actually is. For the sake of scalability
>> > and ease of sharing/distribution I would propose to put everything
>> > that belongs to one module inside 1 module directory. Each module can
>> > have its own config directory which Zend\App iterates over (this can
>> > already be done through extending some of zend_app, but it's not
>> > really you can expect from everybody), and media like javascript or
>> > images can just be put in modules/modulename/public . If we choose to
>> > do the latter we can simply document a default rewrite rule that maps
>> > ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
>> > cross operating system, and I suppose any decent kind of webserver (or
>> > proxy/loadbalancer) supports something similar.
>> >
>> > [component framework]
>> > ZF's strength is that it's always been a component framework. Having a
>> > loosely coupled component framework enables users to utilize just a
>> > few components without having to bother with the rest. I'd say this is
>> > a very appealing feature that only few (if any) other mature
>> > frameworks provide. It happens time after time after time that a new
>> > user starts integrating only one or two components in his/her
>> > application, and that over time they start utilizing the entire fw. As
>> > such, I'm thinking that although we should have modules that are
>> > selfcontained (and as such may be easily moved across applications),
>> > we should not try to build an application framework. This would take a
>> > lot of time, but more importantly, the chances of losing the fact that
>> > components can be utilized standalone would vastly increase. This
>> > means that imho ZF should /not/ be aware of what a user is.
>> >
>> > I do however think that building a layer /on top/ of ZF2 would be a
>> > great thing. However time/resource wise I'd say we shouldn't do this
>> > in ZF2.0.0, and it should probably be done as a standalone project. If
>> > not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
>> > Enrico), I see potential to revive Zym Engine (or have someone else
>> > step up to take lead here) *. Allowing to build a layer on top of ZF
>> > that converts it into an application framework should be a
>> > consideration, and therefore I think we'd need to contemplate how one
>> > can extend a module. Think of me building my Foo module that's meant
>> > to be a blog, and someone - obviously not wanting to touch my code -
>> > be able to just extend the module and override specific parts of it.
>> >
>> > * Obviously several contributors could try independently from each
>> > other to set up such a layer, but I'm thinking ultimately only one
>> > would 'win' the battle this would create. As usual contributors are
>> > encouraged to collaborate and share knowledge.
>> >
>> > I've just noted down some ideas of my own - although inspired by
>> > talking to lots of contributors. I'd be curious to know how you feel
>> > above the points mentioned above. Also, feel free to address any
>> > relevant issue when it comes to modularization that I have missed.
>> >
>> > Dolf
>> > -- Freeaqingme
>> >
>> > --
>> > List: [hidden email]
>> > Info: http://framework.zend.com/archives
>> > Unsubscribe: [hidden email]
>> >
>> >
>> >
>
>

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

[Tomáš Fejfar]

1) Sorry, for broadening the topic.

2) Thanks for the link. Interresting discussion there.

3) Just to sum up and clarify - archieving such a complex modular
architecture will mean extreme amout of classes/processes during the
dispatch. That will cause even slower request speeds. And it *might* push ZF
away from ordinary developers, closer to corporations - where adding some
more memory, or creating a memcached server is as simple as to say it. But
ordinary developer, that use ZF either on shared hosting or on (already
pricy) VPS, will move to something which doesn't need uber-caching for empty
request :) And that will by IMO bad...
We should keep that in mind when discussing the new ways of doing things. As
many good ideas might be discarted because it would be too hard to make it
maintain the same coupling/extensibility criteria as the rest of the
framework.

4) One suggestion - more In-Topic: ZF should be modular by default. It would
save |------------| this much beginner's problems and StackOverflow
questions. I already searched for the reason there is default module
elsewhere than other modules (
http://stackoverflow.com/questions/1415984/default-modular-directory-structure-for-zend-framework-application/5788502#5788502)
and why you need any configuration to add new modules. And I still don't
understand - it's for me an obvious solution to add new module just by
copying the default one a renaming the directory.

2011/6/1 Dolf Schimmel <[hidden email]>

> Tomáš,
>
> While designing and reiterating over existing MVC codebases a lot of
> mistakes were made (in short: way too much functionality was added).
> Therefore there's a new page describing the requirements for an mvc
> component here:
>
> http://framework.zend.com/wiki/display/ZFDEV2/ZF2+MVC+requirements+brainstorming
>
> Performance is one of the main goals there, so I wouldnt be too scared
> for that. If you aim to focus the discussion more specifically at the
> MVC parts, I'd suggest you take your arguments to the page linked
> above. Although MVC, location of resources, our definition of modules
> and the way we package it all is tightly related to each other, we
> will have to split it up somewhere to keep it manageable. This is
> where I would propose to draw a line for the time being.
>
> Dolf
> -- Freeaqingme
>
> 2011/6/1 Tomáš Fejfar <[hidden email]>:
> > I agree. 100%.  One important addition I have is that even though ZF is a
> > library of **loosely-coupled** classes, we should opt-out this concept
> for
> > the MVC part. The MVC core is so specific that it does not need to be so
> > loose. The MVC should be centered around extensibility, right...  but it
> > should not choose loose-coupling over speed (or developer-experience).
> I'm
> > bold enough to say 90% of developer out there **never** needed to extend
> any
> > of the core MVC classes (with the exception of Router). We don't need to
> > make the core super-customizable (say changing url separator from / to
> -),
> > but instead we shoud look for "good-working defaults".
> >
> > Loose coupling is great thing but there are places where things like
> speed
> > matter much more.
> >
> > If you know about any situations where developers needed only part of
> core
> > MVC, let me know. I don't know any.
> >
> > P.S.: I've noticed now that I've been actually talking about the dispatch
> > process, not MVC. I don't know it that well as other parts of ZF, but the
> > only fact that empty request is much slower in ZF than in other
> frameworks
> > shows the problem.
> >
> > On Wed, Jun 1, 2011 at 9:47 PM, Court Ewing <[hidden email]>
> wrote:
> >>
> >> Howdy,
> >>
> >> Doh.  I sent this originally to Dolf only.  Sorry for the duplicate,
> Dolf!
> >>
> >> Modules, in my opinion, are the single greatest problem with Zend
> >> Framework
> >> at this point, so I am ecstatic to see more discussion about them.  I
> >> talked
> >> a bit with Matthew about my feelings on the matter at tek11, but
> >> unfortunately we were never able to sit down to discuss in more detail.
> >>
> >> The current implementation in ZF1 is so bad that it should not even be
> >> used
> >> as basis for any new module system that is created.  At the moment, they
> >> serve only to better organize large projects and have basically zero
> >> reusability, and that sucks... a lot.  I hate to make the comparison,
> but
> >> I
> >> think symfony2 _nailed_ the concept of modules (they call them bundles),
> >> and
> >> I also think that is one of the biggest reasons why so many developers
> are
> >> adopting symfony2 already.  The bundle system is so flexible, and
> creating
> >> reusable "modules" that can be installed into any standard symfony2 app
> >> structure with very little configuration is so easy that hundreds of
> third
> >> party bundles are already on github.
> >>
> >> The immediate benefit of this is that the community can focus on the
> best
> >> bundle out there for any particular job, and you won't have thousands of
> >> developers writing the same functionality over and over again.  A good
> >> example of this is the UserBundle that is very popular on github right
> now
> >> (offered by a community group called Friends Of Symfony) -- with it, you
> >> will not have to write user login, logout, forget password, etc.
> >> functionality again.  Sure, you all probably have this type of "module"
> >> for
> >> your own ZF projects, but you most likely wrote your own, and I am
> >> supremely
> >> confident that I couldn't drop your user module into my app.
> >>
> >> My opinion about how modules should be implemented in ZF is slightly
> >> tainted
> >> by my experiences working with symfony2 bundles, but I'll give a go at
> >> pointing out the most important aspects of modules that I think must be
> >> central to any planning of module support in ZF2:
> >>
> >>   1. Modules are not simply independent libraries of PHP code.  They are
> >>   all of the library code (controllers, models, forms, etc), api
> >>   documentation, user documentation, unit tests, public resources
> (images,
> >>   javascript, css, etc), configurations, command line tools, and any
> other
> >>   tools, files, classes, etc. related to that module's functionality.
>  All
> >> of
> >>   these things should be contained within a standardized module file
> >> format
> >>   and in a single parent directory.
> >>   2. Modules must have vendor namespaces.  I might create my own User
> >>   module, and that should be clearly distinguished from someone else's
> >> user
> >>   module.  Even though both of our modules are called User, the fact
> that
> >> mine
> >>   is bundled with the Epixa vendor namespace should mean that there are
> no
> >>   file naming conflicts nor are there any php namespace conflicts
> between
> >> the
> >>   two modules.  An example directory structure for this could be:
> >>   modules/Epixa/UserModule
> >>   3. The actual PHP classes within the module should follow standard
> >>   autoloading conventions so there are no restrictions on what types of
> >>   classes you use in a module (as is the case with the current resource
> >>   autoloader setup in zf1).  If I want an
> Epixa\UserModule\Entity\Session
> >>   namespace, I should be able to create it without additional
> >> configuration.
> >>    Same goes for an Epixa\UserModule\Foo\Bar namespace.
> >>   4. Modules should be able to extend certain pieces of functionality
> from
> >>   other modules.  This is likely to be a contentious issue, but I do
> think
> >> it
> >>   makes modules immensely more flexible and reusable.  This allows for
> not
> >>   only module dependency for open source modules, but it also allows the
> >> user
> >>   to create an installation-specific module that performs very specific
> >>   tweaking for the current application needs.
> >>   5. Modules should be independent units that are contained in their own
> >>   repositories.  Obviously there is no way to force people to make each
> of
> >>   their modules a unique repo, but the practice should be highly
> >> encouraged.
> >>    This is a fundamental requirement if we really want the community to
> >> come
> >>   together around third party module development.  People need to be
> able
> >> to
> >>   search for ZF2 modules on sites like github, and they should be
> finding
> >> blog
> >>   modules, user modules, etc. that are independent of each other but
> that
> >> can
> >>   work together.  Symfony handles this by specifically defining
> standards
> >> for
> >>   bundle development including how bundles should be packaged in
> >> repositories.
> >>   6. Application configuration should be able to import module
> >>   configurations.  So if my module has a routes config (as all modules
> >> should
> >>   have), then I should be able to import those routes into my
> >> application's
> >>   routing config with a simple addition to the application configuration
> >> or
> >>   bootstrapping.  Specifically with routes, I should be able to (but not
> >>   required to) prefix module routing schemes so as to avoid any
> conflicts
> >> that
> >>   might happen between module routes.  For example, in my application
> >> config,
> >>   I should be able to import my UserModule routes and say that I want
> >> those
> >>   routes prefixed by "/user" so that if I have a route defining
> something
> >> like
> >>   /view/:id, I would access that via the uri scheme /user/view/:id so I
> >> know
> >>   that does not conflict with a blog module's routes that may have a
> >> similar
> >>   scheme for viewing blog articles.
> >>   7. Copying or symlinking public module resources (images, css,
> >>   javascript) should be possible through the command line.  Of course
> >> someone
> >>   could get crazy with this and develop an entire UI in its own module
> for
> >>   handling this sort of thing (and I imagine someone will), but I don't
> >> really
> >>   think it is necessary for it to be a part of the ZF core.
> >>   8. Ideally modules could add command line functionality without having
> >> to
> >>   implement their own unique command line interfaces.
> >>   9. Modules are not fundamentally functionality centered around
> >>   controllers and views.  If a module exists solely to add command line
> >>   functionality, that should be possible.
> >>   10. The application itself should be little more than the glue
> necessary
> >>   to bring all of the application's module functionality together.  If
> you
> >>   don't want to use modules, that's cool.  Throw all of your
> functionality
> >> in
> >>   a single module and call it a day.
> >>
> >> I agree strongly with Kevin McArthur's point about a module/component
> >> system
> >> being a core part of the framework without destroying the loosely
> coupled
> >> nature that we're aiming for.  It can be done, and I think modules are
> >> such
> >> an important aspect of building reusable web apps in an MVC framework
> that
> >> we cannot settle for a mediocre implementation.  It's not just a matter
> of
> >> helping me write my apps better, either.  When you have a strong module
> >> system, it provides an extremely visible way for the community to get
> >> involved in writing really good ZF-based functionality, and it attracts
> >> new
> >> users as a result of that high visibility.  Symfony2 is still in beta
> and
> >> there are hundreds of bundles out there.  In time, it will be difficult
> to
> >> look for something like user-functionality or blog-functionality on
> github
> >> without coming across standalone Symfony2 bundles for those very things.
> >>  I
> >> desperately want the same to be true with Zend Framework.
> >>
> >> -Court
> >>
> >>
> >> On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel
> >> <[hidden email]>wrote:
> >>
> >> > Hi folks,
> >> >
> >> > The subject has been hinted on several times, but now it's getting its
> >> > very own thread. ZF1 already has modules (though I think they were
> >> > hacked in with 1.5?), but each module occurs at several places (a
> >> > default directory layout is assumed). There are the config files which
> >> > all reside in one common application directory, there are the
> >> > controllers/models/services/forms and viewscripts that reside in their
> >> > 'module directory', and there is the javascript/images that comes with
> >> > it, and usually is stored in some random directory in public/.
> >> >
> >> > [default & non modular]
> >> > Also, alongside of the modules are the non-modular controllers,
> >> > viewscripts, etc. This leads to inconsistencies in dispatching,
> >> > results in more code than would otherwise be required, and is weird
> >> > since all 'non modular stuff' can also be stored in the default
> >> > module. As such I'd propose to always put everything in a module, and
> >> > tell people that it's no problem to only utilize one module in total
> >> > if their app is too small to justify having multiple ones.
> >> >
> >> > Since 'default' is a keyword to php we cannot call the default module
> >> > "default". My suggestion would be to call it Core instead. Even if PHP
> >> > allowed for it, I think the naming of Core would better fit with the
> >> > idea of modules being selfcontained (see below).
> >> >
> >> > [a module?]
> >> > Then we come to what a module actually is. For the sake of scalability
> >> > and ease of sharing/distribution I would propose to put everything
> >> > that belongs to one module inside 1 module directory. Each module can
> >> > have its own config directory which Zend\App iterates over (this can
> >> > already be done through extending some of zend_app, but it's not
> >> > really you can expect from everybody), and media like javascript or
> >> > images can just be put in modules/modulename/public . If we choose to
> >> > do the latter we can simply document a default rewrite rule that maps
> >> > ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
> >> > cross operating system, and I suppose any decent kind of webserver (or
> >> > proxy/loadbalancer) supports something similar.
> >> >
> >> > [component framework]
> >> > ZF's strength is that it's always been a component framework. Having a
> >> > loosely coupled component framework enables users to utilize just a
> >> > few components without having to bother with the rest. I'd say this is
> >> > a very appealing feature that only few (if any) other mature
> >> > frameworks provide. It happens time after time after time that a new
> >> > user starts integrating only one or two components in his/her
> >> > application, and that over time they start utilizing the entire fw. As
> >> > such, I'm thinking that although we should have modules that are
> >> > selfcontained (and as such may be easily moved across applications),
> >> > we should not try to build an application framework. This would take a
> >> > lot of time, but more importantly, the chances of losing the fact that
> >> > components can be utilized standalone would vastly increase. This
> >> > means that imho ZF should /not/ be aware of what a user is.
> >> >
> >> > I do however think that building a layer /on top/ of ZF2 would be a
> >> > great thing. However time/resource wise I'd say we shouldn't do this
> >> > in ZF2.0.0, and it should probably be done as a standalone project. If
> >> > not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
> >> > Enrico), I see potential to revive Zym Engine (or have someone else
> >> > step up to take lead here) *. Allowing to build a layer on top of ZF
> >> > that converts it into an application framework should be a
> >> > consideration, and therefore I think we'd need to contemplate how one
> >> > can extend a module. Think of me building my Foo module that's meant
> >> > to be a blog, and someone - obviously not wanting to touch my code -
> >> > be able to just extend the module and override specific parts of it.
> >> >
> >> > * Obviously several contributors could try independently from each
> >> > other to set up such a layer, but I'm thinking ultimately only one
> >> > would 'win' the battle this would create. As usual contributors are
> >> > encouraged to collaborate and share knowledge.
> >> >
> >> > I've just noted down some ideas of my own - although inspired by
> >> > talking to lots of contributors. I'd be curious to know how you feel
> >> > above the points mentioned above. Also, feel free to address any
> >> > relevant issue when it comes to modularization that I have missed.
> >> >
> >> > Dolf
> >> > -- Freeaqingme
> >> >
> >> > --
> >> > List: [hidden email]
> >> > Info: http://framework.zend.com/archives
> >> > Unsubscribe: [hidden email]
> >> >
> >> >
> >> >
> >
> >
>

[Court Ewing]

Howdy,

I don't really see the need for a zero-configuration setup for modules, nor
do I think it would necessarily be a good thing.  Let's consider drupal as
an example (please, just stay with me for a second here).  Even Drupal,
which has one of the easiest-to-begin-using module setups out there, has
setup involved with each module.  They hide that setup behind a module
enable/disable UI.  With a proper module set up in ZF2, someone could
certainly develop a module that handles the installation of other modules in
a similar way, but I think that is a discussion to take up with community
members after the module setup is implemented; that really isn't a ZF2 core
issue.

I don't see how you could possibly have a "simply drop this module into this
directory and now it is fully operational within your existing app" setup.
 Modules will, at the very least, need to be known to the autoloader.  For
performance reasons alone, that is enough of a reason to require
configuration/setup of some kind.  Most modules will also have custom routes
and other configurations.  ZF could certainly automatically scan for those
at runtime, but you would at least be sacrificing performance to do so.

In addition, you may want to make a module available to other modules
without exposing all of its functionality through routes.  This could be
done by adding the module itself to the autoloader but not importing any of
the module's routes.  This is just the first use-case that popped into my
head that wouldn't be possible if modules were somehow automatically
installed just by existing in a specific directory.

So long as the most basic configuration necessary to install a module is as
simple as telling the application that a module does exist and at what
directory the module could be accessed, then I think we're in good shape.
 At that point, the amount of configuration necessary is really dependent on
the complexity of the module itself.

-Court

[robzienert]

I'm really glad to see this discussion starting up. As Court, I too,
strongly desire to see a good module system in ZF2.

As much as we have been pointing at Symfony2 as an example of how things
have been done well, I wholeheartedly agree with Dolf that we shouldn't be
stamping out a clone of their Bundle system. It works great for Symfony2,
but let's not get tunnel vision here.

One aspect of many modular PHP frameworks that I could see us trying to
improve is the concept that all modules are loaded each request. As Court
pointed out, modules can provide minimal functionality, such as a module
that offers only command-line tools. Loading these kinds of modules for an
HTTP request is simply unncessary, resulting in wasted resources.

I'd like to explore the concept of modules maintaining dependency lists, so
that our ModuleManager/ComponentManager or whatever can take the request
from Zend\Controller to map which modules to actually bootstrap and run,
similar in concept to how a class map works in autoloading, except a request
will load a package of modules. If you read the Facebook Engineering blog,
this similar to how FB handles module dependencies.

Expanding on Dolf's idea of core modules shipped with ZF: I like the idea,
but it may be a little far-fetched for an initial 2.0 release. A nice first
step would be to simply provide common interfaces for the community to work
from. For example, a user module will be something people want to tackle out
of the gate: Let's setup basic interfaces for a user module, i.e. a user
class will need getId(), getCredentials(), and so-on.

Approaching it this way could let the community drive the features and
functionality of these modules a little bit better and, once stable, could
be proposed for adoption into the actual ZF2 codebase.

- Rob


2011/6/1 Tomáš Fejfar <[hidden email]>

> 1) Sorry, for broadening the topic.
>
> 2) Thanks for the link. Interresting discussion there.
>
> 3) Just to sum up and clarify - archieving such a complex modular
> architecture will mean extreme amout of classes/processes during the
> dispatch. That will cause even slower request speeds. And it *might* push
> ZF
> away from ordinary developers, closer to corporations - where adding some
> more memory, or creating a memcached server is as simple as to say it. But
> ordinary developer, that use ZF either on shared hosting or on (already
> pricy) VPS, will move to something which doesn't need uber-caching for
> empty
> request :) And that will by IMO bad...
> We should keep that in mind when discussing the new ways of doing things.
> As
> many good ideas might be discarted because it would be too hard to make it
> maintain the same coupling/extensibility criteria as the rest of the
> framework.
>
> 4) One suggestion - more In-Topic: ZF should be modular by default. It
> would
> save |------------| this much beginner's problems and StackOverflow
> questions. I already searched for the reason there is default module
> elsewhere than other modules (
>
> http://stackoverflow.com/questions/1415984/default-modular-directory-structure-for-zend-framework-application/5788502#5788502
> )
> and why you need any configuration to add new modules. And I still don't
> understand - it's for me an obvious solution to add new module just by
> copying the default one a renaming the directory.
>
> 2011/6/1 Dolf Schimmel <[hidden email]>
>
> > Tomáš,
> >
> > While designing and reiterating over existing MVC codebases a lot of
> > mistakes were made (in short: way too much functionality was added).
> > Therefore there's a new page describing the requirements for an mvc
> > component here:
> >
> >
> http://framework.zend.com/wiki/display/ZFDEV2/ZF2+MVC+requirements+brainstorming
> >
> > Performance is one of the main goals there, so I wouldnt be too scared
> > for that. If you aim to focus the discussion more specifically at the
> > MVC parts, I'd suggest you take your arguments to the page linked
> > above. Although MVC, location of resources, our definition of modules
> > and the way we package it all is tightly related to each other, we
> > will have to split it up somewhere to keep it manageable. This is
> > where I would propose to draw a line for the time being.
> >
> > Dolf
> > -- Freeaqingme
> >
> > 2011/6/1 Tomáš Fejfar <[hidden email]>:
> > > I agree. 100%.  One important addition I have is that even though ZF is
> a
> > > library of **loosely-coupled** classes, we should opt-out this concept
> > for
> > > the MVC part. The MVC core is so specific that it does not need to be
> so
> > > loose. The MVC should be centered around extensibility, right...  but
> it
> > > should not choose loose-coupling over speed (or developer-experience).
> > I'm
> > > bold enough to say 90% of developer out there **never** needed to
> extend
> > any
> > > of the core MVC classes (with the exception of Router). We don't need
> to
> > > make the core super-customizable (say changing url separator from / to
> > -),
> > > but instead we shoud look for "good-working defaults".
> > >
> > > Loose coupling is great thing but there are places where things like
> > speed
> > > matter much more.
> > >
> > > If you know about any situations where developers needed only part of
> > core
> > > MVC, let me know. I don't know any.
> > >
> > > P.S.: I've noticed now that I've been actually talking about the
> dispatch
> > > process, not MVC. I don't know it that well as other parts of ZF, but
> the
> > > only fact that empty request is much slower in ZF than in other
> > frameworks
> > > shows the problem.
> > >
> > > On Wed, Jun 1, 2011 at 9:47 PM, Court Ewing <[hidden email]>
> > wrote:
> > >>
> > >> Howdy,
> > >>
> > >> Doh.  I sent this originally to Dolf only.  Sorry for the duplicate,
> > Dolf!
> > >>
> > >> Modules, in my opinion, are the single greatest problem with Zend
> > >> Framework
> > >> at this point, so I am ecstatic to see more discussion about them.  I
> > >> talked
> > >> a bit with Matthew about my feelings on the matter at tek11, but
> > >> unfortunately we were never able to sit down to discuss in more
> detail.
> > >>
> > >> The current implementation in ZF1 is so bad that it should not even be
> > >> used
> > >> as basis for any new module system that is created.  At the moment,
> they
> > >> serve only to better organize large projects and have basically zero
> > >> reusability, and that sucks... a lot.  I hate to make the comparison,
> > but
> > >> I
> > >> think symfony2 _nailed_ the concept of modules (they call them
> bundles),
> > >> and
> > >> I also think that is one of the biggest reasons why so many developers
> > are
> > >> adopting symfony2 already.  The bundle system is so flexible, and
> > creating
> > >> reusable "modules" that can be installed into any standard symfony2
> app
> > >> structure with very little configuration is so easy that hundreds of
> > third
> > >> party bundles are already on github.
> > >>
> > >> The immediate benefit of this is that the community can focus on the
> > best
> > >> bundle out there for any particular job, and you won't have thousands
> of
> > >> developers writing the same functionality over and over again.  A good
> > >> example of this is the UserBundle that is very popular on github right
> > now
> > >> (offered by a community group called Friends Of Symfony) -- with it,
> you
> > >> will not have to write user login, logout, forget password, etc.
> > >> functionality again.  Sure, you all probably have this type of
> "module"
> > >> for
> > >> your own ZF projects, but you most likely wrote your own, and I am
> > >> supremely
> > >> confident that I couldn't drop your user module into my app.
> > >>
> > >> My opinion about how modules should be implemented in ZF is slightly
> > >> tainted
> > >> by my experiences working with symfony2 bundles, but I'll give a go at
> > >> pointing out the most important aspects of modules that I think must
> be
> > >> central to any planning of module support in ZF2:
> > >>
> > >>   1. Modules are not simply independent libraries of PHP code.  They
> are
> > >>   all of the library code (controllers, models, forms, etc), api
> > >>   documentation, user documentation, unit tests, public resources
> > (images,
> > >>   javascript, css, etc), configurations, command line tools, and any
> > other
> > >>   tools, files, classes, etc. related to that module's functionality.
> >  All
> > >> of
> > >>   these things should be contained within a standardized module file
> > >> format
> > >>   and in a single parent directory.
> > >>   2. Modules must have vendor namespaces.  I might create my own User
> > >>   module, and that should be clearly distinguished from someone else's
> > >> user
> > >>   module.  Even though both of our modules are called User, the fact
> > that
> > >> mine
> > >>   is bundled with the Epixa vendor namespace should mean that there
> are
> > no
> > >>   file naming conflicts nor are there any php namespace conflicts
> > between
> > >> the
> > >>   two modules.  An example directory structure for this could be:
> > >>   modules/Epixa/UserModule
> > >>   3. The actual PHP classes within the module should follow standard
> > >>   autoloading conventions so there are no restrictions on what types
> of
> > >>   classes you use in a module (as is the case with the current
> resource
> > >>   autoloader setup in zf1).  If I want an
> > Epixa\UserModule\Entity\Session
> > >>   namespace, I should be able to create it without additional
> > >> configuration.
> > >>    Same goes for an Epixa\UserModule\Foo\Bar namespace.
> > >>   4. Modules should be able to extend certain pieces of functionality
> > from
> > >>   other modules.  This is likely to be a contentious issue, but I do
> > think
> > >> it
> > >>   makes modules immensely more flexible and reusable.  This allows for
> > not
> > >>   only module dependency for open source modules, but it also allows
> the
> > >> user
> > >>   to create an installation-specific module that performs very
> specific
> > >>   tweaking for the current application needs.
> > >>   5. Modules should be independent units that are contained in their
> own
> > >>   repositories.  Obviously there is no way to force people to make
> each
> > of
> > >>   their modules a unique repo, but the practice should be highly
> > >> encouraged.
> > >>    This is a fundamental requirement if we really want the community
> to
> > >> come
> > >>   together around third party module development.  People need to be
> > able
> > >> to
> > >>   search for ZF2 modules on sites like github, and they should be
> > finding
> > >> blog
> > >>   modules, user modules, etc. that are independent of each other but
> > that
> > >> can
> > >>   work together.  Symfony handles this by specifically defining
> > standards
> > >> for
> > >>   bundle development including how bundles should be packaged in
> > >> repositories.
> > >>   6. Application configuration should be able to import module
> > >>   configurations.  So if my module has a routes config (as all modules
> > >> should
> > >>   have), then I should be able to import those routes into my
> > >> application's
> > >>   routing config with a simple addition to the application
> configuration
> > >> or
> > >>   bootstrapping.  Specifically with routes, I should be able to (but
> not
> > >>   required to) prefix module routing schemes so as to avoid any
> > conflicts
> > >> that
> > >>   might happen between module routes.  For example, in my application
> > >> config,
> > >>   I should be able to import my UserModule routes and say that I want
> > >> those
> > >>   routes prefixed by "/user" so that if I have a route defining
> > something
> > >> like
> > >>   /view/:id, I would access that via the uri scheme /user/view/:id so
> I
> > >> know
> > >>   that does not conflict with a blog module's routes that may have a
> > >> similar
> > >>   scheme for viewing blog articles.
> > >>   7. Copying or symlinking public module resources (images, css,
> > >>   javascript) should be possible through the command line.  Of course
> > >> someone
> > >>   could get crazy with this and develop an entire UI in its own module
> > for
> > >>   handling this sort of thing (and I imagine someone will), but I
> don't
> > >> really
> > >>   think it is necessary for it to be a part of the ZF core.
> > >>   8. Ideally modules could add command line functionality without
> having
> > >> to
> > >>   implement their own unique command line interfaces.
> > >>   9. Modules are not fundamentally functionality centered around
> > >>   controllers and views.  If a module exists solely to add command
> line
> > >>   functionality, that should be possible.
> > >>   10. The application itself should be little more than the glue
> > necessary
> > >>   to bring all of the application's module functionality together.  If
> > you
> > >>   don't want to use modules, that's cool.  Throw all of your
> > functionality
> > >> in
> > >>   a single module and call it a day.
> > >>
> > >> I agree strongly with Kevin McArthur's point about a module/component
> > >> system
> > >> being a core part of the framework without destroying the loosely
> > coupled
> > >> nature that we're aiming for.  It can be done, and I think modules are
> > >> such
> > >> an important aspect of building reusable web apps in an MVC framework
> > that
> > >> we cannot settle for a mediocre implementation.  It's not just a
> matter
> > of
> > >> helping me write my apps better, either.  When you have a strong
> module
> > >> system, it provides an extremely visible way for the community to get
> > >> involved in writing really good ZF-based functionality, and it
> attracts
> > >> new
> > >> users as a result of that high visibility.  Symfony2 is still in beta
> > and
> > >> there are hundreds of bundles out there.  In time, it will be
> difficult
> > to
> > >> look for something like user-functionality or blog-functionality on
> > github
> > >> without coming across standalone Symfony2 bundles for those very
> things.
> > >>  I
> > >> desperately want the same to be true with Zend Framework.
> > >>
> > >> -Court
> > >>
> > >>
> > >> On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel
> > >> <[hidden email]>wrote:
> > >>
> > >> > Hi folks,
> > >> >
> > >> > The subject has been hinted on several times, but now it's getting
> its
> > >> > very own thread. ZF1 already has modules (though I think they were
> > >> > hacked in with 1.5?), but each module occurs at several places (a
> > >> > default directory layout is assumed). There are the config files
> which
> > >> > all reside in one common application directory, there are the
> > >> > controllers/models/services/forms and viewscripts that reside in
> their
> > >> > 'module directory', and there is the javascript/images that comes
> with
> > >> > it, and usually is stored in some random directory in public/.
> > >> >
> > >> > [default & non modular]
> > >> > Also, alongside of the modules are the non-modular controllers,
> > >> > viewscripts, etc. This leads to inconsistencies in dispatching,
> > >> > results in more code than would otherwise be required, and is weird
> > >> > since all 'non modular stuff' can also be stored in the default
> > >> > module. As such I'd propose to always put everything in a module,
> and
> > >> > tell people that it's no problem to only utilize one module in total
> > >> > if their app is too small to justify having multiple ones.
> > >> >
> > >> > Since 'default' is a keyword to php we cannot call the default
> module
> > >> > "default". My suggestion would be to call it Core instead. Even if
> PHP
> > >> > allowed for it, I think the naming of Core would better fit with the
> > >> > idea of modules being selfcontained (see below).
> > >> >
> > >> > [a module?]
> > >> > Then we come to what a module actually is. For the sake of
> scalability
> > >> > and ease of sharing/distribution I would propose to put everything
> > >> > that belongs to one module inside 1 module directory. Each module
> can
> > >> > have its own config directory which Zend\App iterates over (this can
> > >> > already be done through extending some of zend_app, but it's not
> > >> > really you can expect from everybody), and media like javascript or
> > >> > images can just be put in modules/modulename/public . If we choose
> to
> > >> > do the latter we can simply document a default rewrite rule that
> maps
> > >> > ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that
> works
> > >> > cross operating system, and I suppose any decent kind of webserver
> (or
> > >> > proxy/loadbalancer) supports something similar.
> > >> >
> > >> > [component framework]
> > >> > ZF's strength is that it's always been a component framework. Having
> a
> > >> > loosely coupled component framework enables users to utilize just a
> > >> > few components without having to bother with the rest. I'd say this
> is
> > >> > a very appealing feature that only few (if any) other mature
> > >> > frameworks provide. It happens time after time after time that a new
> > >> > user starts integrating only one or two components in his/her
> > >> > application, and that over time they start utilizing the entire fw.
> As
> > >> > such, I'm thinking that although we should have modules that are
> > >> > selfcontained (and as such may be easily moved across applications),
> > >> > we should not try to build an application framework. This would take
> a
> > >> > lot of time, but more importantly, the chances of losing the fact
> that
> > >> > components can be utilized standalone would vastly increase. This
> > >> > means that imho ZF should /not/ be aware of what a user is.
> > >> >
> > >> > I do however think that building a layer /on top/ of ZF2 would be a
> > >> > great thing. However time/resource wise I'd say we shouldn't do this
> > >> > in ZF2.0.0, and it should probably be done as a standalone project.
> If
> > >> > not initiated by Zend (more specifically the ZF team; Matthew, Ralph
> &
> > >> > Enrico), I see potential to revive Zym Engine (or have someone else
> > >> > step up to take lead here) *. Allowing to build a layer on top of ZF
> > >> > that converts it into an application framework should be a
> > >> > consideration, and therefore I think we'd need to contemplate how
> one
> > >> > can extend a module. Think of me building my Foo module that's meant
> > >> > to be a blog, and someone - obviously not wanting to touch my code -
> > >> > be able to just extend the module and override specific parts of it.
> > >> >
> > >> > * Obviously several contributors could try independently from each
> > >> > other to set up such a layer, but I'm thinking ultimately only one
> > >> > would 'win' the battle this would create. As usual contributors are
> > >> > encouraged to collaborate and share knowledge.
> > >> >
> > >> > I've just noted down some ideas of my own - although inspired by
> > >> > talking to lots of contributors. I'd be curious to know how you feel
> > >> > above the points mentioned above. Also, feel free to address any
> > >> > relevant issue when it comes to modularization that I have missed.
> > >> >
> > >> > Dolf
> > >> > -- Freeaqingme
> > >> >
> > >> > --
> > >> > List: [hidden email]
> > >> > Info: http://framework.zend.com/archives
> > >> > Unsubscribe: [hidden email]
> > >> >
> > >> >
> > >> >
> > >
> > >
> >
>

--
*Rob Zienert*
P: 248.207.4959
W: http://robzienert.com

[Gregory]

I'm still under the impression that routing should not be restricted
to a configuration file. For an application using the default routing
mechanism and all modules in the same directory (as in ZF1) then the
dispatcher can locate these controllers from the autoloader (with a
class path map the latter may not even be necessary). I currently
prefer using mod_rewrite to handle any additional routing.

For me, not providing an Application Framework would be no better than
what occurred previously in a lot of MVC frameworks that left the user
high and dry in regard to the 'M'. Basically this should be not much
more than providing appropriate convenience methods (reducing typing
etc) and a suggested (80% case) Model scenario (I'd even be OK with
something like what is suggested in the current QuickStart guide as a
basis of this).



--
Greg

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

[padraicb]

>I agree. 100%.  One important addition I have is that even though ZF is a
>library of **loosely-coupled** classes, we should opt-out this concept for
>the MVC part. The MVC core is so specific that it does not need to be so
>loose. The MVC should be centered around extensibility, right...  but it
>should not choose loose-coupling over speed (or developer-experience). I'm
>bold enough to say 90% of developer out there **never** needed to extend any
>of the core MVC classes (with the exception of Router). We don't need to
>make the core super-customizable (say changing url separator from / to -),
>but instead we shoud look for "good-working defaults".
>
>Loose coupling is great thing but there are places where things like speed
>matter much more.

This is an invalid argument for several reasons.

Firstly, loose coupling assists in unit testing, maintenance, and so on. Pick a
framework that isn't loosely coupled and you'll find a complete mess. I think
you're confusing loose coupling with one possible offshoot of that which
"flattens out" the responsibilities of a class (something I support). For
example, in ZF1 we refered to helpers from within controllers using some
interesting code. That was loosely coupled, yes, but it also breaks any number
of API rules (code inside a controller class is somewhat exceptional in that its
exposed internals must ALL be considered an API). Instead of referring to
internal properties or statics, controllers should have had access to one method
- getHelper(). It's one facet I hope to see in ZF2 - a tightly controlled API.
None of this having to chain together umpteem billion methods/properties to get
something from inside a controller or view.

Secondly, the idea that loose coupling imposes a speed penalty has no basis.
Zend Framework 1.10 with four changes (avoid Zend_App, disable ViewRenderer, use
autoloading exclusively, use core class preloading) is 12% faster than Symfony 2
in a Hello World benchmark. In other words, on an equal playing field ZF1 was
actually faster than Symfony 2 in terms of baseline MVC performance (should
re-run those benchmarks sometime ;)). Performance is far more likely to be
impacted by very obvious causes - the way you couple classes is rarely one of
them. Aside from the above there is always routing, plugin loading, and other
inefficiencies.

I fully anticipate ZF2 hanging Symfony 2's overblown and completely
out-of-context marketing on speed out to dry. Loose coupling is NOT slow.

>If you know about any situations where developers needed only part of core
>MVC, let me know. I don't know any.
>
>P.S.: I've noticed now that I've been actually talking about the dispatch
>process, not MVC. I don't know it that well as other parts of ZF, but the
>only fact that empty request is much slower in ZF than in other frameworks
>shows the problem.

See above. The problem with current benchmarks is that nobody tries to explain
them sensibly. Something may be slow, but unless you know WHY it's slow, that
information is out of context. Anyone with five minutes and the relevant WHY can
make ZF faster than most frameworks (of course, that cuts the other way too
doubtlessly ;)).

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team





________________________________
From: Tomáš Fejfar <[hidden email]>
To: Court Ewing <[hidden email]>
Cc: Dolf Schimmel <[hidden email]>; [hidden email]
Sent: Wed, June 1, 2011 9:15:41 PM
Subject: Re: [zf-contributors] Modules & ZF2. What will they be?!

I agree. 100%.  One important addition I have is that even though ZF is a
library of **loosely-coupled** classes, we should opt-out this concept for
the MVC part. The MVC core is so specific that it does not need to be so
loose. The MVC should be centered around extensibility, right...  but it
should not choose loose-coupling over speed (or developer-experience). I'm
bold enough to say 90% of developer out there **never** needed to extend any
of the core MVC classes (with the exception of Router). We don't need to
make the core super-customizable (say changing url separator from / to -),
but instead we shoud look for "good-working defaults".

Loose coupling is great thing but there are places where things like speed
matter much more.

If you know about any situations where developers needed only part of core
MVC, let me know. I don't know any.

P.S.: I've noticed now that I've been actually talking about the dispatch
process, not MVC. I don't know it that well as other parts of ZF, but the
only fact that empty request is much slower in ZF than in other frameworks
shows the problem.

On Wed, Jun 1, 2011 at 9:47 PM, Court Ewing <[hidden email]> wrote:

> Howdy,
>
> Doh.  I sent this originally to Dolf only.  Sorry for the duplicate, Dolf!
>
> Modules, in my opinion, are the single greatest problem with Zend Framework
> at this point, so I am ecstatic to see more discussion about them.  I
> talked
> a bit with Matthew about my feelings on the matter at tek11, but
> unfortunately we were never able to sit down to discuss in more detail.
>
> The current implementation in ZF1 is so bad that it should not even be used
> as basis for any new module system that is created.  At the moment, they
> serve only to better organize large projects and have basically zero
> reusability, and that sucks... a lot.  I hate to make the comparison, but I
> think symfony2 _nailed_ the concept of modules (they call them bundles),
> and
> I also think that is one of the biggest reasons why so many developers are
> adopting symfony2 already.  The bundle system is so flexible, and creating
> reusable "modules" that can be installed into any standard symfony2 app
> structure with very little configuration is so easy that hundreds of third
> party bundles are already on github.
>
> The immediate benefit of this is that the community can focus on the best
> bundle out there for any particular job, and you won't have thousands of
> developers writing the same functionality over and over again.  A good
> example of this is the UserBundle that is very popular on github right now
> (offered by a community group called Friends Of Symfony) -- with it, you
> will not have to write user login, logout, forget password, etc.
> functionality again.  Sure, you all probably have this type of "module" for
> your own ZF projects, but you most likely wrote your own, and I am
> supremely
> confident that I couldn't drop your user module into my app.
>
> My opinion about how modules should be implemented in ZF is slightly
> tainted
> by my experiences working with symfony2 bundles, but I'll give a go at
> pointing out the most important aspects of modules that I think must be
> central to any planning of module support in ZF2:
>
>   1. Modules are not simply independent libraries of PHP code.  They are
>   all of the library code (controllers, models, forms, etc), api
>   documentation, user documentation, unit tests, public resources (images,
>   javascript, css, etc), configurations, command line tools, and any other
>   tools, files, classes, etc. related to that module's functionality.  All
> of
>   these things should be contained within a standardized module file format
>   and in a single parent directory.
>   2. Modules must have vendor namespaces.  I might create my own User
>   module, and that should be clearly distinguished from someone else's user
>   module.  Even though both of our modules are called User, the fact that
> mine
>   is bundled with the Epixa vendor namespace should mean that there are no
>   file naming conflicts nor are there any php namespace conflicts between
> the
>   two modules.  An example directory structure for this could be:
>   modules/Epixa/UserModule
>   3. The actual PHP classes within the module should follow standard
>   autoloading conventions so there are no restrictions on what types of
>   classes you use in a module (as is the case with the current resource
>   autoloader setup in zf1).  If I want an Epixa\UserModule\Entity\Session
>   namespace, I should be able to create it without additional
> configuration.
>    Same goes for an Epixa\UserModule\Foo\Bar namespace.
>   4. Modules should be able to extend certain pieces of functionality from
>   other modules.  This is likely to be a contentious issue, but I do think
> it
>   makes modules immensely more flexible and reusable.  This allows for not
>   only module dependency for open source modules, but it also allows the
> user
>   to create an installation-specific module that performs very specific
>   tweaking for the current application needs.
>   5. Modules should be independent units that are contained in their own
>   repositories.  Obviously there is no way to force people to make each of
>   their modules a unique repo, but the practice should be highly
> encouraged.
>    This is a fundamental requirement if we really want the community to
> come
>   together around third party module development.  People need to be able
> to
>   search for ZF2 modules on sites like github, and they should be finding
> blog
>   modules, user modules, etc. that are independent of each other but that
> can
>   work together.  Symfony handles this by specifically defining standards
> for
>   bundle development including how bundles should be packaged in
> repositories.
>   6. Application configuration should be able to import module
>   configurations.  So if my module has a routes config (as all modules
> should
>   have), then I should be able to import those routes into my application's
>   routing config with a simple addition to the application configuration or
>   bootstrapping.  Specifically with routes, I should be able to (but not
>   required to) prefix module routing schemes so as to avoid any conflicts
> that
>   might happen between module routes.  For example, in my application
> config,
>   I should be able to import my UserModule routes and say that I want those
>   routes prefixed by "/user" so that if I have a route defining something
> like
>   /view/:id, I would access that via the uri scheme /user/view/:id so I
> know
>   that does not conflict with a blog module's routes that may have a
> similar
>   scheme for viewing blog articles.
>   7. Copying or symlinking public module resources (images, css,
>   javascript) should be possible through the command line.  Of course
> someone
>   could get crazy with this and develop an entire UI in its own module for
>   handling this sort of thing (and I imagine someone will), but I don't
> really
>   think it is necessary for it to be a part of the ZF core.
>   8. Ideally modules could add command line functionality without having to
>   implement their own unique command line interfaces.
>   9. Modules are not fundamentally functionality centered around
>   controllers and views.  If a module exists solely to add command line
>   functionality, that should be possible.
>   10. The application itself should be little more than the glue necessary
>   to bring all of the application's module functionality together.  If you
>   don't want to use modules, that's cool.  Throw all of your functionality
> in
>   a single module and call it a day.
>
> I agree strongly with Kevin McArthur's point about a module/component
> system
> being a core part of the framework without destroying the loosely coupled
> nature that we're aiming for.  It can be done, and I think modules are such
> an important aspect of building reusable web apps in an MVC framework that
> we cannot settle for a mediocre implementation.  It's not just a matter of
> helping me write my apps better, either.  When you have a strong module
> system, it provides an extremely visible way for the community to get
> involved in writing really good ZF-based functionality, and it attracts new
> users as a result of that high visibility.  Symfony2 is still in beta and
> there are hundreds of bundles out there.  In time, it will be difficult to
> look for something like user-functionality or blog-functionality on github
> without coming across standalone Symfony2 bundles for those very things.  I
> desperately want the same to be true with Zend Framework.
>
> -Court
>
>
> On Wed, Jun 1, 2011 at 2:52 PM, Dolf Schimmel <[hidden email]
> >wrote:
>
> > Hi folks,
> >
> > The subject has been hinted on several times, but now it's getting its
> > very own thread. ZF1 already has modules (though I think they were
> > hacked in with 1.5?), but each module occurs at several places (a
> > default directory layout is assumed). There are the config files which
> > all reside in one common application directory, there are the
> > controllers/models/services/forms and viewscripts that reside in their
> > 'module directory', and there is the javascript/images that comes with
> > it, and usually is stored in some random directory in public/.
> >
> > [default & non modular]
> > Also, alongside of the modules are the non-modular controllers,
> > viewscripts, etc. This leads to inconsistencies in dispatching,
> > results in more code than would otherwise be required, and is weird
> > since all 'non modular stuff' can also be stored in the default
> > module. As such I'd propose to always put everything in a module, and
> > tell people that it's no problem to only utilize one module in total
> > if their app is too small to justify having multiple ones.
> >
> > Since 'default' is a keyword to php we cannot call the default module
> > "default". My suggestion would be to call it Core instead. Even if PHP
> > allowed for it, I think the naming of Core would better fit with the
> > idea of modules being selfcontained (see below).
> >
> > [a module?]
> > Then we come to what a module actually is. For the sake of scalability
> > and ease of sharing/distribution I would propose to put everything
> > that belongs to one module inside 1 module directory. Each module can
> > have its own config directory which Zend\App iterates over (this can
> > already be done through extending some of zend_app, but it's not
> > really you can expect from everybody), and media like javascript or
> > images can just be put in modules/modulename/public . If we choose to
> > do the latter we can simply document a default rewrite rule that maps
> > ^media/$1/$2 to ../modules/$1/public/$2. This is a solution that works
> > cross operating system, and I suppose any decent kind of webserver (or
> > proxy/loadbalancer) supports something similar.
> >
> > [component framework]
> > ZF's strength is that it's always been a component framework. Having a
> > loosely coupled component framework enables users to utilize just a
> > few components without having to bother with the rest. I'd say this is
> > a very appealing feature that only few (if any) other mature
> > frameworks provide. It happens time after time after time that a new
> > user starts integrating only one or two components in his/her
> > application, and that over time they start utilizing the entire fw. As
> > such, I'm thinking that although we should have modules that are
> > selfcontained (and as such may be easily moved across applications),
> > we should not try to build an application framework. This would take a
> > lot of time, but more importantly, the chances of losing the fact that
> > components can be utilized standalone would vastly increase. This
> > means that imho ZF should /not/ be aware of what a user is.
> >
> > I do however think that building a layer /on top/ of ZF2 would be a
> > great thing. However time/resource wise I'd say we shouldn't do this
> > in ZF2.0.0, and it should probably be done as a standalone project. If
> > not initiated by Zend (more specifically the ZF team; Matthew, Ralph &
> > Enrico), I see potential to revive Zym Engine (or have someone else
> > step up to take lead here) *. Allowing to build a layer on top of ZF
> > that converts it into an application framework should be a
> > consideration, and therefore I think we'd need to contemplate how one
> > can extend a module. Think of me building my Foo module that's meant
> > to be a blog, and someone - obviously not wanting to touch my code -
> > be able to just extend the module and override specific parts of it.
> >
> > * Obviously several contributors could try independently from each
> > other to set up such a layer, but I'm thinking ultimately only one
> > would 'win' the battle this would create. As usual contributors are
> > encouraged to collaborate and share knowledge.
> >
> > I've just noted down some ideas of my own - although inspired by
> > talking to lots of contributors. I'd be curious to know how you feel
> > above the points mentioned above. Also, feel free to address any
> > relevant issue when it comes to modularization that I have missed.
> >
> > Dolf
> > -- Freeaqingme
> >
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
> >
> >
> >
>