Quantcast

ZF2 Modules Ideas

classic Classic list List threaded Threaded
84 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ZF2 Modules Ideas

weierophinney
Administrator
Here is a draft of my ideas surrounding modules:

 * A module is a namespace.

 * Inside a module can be any code at all -- it is not limited to MVC
   artifacts such as controllers and view templates.

 * A module _should_ contain a file containing a class map for use with
   the ClassMapAutoloader. However, files should be loadable using
   PSR-0 standards via the StandardAutoloader.

 * A module _should_ contain a configuration file that can be merged
   with the application configuration. Most likely, configuration keys
   should be namespaced. Configuration might include, but not be limited
   to:
    * DI definitions and/or configuration for module-specific classes
    * Routing tables

 * Each module should contain a Configuration _class_. This class will
   be consumed by Zend\Tool (or similar), and do the following:
    * Merge the module classmap with the application classmap, if
      present.
    * Merge module configuration with application configuration.
    * Define application event listeners to register with the
      StaticEventManager.
    * Describe application assets (which the tool would then move to the
      document root into the appropriate directories, under the given
      namespace).
    * Describe the location of view templates (to optionally move to a
      global view directory).
    * etc.

 * A module package _could_ be installed as follows:

    prompt> zf2 install module <packagefile>

   Alternately, the developer could inflate the package manually, and
   specify a directory:

    prompt> zf2 install module path/to/module/

 * A module will _usually_ live in the "application" directory, but does
   not need to, so long as the application configuration and bootstrap
   are known to the installer.

 * For packaging purposes, a module _could_ also have a metadata file
   describing the module and used by a packaging tool to build the
   package.

    prompt> zf2 create package path/to/module/

   This file _should_ also indicate specific dependencies on other
   modules and/or libraries (including ZF2 itself or individual
   components in ZF2).

As a working example, I have used the above idea of modules in the
zf-quickstart "features/zf2-di-compiler" branch:
   
 * http://bit.ly/n8ET1v 
   
Both "Application" and "QuickStart" are considered modules in this
application.  The only pieces I haven't addressed in this example is the
module-specific configuration file and configuration class.

Guiding the above were the following goals:

 * Make modules as flexible as possible
 * Encourage following established ZF2 coding and naming standards in
   3rd party code targetting or consuming ZF2
 * Discourage dynamic discovery in preference of installation (which
   should improve performance over ZF1 modular applications)
 * Encourage re-use and extension of modules

Discuss!

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

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Kevin McArthur-2
Responses inline:

> Here is a draft of my ideas surrounding modules:
>
>   * A module is a namespace.
(like a php namepsace, or more generically? Can you give an example of a
name)
>   * Inside a module can be any code at all -- it is not limited to MVC
>     artifacts such as controllers and view templates.
+1
>   * A module _should_ contain a file containing a class map for use with
>     the ClassMapAutoloader. However, files should be loadable using
>     PSR-0 standards via the StandardAutoloader.
+1 (except for PSR-0, which I'm not sure is workable if components are
overridden)
>   * A module _should_ contain a configuration file that can be merged
>     with the application configuration. Most likely, configuration keys
>     should be namespaced. Configuration might include, but not be limited
>     to:
>      * DI definitions and/or configuration for module-specific classes
+1
>      * Routing tables
+1 (I presume one can inject a routing class with the DI too?)

>   * Each module should contain a Configuration _class_. This class will
>     be consumed by Zend\Tool (or similar), and do the following:
-1 to by Zend\Tool. Should be part of the architecture. I'd still seek
to support drag+drop installations.
>      * Merge the module classmap with the application classmap, if
>        present.
+1 but automatic (tighty tie in zend cache and create a requirement for
a writeable directory)

This should be versioned so that for example if you downloaded a
component, you could write another component to customize it. For
example we have a standard set of ecommerce functionality, but override
significant portions of it with each client site. This use case should
be supported.
>      * Merge module configuration with application configuration.
+1 if you're talking about a runtime/automatic merge rather than a
one-time merge.
>      * Define application event listeners to register with the
>        StaticEventManager.
+1
>      * Describe application assets (which the tool would then move to the
>        document root into the appropriate directories, under the given
>        namespace).
+1 to assets, -1 to them moving. assets should remain in the component
in situ.
>      * Describe the location of view templates (to optionally move to a
>        global view directory).
+1 to views, again -1 to moving them.
>      * etc.


>   * A module package _could_ be installed as follows:
>
>      prompt>  zf2 install module<packagefile>
+1 to a downloader working this way. -1 to having to install modules
(copying them into place should be sufficient)
>     Alternately, the developer could inflate the package manually, and
>     specify a directory:
>
>      prompt>  zf2 install module path/to/module/
-1 i dont think we need an explicit install action, rather the core can
detect changes, do automatic configuration and cache results.
>   * A module will _usually_ live in the "application" directory, but does
>     not need to, so long as the application configuration and bootstrap
>     are known to the installer.
I'd propose scrapping the concept of the application/* directories in
favor of the component model. Rather than application, something like
/components/org.example.package/ or /components/org.example.package.phar

This will prevent the need to maintain two entirely different
application contexts and make it more seamless (more default) to
download and install components.

>   * For packaging purposes, a module _could_ also have a metadata file
>     describing the module and used by a packaging tool to build the
>     package.
>
>      prompt>  zf2 create package path/to/module/
>
>     This file _should_ also indicate specific dependencies on other
>     modules and/or libraries (including ZF2 itself or individual
>     components in ZF2).
+1 (spec should include md5 or similar of files to detect if they've
been modified and crypto-signing of the manifest as an option)
> As a working example, I have used the above idea of modules in the
> zf-quickstart "features/zf2-di-compiler" branch:
>
>   * http://bit.ly/n8ET1v
>
> Both "Application" and "QuickStart" are considered modules in this
> application.  The only pieces I haven't addressed in this example is the
> module-specific configuration file and configuration class.

Will check that out. (havent yet)

> Guiding the above were the following goals:
>
>   * Make modules as flexible as possible
+1
>   * Encourage following established ZF2 coding and naming standards in
>     3rd party code targetting or consuming ZF2
+1
>   * Discourage dynamic discovery in preference of installation (which
>     should improve performance over ZF1 modular applications)
-1 I think we can do dynamic discovery with tightly coupled caching and
see it perform.
>   * Encourage re-use and extension of modules
+1
> Discuss!
>
+10

Thanks Matthew,

--

Kevin

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

robertbasic
In reply to this post by weierophinney
I agree with almost everything, but:

- the moving of view files. Err, no. I want to explain the HTML guy only
once where are the files he can play with. Application global view files are
needed, like layouts, footer, whatnot, but moving files from a module to
"global" is just me screaming even more at the designers.

- the module metadata file should be required at all times. Author, github
repo link, descriptions, dependencies... Even if there will be no tool that
will read that file, still it might turn out helpful for developers using
that module.

- even if not required, do give a general guidance on how to layout
documentation, API documentation, unit tests... for any module.

- unit tests. How will unit tests for a module be run?
prompt> phpunit application/MyBlog/tests/phpunit.xml
or
prompt> zf2 module test module_name

- will there be a metadata file or some such of installed/enabled modules on
the application level?

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

weierophinney
Administrator
-- Robert Basic <[hidden email]> wrote
(on Monday, 15 August 2011, 10:34 PM +0200):
> I agree with almost everything, but:
>
> - the moving of view files. Err, no. I want to explain the HTML guy only
> once where are the files he can play with. Application global view files are
> needed, like layouts, footer, whatnot, but moving files from a module to
> "global" is just me screaming even more at the designers.

You can Kevin both brought this up... and evidently missed the word
"optionally". The reason I mentioned it as a potential target is I know
a number of folks working in client-oriented shops or corporations with
a division between back-end and UI/UX developers, and for some of these
people, they'd rather have the view templates in a common directory
instead of per-module. This allows them to offer it as a subdirectory
checkout of SVN, or as a git submodule.

Again, I suggest this only as _optional_ functionality.

> - the module metadata file should be required at all times. Author, github
> repo link, descriptions, dependencies... Even if there will be no tool that
> will read that file, still it might turn out helpful for developers using
> that module.

I tend to agree.

> - even if not required, do give a general guidance on how to layout
> documentation, API documentation, unit tests... for any module.

Absolutely.

> - unit tests. How will unit tests for a module be run?
> prompt> phpunit application/MyBlog/tests/phpunit.xml
> or
> prompt> zf2 module test module_name

I'd expect, actually, this:

    prompt> cd path/to/module/tests
    prompt> phpunit

as that's the simplest case for us to support. :)

> - will there be a metadata file or some such of installed/enabled modules on
> the application level?

Probably. This is part of why I suggested this being a Zend\Tool target,
as it has some mechanisms for storing application metadata already.

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

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Artur Bodera
In reply to this post by weierophinney
On Mon, Aug 15, 2011 at 9:48 PM, Matthew Weier O'Phinney
<[hidden email]>wrote:

>   * Inside a module can be any code at all -- it is not limited to MVC
>   artifacts such as controllers and view templates.
>
Should be able to include assets in public dir (i.e. images, js, etc.)


>
>  * A module _should_ contain a file containing a class map for use with
>   the ClassMapAutoloader. However, files should be loadable using
>   PSR-0 standards via the StandardAutoloader.
>
+1


>  * A module _should_ contain a configuration file that can be merged
>   with the application configuration. Most likely, configuration keys
>   should be namespaced. Configuration might include, but not be limited
>   to:
>
How about configuring resources?
E-commerce module could have its own cache, db, translate.

But it could also "require" these resources to be configured at application
level. For example e-commerce mod requires a working db-connection and
translate, which is then fed with translation strings loaded from module's
dir.

Also - current ZF1/ZF2 module boostrap implementation causes resources to be
double (tripple, quadruple) bootstrapped (bug), which break i.e. session
(because there are 3 session instances). Resources should be loaded
on-demand and module bootstrap should only load resources that have not been
loaded yet (unless module requires double-loading for some reason).



   * DI definitions and/or configuration for module-specific classes
>    * Routing tables
>

+ loading priority stack

i.e. "security module" loading before "e-commerce module"



>  * Each module should contain a Configuration _class_. This class will
>   be consumed by Zend\Tool (or similar), and do the following:
>    * Merge the module classmap with the application classmap, if
>      present.
>    * Merge module configuration with application configuration.
>    * Define application event listeners to register with the
>      StaticEventManager.
>    * Describe application assets (which the tool would then move to the
>      document root into the appropriate directories, under the given
>      namespace).
>    * Describe the location of view templates (to optionally move to a
>      global view directory).
>    * etc.
>

+ install scripts


>
>  * A module package _could_ be installed as follows:
>      prompt> zf2 install module <packagefile>
>     Alternately, the developer could inflate the package manually, and
>   specify a directory:
>      prompt> zf2 install module path/to/module/
>

+1 to manual install, but Kevin is forgetting about more complex modules
that might need to have their database schema set up, or warm up cache, or
download dependencies, or do a code analysis and create an ACL map, or
whatever. In case of a module being manually installed (read:
extracted/copied from archive), a config flag could prevent it from working
before the install script is invoked (vide wordpress installation process).



>  * A module will _usually_ live in the "application" directory, but does
>   not need to, so long as the application configuration and bootstrap
>   are known to the installer.
>

-1 to that
Common (configurable) paths are a must.
I don't see any benefit of having modules scattered across filesystem.


 * For packaging purposes, a module _could_ also have a metadata file
>   describing the module and used by a packaging tool to build the
>   package.
>
>    prompt> zf2 create package path/to/module/
>
>   This file _should_ also indicate specific dependencies on other
>   modules and/or libraries (including ZF2 itself or individual
>   components in ZF2).
>

Metadata should be mandatory for submission to the directory.
It could be handled with a generator (cli survey/wizard) or web-based tool.

In any case, dependencies (or lack thereof), purpose, maintainer email etc.
are very important.

 * Make modules as flexible as possible
>  * Encourage following established ZF2 coding and naming standards in
>   3rd party code targetting or consuming ZF2
>  * Discourage dynamic discovery in preference of installation (which
>   should improve performance over ZF1 modular applications)
>

I'd leave out dynamic discovery altogether. If there is a need for keeping a
specific module on a separate filesystem, some "exotic" path or load it in a
non-standard way, it should be hacked away by the developer.

I thought of module installation as being somewhat stateless: there is no
need to "enable" them really, just extract from an archive and you're
set. Unfortunately routing, events and service calls won't work without the
main app knowing (and loading) them.

I believe the most reasonable option is a dir scan of
(application/modules/*) which will find the manifest or a Bootstrap.php and
init what there is to be init. This process can be then accelerated by
compiling an aggregate of all DI, routes, translation matrices etc.
(symphony2 does that).

A.

--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

robertbasic
In reply to this post by weierophinney
On Mon, Aug 15, 2011 at 10:45 PM, Matthew Weier O'Phinney
<[hidden email]>wrote:

> You can Kevin both brought this up... and evidently missed the word
> "optionally". The reason I mentioned it as a potential target is I know
> a number of folks working in client-oriented shops or corporations with
> a division between back-end and UI/UX developers, and for some of these
> people, they'd rather have the view templates in a common directory
> instead of per-module. This allows them to offer it as a subdirectory
> checkout of SVN, or as a git submodule.
>
> Again, I suggest this only as _optional_ functionality.
>

Ah, a valid use case. You are correct. But the directory layout must
resemble the "original" layout. E.g.:
 - application/MyBlog/View/scripts
 - application/MyBlog/View/assets
goes to:
 - some/path/MyBlog/View/scripts
 - some/path/MyBlog/View/assets


>
> > - unit tests. How will unit tests for a module be run?
> > prompt> phpunit application/MyBlog/tests/phpunit.xml
> > or
> > prompt> zf2 module test module_name
>
> I'd expect, actually, this:
>
>    prompt> cd path/to/module/tests
>    prompt> phpunit
>
> as that's the simplest case for us to support. :)


Sounds good :) we just need to be sure that we provide a "dummy"
phpunit.xml.dist and a TestBootstrap.php.dist so it's easy to start writing
tests.

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

till-2
In reply to this post by Artur Bodera
On Mon, Aug 15, 2011 at 10:52 PM, Artur Bodera <[hidden email]> wrote:
> On Mon, Aug 15, 2011 at 9:48 PM, Matthew Weier O'Phinney
> <[hidden email]>wrote:
>
>>   * Inside a module can be any code at all -- it is not limited to MVC
>>   artifacts such as controllers and view templates.
>>
> Should be able to include assets in public dir (i.e. images, js, etc.)

This is a great idea and it's good to see something official on that topic.

We kept it rather simple:

All of our modules contain:

controllers/
etc/
layouts/
library/
models/
www/
tmp/
var/
views/

I know my directories don't match up the official guide, but you get the idea.

Our library directory also contains "vendor" where we distribute
externals dependencies.

In the end, we link it together using svn:externals (and
git-submodules in one case).

Till

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

robzienert
In reply to this post by Artur Bodera
On Mon, Aug 15, 2011 at 3:52 PM, Artur Bodera <[hidden email]> wrote:

<snip>

+ loading priority stack
>
> i.e. "security module" loading before "e-commerce module"
>
>
+1

There needs to be some way to assign priorities to when a module is loaded.
Would this be done in the module Configuration class, or would we make it
part of the installer? My opinion is that it makes more sense for it to be
in the Configuration class, but then we'd need to have some way of
recompiling the module manifest outside of runtime.

- Rob
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

robertbasic
In reply to this post by Artur Bodera
On Mon, Aug 15, 2011 at 10:52 PM, Artur Bodera <[hidden email]> wrote:

>
>
> >
> >  * A module package _could_ be installed as follows:
> >      prompt> zf2 install module <packagefile>
> >     Alternately, the developer could inflate the package manually, and
> >   specify a directory:
> >      prompt> zf2 install module path/to/module/
> >
>
> +1 to manual install, but Kevin is forgetting about more complex modules
> that might need to have their database schema set up, or warm up cache, or
> download dependencies, or do a code analysis and create an ACL map, or
> whatever. In case of a module being manually installed (read:
> extracted/copied from archive), a config flag could prevent it from working
> before the install script is invoked (vide wordpress installation process).
>
>
Would it be insane to leave it to the module developer to provide the
complete install script by himself? Have a MyBlog/bin directory which holds
myblog.php script which is based on Zend\Tool (or whatever will be used for
the scripting process). Thus, it's the developer's responsibility to deal
with the dependencies, SQL files, to check for required PHP extensions, load
dummy data, move CSS/JS/image files and whatever the developer actually
wants to happen in the install process... We could actually leave the zf2
module install module_name step, which would call the MyBlog/bin/myblog.php
script and possibly inject the global app configuration, the list of already
installed modules (for dependency checks) and what not.

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

robzienert
I don't think this is insane. Quite the opposite in fact: It seems makes a
lot more sense that the developer be responsible for providing the
installation process. I would assume that Zend\Tool could have a baseline
install script that developers would work from that satisfies the most basic
of operations to get a module up and running.

Taking it one step further: How would module updates work? Let's say you
download MyBlog v1.0.0, but then v1.1.0 is released which includes SQL
deltas: How are these handled?

- Rob

On Mon, Aug 15, 2011 at 4:09 PM, Robert Basic <[hidden email]>wrote:

> On Mon, Aug 15, 2011 at 10:52 PM, Artur Bodera <[hidden email]> wrote:
> >
> >
> > >
> > >  * A module package _could_ be installed as follows:
> > >      prompt> zf2 install module <packagefile>
> > >     Alternately, the developer could inflate the package manually, and
> > >   specify a directory:
> > >      prompt> zf2 install module path/to/module/
> > >
> >
> > +1 to manual install, but Kevin is forgetting about more complex modules
> > that might need to have their database schema set up, or warm up cache,
> or
> > download dependencies, or do a code analysis and create an ACL map, or
> > whatever. In case of a module being manually installed (read:
> > extracted/copied from archive), a config flag could prevent it from
> working
> > before the install script is invoked (vide wordpress installation
> process).
> >
> >
> Would it be insane to leave it to the module developer to provide the
> complete install script by himself? Have a MyBlog/bin directory which holds
> myblog.php script which is based on Zend\Tool (or whatever will be used for
> the scripting process). Thus, it's the developer's responsibility to deal
> with the dependencies, SQL files, to check for required PHP extensions,
> load
> dummy data, move CSS/JS/image files and whatever the developer actually
> wants to happen in the install process... We could actually leave the zf2
> module install module_name step, which would call the MyBlog/bin/myblog.php
> script and possibly inject the global app configuration, the list of
> already
> installed modules (for dependency checks) and what not.
>
> --
> ~Robert Basic;
> http://robertbasic.com/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

robertbasic
On Mon, Aug 15, 2011 at 11:13 PM, Rob Zienert <[hidden email]> wrote:

> I don't think this is insane. Quite the opposite in fact: It seems makes a
> lot more sense that the developer be responsible for providing the
> installation process. I would assume that Zend\Tool could have a baseline
> install script that developers would work from that satisfies the most basic
> of operations to get a module up and running.
>
> Taking it one step further: How would module updates work? Let's say you
> download MyBlog v1.0.0, but then v1.1.0 is released which includes SQL
> deltas: How are these handled?
>
>
have a "zf2 update module module_name" which calls MyBlog/bin/myblog.php
--update (or updatemyblog.php or whatever), again passing in the general app
config and what else is needed, plus, from the metadata file of the
currently installed modules, it reads in the version number of the currently
installed module and sends that to the module update script - and it is up
to the developer to decide what will he do with the updating from 1.0.0 to
1.2.0 and from 1.1.0 to 1.2.0.

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Artur Bodera
In reply to this post by robzienert
>
> Would it be insane to leave it to the module developer to provide the
> complete install script by himself? Have a MyBlog/bin directory which holds
> myblog.php script which is based on Zend\Tool (or whatever will be used for
> the scripting process). Thus, it's the developer's responsibility to deal
> with the dependencies, SQL files, to check for required PHP extensions, load
> dummy data, move CSS/JS/image files and whatever the developer actually
> wants to happen in the install process... We could actually leave the zf2
> module install module_name step, which would call the MyBlog/bin/myblog.php
> script and possibly inject the global app configuration, the list of already
> installed modules (for dependency checks) and what not.


Sorry Robert, but you're giving developers some ease-of-use (zf install
module) and then taking it away one step later (manual installation).

It's either automatic or manual. Not both.

Wordpress didn't have installation hooks at first, but they quickly fixed it
;-)
Drupal: same story. Started with a drop-in, now they have install scripts,
update scripts and hooks (events) that can be implemented (listened to) by
each and every piece of the puzzle.

We don't have to test that out. It's already used in different products and
it works. So let's stick to it.

Of course not all modules will have those. Some will be just fine with just
copying the files over.

Also: requirement checks should include php extension checks. This way
module installation can be aborted if zend tool detects, that a required
extension is missing (thus saving us exceptions or fatal errors).

On Mon, Aug 15, 2011 at 11:13 PM, Rob Zienert <[hidden email]> wrote:

> I don't think this is insane. Quite the opposite in fact: It seems makes a
> lot more sense that the developer be responsible for providing the
> installation process. I would assume that Zend\Tool could have a baseline
> install script that developers would work from that satisfies the most basic
> of operations to get a module up and running.
> Taking it one step further: How would module updates work? Let's say you
> download MyBlog v1.0.0, but then v1.1.0 is released which includes SQL
> deltas: How are these handled?
>
> Zend\Db\Introspect ? ;-)

If we have it by ZF2 (doubtful) then we should do it.

If not, I'd start with just giving devs those install scripts.
They could implement it manually in install/update hook/event. It's not that
hard.


--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

robertbasic
On Mon, Aug 15, 2011 at 11:25 PM, Artur Bodera <[hidden email]> wrote:
>
> Sorry Robert, but you're giving developers some ease-of-use (zf install
> module) and then taking it away one step later (manual installation).
>
> It's either automatic or manual. Not both.
>
>
No need to apologize, I'm just throwing random ideas out :P actually, I'm
just making it "harder" for the developer of the said module. Other
developers, who will be using said module, won't notice a thing :)


> Wordpress didn't have installation hooks at first, but they quickly fixed
> it ;-)
> Drupal: same story. Started with a drop-in, now they have install scripts,
> update scripts and hooks (events) that can be implemented (listened to) by
> each and every piece of the puzzle.
>
>
We don't have to test that out. It's already used in different products and
> it works. So let's stick to it.
>
>
Then we need to tell exactly what hooks/events will be there and in what
order will they be executed/called.

Of course not all modules will have those. Some will be just fine with just
> copying the files over.
>

How will this module then be "registered" with the application in the global
metadata file? The developer will have to add it by hand?

--
~Robert Basic;
http://robertbasic.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Artur Bodera
On Mon, Aug 15, 2011 at 11:35 PM, Robert Basic <[hidden email]>wrote:

>
> Of course not all modules will have those. Some will be just fine with just
>> copying the files over.
>>
>
> How will this module then be "registered" with the application in the
> global metadata file? The developer will have to add it by hand?
>
>
Nope.
If we want to make it easy as a pie, it will be just:

> zf install formbuilder

Just like in drupal.... and magic happens in the background.

Update?

> zf install formbuilder
  -- or --
> zf upgrade formbuilder


External repo:
> zf install http://foobar.com/mymodules/formbuilder.zfmod

External manifest containing package url:
> zf install http://foobar.com/mymodules/formbuilder.zfmanifest

That's from the app developer side. Module developer has to handle each
situation until we have some "helpers" in place -  like database schema
migration. Besides DB, what would happen to images or JS that have been
updated. Should it overwrite them? What about local changes?

Actually, now that I think of it... it should be somewhat controlled. I'd go
berserk if one module would upgrade nicely, while another overwrite all of
my files after upgrading  :-)


A.

--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Tim Fountain
In reply to this post by weierophinney
Firstly, some suggested use cases:

1. User module - imagine you'd written a bog standard users module,
including registration, account validation, forgotten password etc.;
something you'd want to reuse in other applications. The component would
require minimal configuration, it's interaction with the rest of the app
would be some module-specific routes and a User model that is exposed to the
app.

2. Wordpress - imagine Wordpress was rewritten as a ZF module. I would be be
grouped up into further modules (in the ZF1 sense of the word), include unit
tests, require installation, routes, over-rideable templates, configuration
and have various points of integration with the rest of the app.


I've spent some time working on this area in ZF1. I tried a few different
approaches, the one that worked best was actually using the resources part
of Zend_Application. I know this isn't what it was designed for, but it
allows for modules to be bootstrapped, configuration added and various other
things.

Some more comments inline:


On 15 August 2011 20:48, Matthew Weier O'Phinney <[hidden email]> wrote:

> Here is a draft of my ideas surrounding modules:
>
>  * A module is a namespace.
>
>  * Inside a module can be any code at all -- it is not limited to MVC
>   artifacts such as controllers and view templates.
>

Would they generally mirror the ZF2 application structure?


 * Each module should contain a Configuration _class_. This class will
>   be consumed by Zend\Tool (or similar), and do the following:
>
>    * Describe application assets (which the tool would then move to the
>      document root into the appropriate directories, under the given
>      namespace).
>

I think the modules should be self-contained, the tool shouldn't move
anything out. Perhaps creating symlinks would be a reasonable compromise,
although I know this is an issue on Windows. Better I think would be if ZF
had a default route for serving module-specific assets.

Eg. let's go with my 2nd use case above of Wordpress, so we'll assume the
namespace for the module is "wordpress". ZF then knows to route /wordpress/*
to application/modules/wordpress/public/*. Routing static assets through PHP
is not something you want to do in production, but this could be addressed
on deployment or via Zend Tool on demand.



>  * A module package _could_ be installed as follows:
>
>    prompt> zf2 install module <packagefile>
>

I think it would be really great if this command could take a git URL as
well instead of a packagefile (something which is used extensively for Rails
plugins - a big reason why there are some many of them on github). This also
gives some nice options for updating modules from source.

Related to installation, I think the modules need to be able to optionally
define some sort of installation process, run on first install. Sticking
with my Wordpress example, that module would need to at minimum create some
database tables (which means it needs access to existing resources in the
app), and ideally walk the user through some configuration.

If we go down this route, modules should be able to define an uninstallation
process as well.


 * A module will _usually_ live in the "application" directory, but does
>   not need to, so long as the application configuration and bootstrap
>   are known to the installer.
>

Requiring modules to always live in application/modules would be a perfectly
reasonable requirement IMO, if this simplifies things.


--
Tim Fountain
http://tfountain.co.uk/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

weierophinney
Administrator
In reply to this post by Kevin McArthur-2
-- Kevin McArthur <[hidden email]> wrote
(on Monday, 15 August 2011, 01:05 PM -0700):

> >  * A module will _usually_ live in the "application" directory, but does
> >    not need to, so long as the application configuration and bootstrap
> >    are known to the installer.
> I'd propose scrapping the concept of the application/* directories
> in favor of the component model. Rather than application, something
> like /components/org.example.package/ or
> /components/org.example.package.phar
>
> This will prevent the need to maintain two entirely different
> application contexts and make it more seamless (more default) to
> download and install components.

This makes sense, and helps ensure that the application-specific coding
is kept separate from the 3rd-party modules installed.

Maybe something like:

    application/
        SomeCustomCode/
            Controller/
                Index.php
                Guestbook.php
            Model/
                Guestbook.php
                GuestbookTable.php
            /* etc. */
    modules/
        net.mwop.acl/
            Roles.php
            Role.php
        net.mwop.user/
            Controller/
                Login.php
                Register.php
            /* uses net.mwop.acl */

Is that what you're thinking?

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

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Anthony Shireman
In reply to this post by robertbasic
On Mon, Aug 15, 2011 at 2:19 PM, Robert Basic <[hidden email]>wrote:

> On Mon, Aug 15, 2011 at 11:13 PM, Rob Zienert <[hidden email]> wrote:
>
> >
> > Taking it one step further: How would module updates work? Let's say you
> > download MyBlog v1.0.0, but then v1.1.0 is released which includes SQL
> > deltas: How are these handled?
> >
> >
> have a "zf2 update module module_name" which calls MyBlog/bin/myblog.php
> --update (or updatemyblog.php or whatever), again passing in the general
> app
> config and what else is needed, plus, from the metadata file of the
> currently installed modules, it reads in the version number of the
> currently
> installed module and sends that to the module update script - and it is up
> to the developer to decide what will he do with the updating from 1.0.0 to
> 1.2.0 and from 1.1.0 to 1.2.0.
>
>
I like the Magento method of handling DB updates (which I'm sure many won't
care for) each time the version changes, there's a migration script that
handles all the DB alteration for that module. So if you go from 1.0.0 to
1.2.0 there should be a module_update_sql_1.0.0_to_1.2.0.php file (or some
better naming convention). If there's an intermediary, those are processed
first (1.0.0_to_1.1.0.php, then 1.1.0_to_1.2.0.php). Just a thought to toss
out.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Kevin McArthur-2
In reply to this post by weierophinney
> Is that what you're thinking?

Nope. I'm thinking we live by our own model and forgo the application
mvc dirs entirely.

Mine would look like,

/
/public/
/public/.htaccess
/public/index.php (loader)
/application/
/application/bootstrap.php
/application/config.ini <-- local server configuration items, most
feature config occurs in components
/writable/
/writable/caches
/writable/sessions
/writable/useruploads
/writable/components/ca.stormtide.commerce/<--- dir that components can
create/register for writing and that is basedir protected by default.
/components/
/components/ca.stormtide.local/ <-- local overrides following the
component model overriding procedure.
/components/ca.stormtide.local/Controllers
/components/ca.stormtide.local/Layouts
/components/ca.stormtide.local/Views
/components/ca.stormtide.local/<etc>
/components/ca.stormtide.commerce/ <--- in development
/components/ca.stormtide.commerce/manifest.file
/components/ca.stormtide.commerce/Controllers
/components/ca.stormtide.commerce/Layouts
/components/ca.stormtide.commerce/Views
/components/ca.stormtide.commerce/<etc>
/components/ca.stormtide.othercomponent.phar <-- once a completed
module, packed as phar

I see the benefit being that it leaves only one standard way to do it
(and reduces the learning complexity of using components, as you'll be
used to developing them from day one or visa versa for those who start
with components and then learn to develop)

I see the use case for development being slightly different with the
standard case being one of drop in a standard code component, (like
maybe a base template with all the usual hooks registered, and form
components set up), then defining a custom set of overrides to that
component.

Drupal developers do something similar to this when they start with a
blank theme like 'Zen' or 'Fusion' and this type of workflow could
capture a huge amount of 'i know some php' designers into the zend
ecosystem.

--

Kevin

On 11-08-15 03:12 PM, Matthew Weier O'Phinney wrote:

> -- Kevin McArthur<[hidden email]>  wrote
> (on Monday, 15 August 2011, 01:05 PM -0700):
>>>   * A module will _usually_ live in the "application" directory, but does
>>>     not need to, so long as the application configuration and bootstrap
>>>     are known to the installer.
>> I'd propose scrapping the concept of the application/* directories
>> in favor of the component model. Rather than application, something
>> like /components/org.example.package/ or
>> /components/org.example.package.phar
>>
>> This will prevent the need to maintain two entirely different
>> application contexts and make it more seamless (more default) to
>> download and install components.
> This makes sense, and helps ensure that the application-specific coding
> is kept separate from the 3rd-party modules installed.
>
> Maybe something like:
>
>      application/
>          SomeCustomCode/
>              Controller/
>                  Index.php
>                  Guestbook.php
>              Model/
>                  Guestbook.php
>                  GuestbookTable.php
>              /* etc. */
>      modules/
>          net.mwop.acl/
>              Roles.php
>              Role.php
>          net.mwop.user/
>              Controller/
>                  Login.php
>                  Register.php
>              /* uses net.mwop.acl */
>
> Is that what you're thinking?
>

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

EvanDotPro
Big +1 for reverse-TLD directories for modules (ie. pro.evan.acl)...
The obvious benefit is that namespace conflicts (directory, not PHP)
would never be an issue. Less importantly, in a directory view, all
modules from a common author will be grouped together. Those without a
TLD (or who choose not to use theirs) could even use something like
com.github.username.projectname.

However, if we go that route, I wonder what would be the decided
convention for mapping that sort of namespace to the PHP namespace to
be used in the code? Something like pro\evan\acl or
com\github\username\projectname seems like a natural choice, but comes
off a little excessive.

--
Evan Coury

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ZF2 Modules Ideas

Gregory
In reply to this post by weierophinney
At times I think it would be better if directory names could just be lower case compatible. I think lithium ended up that route.

Sent from my iPhone

On Aug 15, 2011, at 5:12 PM, Matthew Weier O'Phinney <[hidden email]> wrote:

> -- Kevin McArthur <[hidden email]> wrote
> (on Monday, 15 August 2011, 01:05 PM -0700):
>>> * A module will _usually_ live in the "application" directory, but does
>>>   not need to, so long as the application configuration and bootstrap
>>>   are known to the installer.
>> I'd propose scrapping the concept of the application/* directories
>> in favor of the component model. Rather than application, something
>> like /components/org.example.package/ or
>> /components/org.example.package.phar
>>
>> This will prevent the need to maintain two entirely different
>> application contexts and make it more seamless (more default) to
>> download and install components.
>
> This makes sense, and helps ensure that the application-specific coding
> is kept separate from the 3rd-party modules installed.
>
> Maybe something like:
>
>    application/
>        SomeCustomCode/
>            Controller/
>                Index.php
>                Guestbook.php
>            Model/
>                Guestbook.php
>                GuestbookTable.php
>            /* etc. */
>    modules/
>        net.mwop.acl/
>            Roles.php
>            Role.php
>        net.mwop.user/
>            Controller/
>                Login.php
>                Register.php
>            /* uses net.mwop.acl */
>
> Is that what you're thinking?
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

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


12345
Loading...