RFC: ZF2 Modules

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

RFC: ZF2 Modules

akrabat
Hi all,

The Modules discussion thread seems to have fizzled out, so how do we move forward with it? I'm thinking that we need an RFC on the wiki. Anyone want to write one?! :)  

Fortunately, I saved you the effort of having to come up with an excuse on why you couldn't possibly do it and did it myself:

    http://framework.zend.com/wiki/x/wYCbAg


From what I could tell reading the thread, we're mostly in agreement with Matthew's original post, so I started with that and tidied it up, adding additions from the thread. Items that I added, was not sure we have consensus on, or think need more work I've put in red.


There's a few related points that I think we need to discuss:

* Extending another module's class for local use within a module is easy enough, but do we need to handle extending in one module for use in another, unaware, module? If so, how would this work?

* Should we upgrade some of the _should_ requirements to _must_? If so, which ones?

* Did I miss anything?


I'm not sure what the process from here is (I think we're making it up as we go along personally!) Obviously, we need to finalise the items in red. I'm happy to update the RFC document based on comments received and try to ensure we reach consensus. I think we'll then be able to formally vote on it.

Your thoughts and comments are appreciated. As with the other RFC, please comment by replying to this thread on the mailing list and I'll update the wiki as required.


Regards,

Rob...


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Kevin McArthur-2
Hey Rob,

I'm just waiting for Matthew's response to everything. We had a mailing
list failure for several days too, so that might be more blamed for the
discussion fizzling than actually people no longer being interested.
>
>     * Discourage dynamic discovery in preference of installation
>       (which should improve performance over ZF1 modular applications)
>
I'm not sure where you got this from, but my modular proposal is dynamic
based with a hard coupling to disk cache.

>     * A module is a directory (usually under the modules/ folder)
>       which can be named any valid name.
>

A module in my mind is a .phar or similar archive format, which may --
in development -- be a directory. Naming is still contentious, with some
favoring a org.example.component naming model and others favouring a
FIFO registration of plain names. PSR-0 compatibility is still contentious.

>     * All class files within the module /should/ be namespaced.
>
I'd argue to *must* here, but with the caveat that classes could be
provided in other namespaces than the module itself.

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

Still under contention. If we go dynamic discovery and use a more
comprehensive modular approach that involves hierarchical overriding,
we'll probably want to replace the classmapautoloader with something
more like a standardized manifest file more analogous to the .NET global
assembly cache concept.

> A module /should/ contain a configuration file that can be merged with
> the application configuration. Configuration keys should be namespaced
> and might include, but not be limited to:
>
>     * DI definitions and/or configuration for module-specific classes
>     * Routing tables
>
I don't believe this needs to be a configuration file, rather the module
system will have a standard set of hooks that will allow the module the
opportunity to run whatever initialization code is needed, which may or
may not be the injection of site-wide configuration values.

> A module /may/ contain a Configuration class that will be consumed by
> Zend\Tool (or similar) during installation/upgrade 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
>       /optionally/ move (or symlink or add .htaccess rules) 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).
>     * Describe the loading priority and dependent modules.
>     * etc. (Whatever else the developer chooses to implement!)
>

I don't believe we've decided on a 'merged configuration' approach vs a
dynamically compiled dependency approach. I think this files-based
approach will result in a lot of totally un-necessary system admin tasks
that are both laborious and have the potential to introduce serious
user-error and learning curve. A dynamic/manifest approach will slightly
increase the learning curve for module development, but drastically
reduce use-only requirements. (I envision module admin possible from a
ftp client)


> Installing/upgrading modules
>
While a nice Zend_Tool downloader/file manager is a nice-to-have
feature. I'm not sure its a dependency, nor that we need explicit
installation/upgrade/etc phases. ZF install <package> should be analgous
to zf download <package>

ZF remove <package> should be analogous to rm packagename.phar



--

Overall, I think we need to look at the best and worst of modular
architectures in the market place and really consider usability for
end-users going forward. That means module admin should be essentially
drag-and-drop simple, and provide admin-ui-installation possibilities.

I'm not a fan of the bolted ZF1.0-style modules + incremental changes
approach. I think we need to toss the zf1.0 architectural ideas out the
window and start again from the best innovations seen in the
marketplace. IMO that means looking at symphony bundles, .net gac, java
jars, ruby gems, etc and picking what works from them and leaving out
whats crap about them to arrive at something uniquely ZF2.

--

Kevin




On 11-08-29 09:08 AM, Rob Allen wrote:

> Hi all,
>
> The Modules discussion thread seems to have fizzled out, so how do we move forward with it? I'm thinking that we need an RFC on the wiki. Anyone want to write one?! :)
>
> Fortunately, I saved you the effort of having to come up with an excuse on why you couldn't possibly do it and did it myself:
>
>      http://framework.zend.com/wiki/x/wYCbAg
>
>
>  From what I could tell reading the thread, we're mostly in agreement with Matthew's original post, so I started with that and tidied it up, adding additions from the thread. Items that I added, was not sure we have consensus on, or think need more work I've put in red.
>
>
> There's a few related points that I think we need to discuss:
>
> * Extending another module's class for local use within a module is easy enough, but do we need to handle extending in one module for use in another, unaware, module? If so, how would this work?
>
> * Should we upgrade some of the _should_ requirements to _must_? If so, which ones?
>
> * Did I miss anything?
>
>
> I'm not sure what the process from here is (I think we're making it up as we go along personally!) Obviously, we need to finalise the items in red. I'm happy to update the RFC document based on comments received and try to ensure we reach consensus. I think we'll then be able to formally vote on it.
>
> Your thoughts and comments are appreciated. As with the other RFC, please comment by replying to this thread on the mailing list and I'll update the wiki as required.
>
>
> Regards,
>
> Rob...
>
Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

padraicb
In reply to this post by akrabat
> I'm not sure what the process from here is (I think we're making it up
> as we go along personally!) Obviously, we need to finalise the items in red.
> I'm happy to update the RFC document based on comments received and try to
> ensure we reach consensus. I think we'll then be able to formally vote on
> it.

We are making it up ;). I'll add something to the dev meeting agenda for Wednesday to formally adopt the RFC workflow for architectural proposals. Alas, few comments on my large email about it last week so either people are still ruminating or have no disagreements with what I proposed. Which is fine by me, of course ;). Will reply on your RFC tomorrow when I have more time but thanks for writing it! We were missing something to anchor the discussion around.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Kevin McArthur-2
> We were missing something to anchor the discussion around.
We were? Theres quite a number of outstanding questions on the mailing
list. I fail to see how the wiki format (now with a ton of what I
consider incorrect info on it) helps anything. If anything its going to
increase the friction on this process.

In the line of other, zfprops on the topic:

http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements
http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Milestones
http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
http://framework.zend.com/wiki/pages/viewpage.action?pageId=43745438

Etc..

The mailing list failure was pretty bad but, lack of process isn't why
this discussion stalled.. We've now got the mailing list, blog, weekly
summaries, etc...  I'll note there's no post on the zf2 dev blog and
that the summaries are now out of date and dont reflect the
post-irc-meeting discussion.

A lack of process isn't the problem.

--

Kevin



On 11-08-29 10:05 AM, Pádraic Brady wrote:

>> I'm not sure what the process from here is (I think we're making it up
>> as we go along personally!) Obviously, we need to finalise the items in red.
>> I'm happy to update the RFC document based on comments received and try to
>> ensure we reach consensus. I think we'll then be able to formally vote on
>> it.
> We are making it up ;). I'll add something to the dev meeting agenda for Wednesday to formally adopt the RFC workflow for architectural proposals. Alas, few comments on my large email about it last week so either people are still ruminating or have no disagreements with what I proposed. Which is fine by me, of course ;). Will reply on your RFC tomorrow when I have more time but thanks for writing it! We were missing something to anchor the discussion around.
>
>  
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

padraicb
Kevin,

Rob's topic for the RFC was ZF2 Modules. Not distribution, MVC or anything else. To date, while there is much ML discussion, as the MVC prototypes hopefully bear down on us from Matthew/Ralph, we need to have some agreement documented on Modules. That is the entire purpose of an RFC - to formalise what we agree to do once and for all by inviting comment and debate and bringing it to a final conclusion with a vote. Rob's added an RFC (a Request For Comment) so we have something to refer to and document how the discussion will shape Modules. The community can criticise it, comment on it, create a rival RFC if they think it's too far off-base. Just so long as it results in a decision so we can move on to proposing/writing actual source code and not be bringing up the same topic every few months into infinity ;).
If you believe there are outstanding questions, then let's get on with the show. I'm pretty sure Rob has every intention of modifying the RFC depending on the feedback he sees on this topic.

Regarding the outstanding weekly summary, as I understand from mentioning it to Ralph, Matthew is out sick today and the guys were hoping to get out a dev release for the HTTP stuff added in master. There's bound to be a few unexpected misses over time, so long as it doesn't become a trend :P.

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



----- Original Message -----

> From: Kevin McArthur <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Monday, August 29, 2011 6:25 PM
> Subject: Re: [zf-contributors] RFC: ZF2 Modules
>
>>  We were missing something to anchor the discussion around.
> We were? Theres quite a number of outstanding questions on the mailing list. I
> fail to see how the wiki format (now with a ton of what I consider incorrect
> info on it) helps anything. If anything its going to increase the friction on
> this process.
>
> In the line of other, zfprops on the topic:
>
> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements
> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Milestones
> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
> http://framework.zend.com/wiki/pages/viewpage.action?pageId=43745438
>
> Etc..
>
> The mailing list failure was pretty bad but, lack of process isn't why this
> discussion stalled.. We've now got the mailing list, blog, weekly summaries,
> etc...  I'll note there's no post on the zf2 dev blog and that the
> summaries are now out of date and dont reflect the post-irc-meeting discussion.
>
> A lack of process isn't the problem.
>
> --
>
> Kevin
>
>
>
> On 11-08-29 10:05 AM, Pádraic Brady wrote:
>>>  I'm not sure what the process from here is (I think we're
> making it up
>>>  as we go along personally!) Obviously, we need to finalise the items in
> red.
>>>  I'm happy to update the RFC document based on comments received and
> try to
>>>  ensure we reach consensus. I think we'll then be able to formally
> vote on
>>>  it.
>>  We are making it up ;). I'll add something to the dev meeting agenda
> for Wednesday to formally adopt the RFC workflow for architectural proposals.
> Alas, few comments on my large email about it last week so either people are
> still ruminating or have no disagreements with what I proposed. Which is fine by
> me, of course ;). Will reply on your RFC tomorrow when I have more time but
> thanks for writing it! We were missing something to anchor the discussion
> around.
>>
>>    Pádraic Brady
>>  http://blog.astrumfutura.com
>>  http://www.survivethedeepend.com
>>  Zend Framework Community Review Team
>>
>
> -- List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Kevin McArthur-2
> Rob's topic for the RFC was ZF2 Modules. Not distribution, MVC or anything else.
They're the same thing. We've agreed at the irc meeting to have an
architectural review before defining milestones and rfcs etc... lets
stick to that. If matthew's out today, then lets wait for him to get
back and see what he's thinking. Ultimately deciding these architectural
questions will come down to him and the cr-team for executive decision
making.

--

Kevin


On 11-08-29 10:51 AM, Pádraic Brady wrote:

> Kevin,
>
> Rob's topic for the RFC was ZF2 Modules. Not distribution, MVC or anything else. To date, while there is much ML discussion, as the MVC prototypes hopefully bear down on us from Matthew/Ralph, we need to have some agreement documented on Modules. That is the entire purpose of an RFC - to formalise what we agree to do once and for all by inviting comment and debate and bringing it to a final conclusion with a vote. Rob's added an RFC (a Request For Comment) so we have something to refer to and document how the discussion will shape Modules. The community can criticise it, comment on it, create a rival RFC if they think it's too far off-base. Just so long as it results in a decision so we can move on to proposing/writing actual source code and not be bringing up the same topic every few months into infinity ;).
> If you believe there are outstanding questions, then let's get on with the show. I'm pretty sure Rob has every intention of modifying the RFC depending on the feedback he sees on this topic.
>
> Regarding the outstanding weekly summary, as I understand from mentioning it to Ralph, Matthew is out sick today and the guys were hoping to get out a dev release for the HTTP stuff added in master. There's bound to be a few unexpected misses over time, so long as it doesn't become a trend :P.
>
>  
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
> ----- Original Message -----
>> From: Kevin McArthur<[hidden email]>
>> To: [hidden email]
>> Cc:
>> Sent: Monday, August 29, 2011 6:25 PM
>> Subject: Re: [zf-contributors] RFC: ZF2 Modules
>>
>>>   We were missing something to anchor the discussion around.
>> We were? Theres quite a number of outstanding questions on the mailing list. I
>> fail to see how the wiki format (now with a ton of what I consider incorrect
>> info on it) helps anything. If anything its going to increase the friction on
>> this process.
>>
>> In the line of other, zfprops on the topic:
>>
>> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Requirements
>> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Milestones
>> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>> http://framework.zend.com/wiki/pages/viewpage.action?pageId=43745438
>>
>> Etc..
>>
>> The mailing list failure was pretty bad but, lack of process isn't why this
>> discussion stalled.. We've now got the mailing list, blog, weekly summaries,
>> etc...  I'll note there's no post on the zf2 dev blog and that the
>> summaries are now out of date and dont reflect the post-irc-meeting discussion.
>>
>> A lack of process isn't the problem.
>>
>> --
>>
>> Kevin
>>
>>
>>
>> On 11-08-29 10:05 AM, Pádraic Brady wrote:
>>>>   I'm not sure what the process from here is (I think we're
>> making it up
>>>>   as we go along personally!) Obviously, we need to finalise the items in
>> red.
>>>>   I'm happy to update the RFC document based on comments received and
>> try to
>>>>   ensure we reach consensus. I think we'll then be able to formally
>> vote on
>>>>   it.
>>>   We are making it up ;). I'll add something to the dev meeting agenda
>> for Wednesday to formally adopt the RFC workflow for architectural proposals.
>> Alas, few comments on my large email about it last week so either people are
>> still ruminating or have no disagreements with what I proposed. Which is fine by
>> me, of course ;). Will reply on your RFC tomorrow when I have more time but
>> thanks for writing it! We were missing something to anchor the discussion
>> around.
>>>     Pádraic Brady
>>>   http://blog.astrumfutura.com
>>>   http://www.survivethedeepend.com
>>>   Zend Framework Community Review Team
>>>
>> -- List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

padraicb
Kevin,

The CR Team has no executive decision authority. We were formed to review proposals, assist maintenance, and recommend (or not) adoption by Zend. That doesn't encompass architectural changes in ZF2. The formulation of milestones, also does nothing to remove the need to consider Modules. If anything, it's emphasis over time suggests paving a path forward will be foremost on the list of milestones so I see no reason to delay debating it right now so we can agree on something and move along.

Paddy

P.S. This discussion has hijacked Rob's thread so I suggest moving it to another relevant thread.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

akrabat
In reply to this post by Kevin McArthur-2

On 29 Aug 2011, at 17:56, Kevin McArthur wrote:

> Hey Rob,
>
> I'm just waiting for Matthew's response to everything. We had a mailing list failure for several days too, so that might be more blamed for the discussion fizzling than actually people no longer being interested.

Possibly. I noticed that we had gone 10 clear days with none posting to the Modules thread, so it seems like a good time to write up where we are and try and summarise the Modules strand as there's a lot of strands that need sorting out.


>>    * Discourage dynamic discovery in preference of installation
>>      (which should improve performance over ZF1 modular applications)
>>
> I'm not sure where you got this from, but my modular proposal is dynamic based with a hard coupling to disk cache.

From the first post in the thread :)  I couldn't find anyone else who was negative about this part of Matthew's post and found 2 people who were positive about it.


>
>>    * A module is a directory (usually under the modules/ folder)
>>      which can be named any valid name.
>>
>
> A module in my mind is a .phar or similar archive format, which may -- in development -- be a directory.

Good idea. I've updated.

> Naming is still contentious, with some favoring a org.example.component naming model and others favouring a FIFO registration of plain names.

A quick count of the posts on the thread showed more negatives than positives. However, the RFC doesn't preclude anyone using reverse TLD for their own modules.

> PSR-0 compatibility is still contentious.

I can't find a single post in the module thread disagreeing with PSR-0.


>
>>    * All class files within the module /should/ be namespaced.
>>
> I'd argue to *must* here, but with the caveat that classes could be provided in other namespaces than the module itself.

I can see the /must/ argument.

Not sure that we would want to even mention that the Blog module could implement classes in the Ecommerce namespace. What's the use-case?


>
>>    * A module /should/ contain a file containing a class map for use
>>      with the ClassMapAutoloader. However, classes within the module
>>      should be loadable using PSR-0 standards via the StandardAutoloader.
>>
>
> Still under contention. If we go dynamic discovery and use a more comprehensive modular approach that involves hierarchical overriding, we'll probably want to replace the classmapautoloader with something more like a standardized manifest file more analogous to the .NET global assembly cache concept.

I would be amazed if we threw away Zend\Loader\StandardLoader and Zend\Loader\ClassMapAutoloader. I suspect that they'll have to be some very compelling reasons to do so.


>
>> A module /should/ contain a configuration file that can be merged with the application configuration. Configuration keys should be namespaced and might include, but not be limited to:
>>
>>    * DI definitions and/or configuration for module-specific classes
>>    * Routing tables
>>
> I don't believe this needs to be a configuration file, rather the module system will have a standard set of hooks that will allow the module the opportunity to run whatever initialization code is needed, which may or may not be the injection of site-wide configuration values.


I think I agree. Logically, if a given module developer wanted to use an ini file for default configuration, then they could load it via their Configuration class. If it was a common use-case, then I could imagine ZF2 supplying a helper class for use with the configuration class to handle it.

I imagine that specific application configuration would be put into the application.ini file by the user of the module anyway.

Further input required from others here please. I've marked this point red on the RFC for now.


>
>> A module /may/ contain a Configuration class that will be consumed by Zend\Tool (or similar) during installation/upgrade 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
>>      /optionally/ move (or symlink or add .htaccess rules) 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).
>>    * Describe the loading priority and dependent modules.
>>    * etc. (Whatever else the developer chooses to implement!)
>>
>
> I don't believe we've decided on a 'merged configuration' approach vs a dynamically compiled dependency approach. I think this files-based approach will result in a lot of totally un-necessary system admin tasks that are both laborious and have the potential to introduce serious user-error and learning curve. A dynamic/manifest approach will slightly increase the learning curve for module development, but drastically reduce use-only requirements. (I envision module admin possible from a ftp client)
>

Is the main thing that concerns you about this section is the "that will be consumed by Zend\Tool (or similar) during installation/upgrade" ?

i.e. do we all agree on the general concept that there's a class within the module that handles configuration of the module that is run prior to the bootstrap process?


>
>> Installing/upgrading modules
>>
> While a nice Zend_Tool downloader/file manager is a nice-to-have feature. I'm not sure its a dependency, nor that we need explicit installation/upgrade/etc phases. ZF install <package> should be analgous to zf download <package>
>
> ZF remove <package> should be analogous to rm packagename.phar
>
> Overall, I think we need to look at the best and worst of modular architectures in the market place and really consider usability for end-users going forward. That means module admin should be essentially drag-and-drop simple, and provide admin-ui-installation possibilities.

There seemed to be consensus being able to install a package directly from a remote repository and update it easily via a CLI tool was a requirement.

I left Matthew's use of Zend\Tool on the assumption that no matter what packaging solution we picked, it would probably be proxied through a Zend\Tool provider anyway. In terms of the RFC, the technology used doesn't really matter as it essentially just says that they'll be an easy way to install, update and remove modules via a CLI as it uses the word "could".

Having said that, personally, I quite like the idea of dropping a folder/phar into modules/ and say adding a line to application.ini to tell my app that it exists and all works.

Further input required from others please: Other than remote install, what does using a CLI to install a module give us?


> I'm not a fan of the bolted ZF1.0-style modules + incremental changes approach. I think we need to toss the zf1.0 architectural ideas out the window and start again from the best innovations seen in the marketplace. IMO that means looking at symphony bundles, .net gac, java jars, ruby gems, etc and picking what works from them and leaving out whats crap about them to arrive at something uniquely ZF2.

I see a lot of the actual functionality that's been discussed about what's inside the module's directory and how it works falling into the realm of the MVC and bootstrapping system. In my opinion, the module RFC should be as generic as possible about what's inside a module and only talk about how it gets installed/updated/removed, registered with the system and how classes within it are loaded.

The MVC RFC should cover how, for instance, view script overriding works, directory organisation and how the DI allows one module to override another. Maybe I'm wrong though.

There's a bit of overlap with this one though, so I'm guessing that we'll have to work on MVC a bit before we put modules to bed. I'd rather see a set of focussed RFCs than a long & complicated kitchen sink one.  


Regards,

Rob…








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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Kevin McArthur-2


On 11-08-29 02:34 PM, Rob Allen wrote:
> Not sure that we would want to even mention that the Blog module could implement classes in the Ecommerce namespace. What's the use-case?

Something like TinyMCE integration. Dojo vs Form, etc.

> Is the main thing that concerns you about this section is the "that will be consumed by Zend\Tool (or similar) during installation/upgrade" ?
>
> i.e. do we all agree on the general concept that there's a class within the module that handles configuration of the module that is run prior to the bootstrap process?

There's two approaches to this that I've seen.

1) Sites are built much like Ruby on Rails apps, with some sort of
implicit installation procedure... like installing gems, etc. The
scripts run through db migrations, etc, and make changes to an in-situ
application context. Downside is that one bad install verb and your
system is altered in a permanent way.

2) Sites are totally dynamic/modular. A code scanner (which is set to
stat in development, but time based in production) watches for directory
changes/etc and compiles a 'working set' of source files designed to be
optimally loaded into a memory cache like APC. This is something similar
to the 'compiler compiler' concept (eg yacc) ... the modules form the
basis for the run-time set but are not themselves run directly.

This gives distinct advantages to the overriding and source-code
injecting options. Multiple versions can live side-by-side, and
dependencies can be calculated with more sophistication than simple
DI/extension methodologies. Overriding resources like graphics and
templates becomes possible and easy.

The best (imo) implementation of these concepts is the .NET global
assembly cache, which has some amazingly elegant architecture when it
comes to modular development.

It is however a big change, and probably not PSR-0 compliant. That said,
it should still very much be up for discussion given the potential benefits.

> There seemed to be consensus being able to install a package directly from a remote repository and update it easily via a CLI tool was a requirement.

The meaning of 'install' here is what is confusing. Download yes, but
see prior remarks.

> Having said that, personally, I quite like the idea of dropping a folder/phar into modules/ and say adding a line to application.ini to tell my app that it exists and all works.

If we do it right, shouldnt even need to add to application.ini (or need
an application.ini)

The code scanner can handle self-configuration, and since we'd be making
a hard link on cache, something like Zend_Tool could be used to change
installation options. Imagine dpkg-reconfigure <your zend app> or
similar from an admin ui component ;)


--

Other points can be left for discussion when the big decisions (like
phar, psr-0 requirements, code scanning vs installation, etc) are made.

--

Kevin





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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Artur Bodera
In reply to this post by akrabat
On Mon, Aug 29, 2011 at 6:08 PM, Rob Allen <[hidden email]> wrote:

>
>    http://framework.zend.com/wiki/x/wYCbAg
>
>
On the grounds of flexibility, I'd like to start a discussion on
"extensions". This word has been used
several times now and is still given too much meaning, or too less.

I expressed my concerns about moving MVC away from a dysfunctional body of
utilities named
"core", but I didn't find any supporters there. In any case, there will be a
number of (existing)
components that will not fit into those invisible boxes.


In the modules thread I've tried 3 times to try to normalize it, again with
no supporters ;-) This comes
back every time you tackle things like namespaces, or coupling. Just a quick
recall of my proposition:

 * Core (what comes with basic ZF2 archive)
 * Extensions (extra classes, can live inside Zend\* namespace, distributed
separately)
 * Modules (collections of extensions + configuration, installation, static
assets)
 * Bundles (collections of modules)
 * Apps (collections of bundles and modules)

We could flatten this naming convention to this:
 * Core
 * Modules
 * Bundles
 * Apps

In this convention, here are my examples:

 * Core
 * Modules:  FormBuilder, Dojo, ACL, jQuery, GData-googleplus
 * Bundles: Magento , Security, SEO
 * Apps: Magento

Notice how in Modules, I've thrown in smaller and bigger packets. If every
downloadable and
installable piece of code can be named a "Module", then it can be as big as
a Magento feature
(with configs, models, schemas), and can be as little as a single class
(i.e. Zend\Service\GData\Googleplus).

This brings us to namespaces, if we keep existing fat namespaces, such as
Zend\Service, then
we *must* allow modules to extend them. In my example, a Googleplus
extension to the GData
service inside Zend\Service.

On the other hand, bigger things such as ecommerce module can go both ways -
meaning there
can be a confusion. For example, ecommerce module has its controllers,
configs and own services.
If ecommerce module uses Payment service, does it go to:
 * Zend\Service\Payment
or
 * Ecommerce\Service\Payment
or
 * Zend\Service\Ecommerce\Payment


== Module assets ==
In terms of asset centralization/decentralization I see little options here.
For example, our MusicPlayer module could consist of:
  * config.ini
  * Service/Pandora.php
  * views/index/index.php
  * views/index/tracks.php
  * controllers/indexcontroller.php
  * public/img/pandora.png

There are 2 general approaches.

_Decentralized_
 * Application
    * Modules
       * Ecommerce
          * controllers
          * models
          * views
          * public
       * AnotherModule
          * controllers
          * models
          * views
          * public


_Centralized_
 * Application
    * controllers
        * Ecommerce
        * AnotherModule
    * models
        * Ecommerce
        * AnotherModule
    * views
        * Ecommerce
        * AnotherModule
* public
    * Ecommerce
    * AnotherModule


Centralized is more decoupled in nature, easier to maintain, less "code
hunting", theoretically
easier to control and implement.

Decentralized is more convenient to maintain, view scripts are where all
view scripts are
supposed to be.

Any other ideas?

A.

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

Re: RFC: ZF2 Modules

Shaun Farrell
In reply to this post by akrabat
On Mon, Aug 29, 2011 at 5:34 PM, Rob Allen <[hidden email]> wrote:

>
> On 29 Aug 2011, at 17:56, Kevin McArthur wrote:
>
> > Hey Rob,
> >
> > I'm just waiting for Matthew's response to everything. We had a mailing
> list failure for several days too, so that might be more blamed for the
> discussion fizzling than actually people no longer being interested.
>
> Possibly. I noticed that we had gone 10 clear days with none posting to the
> Modules thread, so it seems like a good time to write up where we are and
> try and summarise the Modules strand as there's a lot of strands that need
> sorting out.
>
>
> >>    * Discourage dynamic discovery in preference of installation
> >>      (which should improve performance over ZF1 modular applications)
> >>
> > I'm not sure where you got this from, but my modular proposal is dynamic
> based with a hard coupling to disk cache.
>
> From the first post in the thread :)  I couldn't find anyone else who was
> negative about this part of Matthew's post and found 2 people who were
> positive about it.
>
>
> >
> >>    * A module is a directory (usually under the modules/ folder)
> >>      which can be named any valid name.
> >>
> >
> > A module in my mind is a .phar or similar archive format, which may -- in
> development -- be a directory.
>
> Good idea. I've updated.
>
> > Naming is still contentious, with some favoring a org.example.component
> naming model and others favouring a FIFO registration of plain names.
>
> A quick count of the posts on the thread showed more negatives than
> positives. However, the RFC doesn't preclude anyone using reverse TLD for
> their own modules.
>
> > PSR-0 compatibility is still contentious.
>
> I can't find a single post in the module thread disagreeing with PSR-0.
>
>
> >
> >>    * All class files within the module /should/ be namespaced.
> >>
> > I'd argue to *must* here, but with the caveat that classes could be
> provided in other namespaces than the module itself.
>
> I can see the /must/ argument.
>
> Not sure that we would want to even mention that the Blog module could
> implement classes in the Ecommerce namespace. What's the use-case?
>
>
> >
> >>    * A module /should/ contain a file containing a class map for use
> >>      with the ClassMapAutoloader. However, classes within the module
> >>      should be loadable using PSR-0 standards via the
> StandardAutoloader.
> >>
> >
> > Still under contention. If we go dynamic discovery and use a more
> comprehensive modular approach that involves hierarchical overriding, we'll
> probably want to replace the classmapautoloader with something more like a
> standardized manifest file more analogous to the .NET global assembly cache
> concept.
>
> I would be amazed if we threw away Zend\Loader\StandardLoader and
> Zend\Loader\ClassMapAutoloader. I suspect that they'll have to be some very
> compelling reasons to do so.
>
>
> >
> >> A module /should/ contain a configuration file that can be merged with
> the application configuration. Configuration keys should be namespaced and
> might include, but not be limited to:
> >>
> >>    * DI definitions and/or configuration for module-specific classes
> >>    * Routing tables
> >>
> > I don't believe this needs to be a configuration file, rather the module
> system will have a standard set of hooks that will allow the module the
> opportunity to run whatever initialization code is needed, which may or may
> not be the injection of site-wide configuration values.
>
>
> I think I agree. Logically, if a given module developer wanted to use an
> ini file for default configuration, then they could load it via their
> Configuration class. If it was a common use-case, then I could imagine ZF2
> supplying a helper class for use with the configuration class to handle it.
>
> I imagine that specific application configuration would be put into the
> application.ini file by the user of the module anyway.
>
> Further input required from others here please. I've marked this point red
> on the RFC for now.
>
>
> >
> >> A module /may/ contain a Configuration class that will be consumed by
> Zend\Tool (or similar) during installation/upgrade 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
> >>      /optionally/ move (or symlink or add .htaccess rules) 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).
> >>    * Describe the loading priority and dependent modules.
> >>    * etc. (Whatever else the developer chooses to implement!)
> >>
> >
> > I don't believe we've decided on a 'merged configuration' approach vs a
> dynamically compiled dependency approach. I think this files-based approach
> will result in a lot of totally un-necessary system admin tasks that are
> both laborious and have the potential to introduce serious user-error and
> learning curve. A dynamic/manifest approach will slightly increase the
> learning curve for module development, but drastically reduce use-only
> requirements. (I envision module admin possible from a ftp client)
> >
>
> Is the main thing that concerns you about this section is the "that will be
> consumed by Zend\Tool (or similar) during installation/upgrade" ?
>
> i.e. do we all agree on the general concept that there's a class within the
> module that handles configuration of the module that is run prior to the
> bootstrap process?
>
>
> >
> >> Installing/upgrading modules
> >>
> > While a nice Zend_Tool downloader/file manager is a nice-to-have feature.
> I'm not sure its a dependency, nor that we need explicit
> installation/upgrade/etc phases. ZF install <package> should be analgous to
> zf download <package>
> >
> > ZF remove <package> should be analogous to rm packagename.phar
> >
> > Overall, I think we need to look at the best and worst of modular
> architectures in the market place and really consider usability for
> end-users going forward. That means module admin should be essentially
> drag-and-drop simple, and provide admin-ui-installation possibilities.
>
> There seemed to be consensus being able to install a package directly from
> a remote repository and update it easily via a CLI tool was a requirement.
>
> I left Matthew's use of Zend\Tool on the assumption that no matter what
> packaging solution we picked, it would probably be proxied through a
> Zend\Tool provider anyway. In terms of the RFC, the technology used doesn't
> really matter as it essentially just says that they'll be an easy way to
> install, update and remove modules via a CLI as it uses the word "could".
>
> Having said that, personally, I quite like the idea of dropping a
> folder/phar into modules/ and say adding a line to application.ini to tell
> my app that it exists and all works.
>
> Further input required from others please: Other than remote install, what
> does using a CLI to install a module give us?
>
>
> > I'm not a fan of the bolted ZF1.0-style modules + incremental changes
> approach. I think we need to toss the zf1.0 architectural ideas out the
> window and start again from the best innovations seen in the marketplace.
> IMO that means looking at symphony bundles, .net gac, java jars, ruby gems,
> etc and picking what works from them and leaving out whats crap about them
> to arrive at something uniquely ZF2.
>
> I see a lot of the actual functionality that's been discussed about what's
> inside the module's directory and how it works falling into the realm of the
> MVC and bootstrapping system. In my opinion, the module RFC should be as
> generic as possible about what's inside a module and only talk about how it
> gets installed/updated/removed, registered with the system and how classes
> within it are loaded.
>
> The MVC RFC should cover how, for instance, view script overriding works,
> directory organisation and how the DI allows one module to override another.
> Maybe I'm wrong though.
>
> There's a bit of overlap with this one though, so I'm guessing that we'll
> have to work on MVC a bit before we put modules to bed. I'd rather see a set
> of focussed RFCs than a long & complicated kitchen sink one.
>
>
> Regards,
>
> Rob…
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

As for the module config.  I don't think the it "Should" be required
however, I think if one is there it should be merged.  I would hate to have
5 modules with a bunch of routes and other settings in there all be put into
my main application.ini I like the separation of the configuration files it
cleaner and easier to locate.  However, I am not in disagreement with what
both Kevin and Rob have stated above.

+1 for .phar

+1 to "dropping a folder/phar into modules/ and say adding a line to
application.ini to tell my app that it exists and all works."

Shaun
Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

weierophinney
Administrator
In reply to this post by padraicb
-- Pádraic Brady <[hidden email]> wrote
(on Monday, 29 August 2011, 10:05 AM -0700):

> > I'm not sure what the process from here is (I think we're making it up
> > as we go along personally!) Obviously, we need to finalise the items in red.
> > I'm happy to update the RFC document based on comments received and try to
> > ensure we reach consensus. I think we'll then be able to formally vote on
> > it.
>
> We are making it up ;). I'll add something to the dev meeting agenda
> for Wednesday to formally adopt the RFC workflow for architectural
> proposals. Alas, few comments on my large email about it last week so
> either people are still ruminating or have no disagreements with what
> I proposed. Which is fine by me, of course ;).

I had no disagreements. I may have additions. Basically, I think the RFC
process should probably work similar to the one php-internals has
recently adopted, though with potentially shorter time frames:

 * RFC posted on wiki
 * RFC announced on ML for discussion
 * Discussion to last X number of days/weeks at _minimum_
 * Author calls for votes
    * This entails editing the RFC and pushing in a voting block, and
      announcing it on the list
 * Voting occurs for X number of days/weeks _maximum_
 * Voting result can be vetoed by CR-Team or Zend ZF team _ONLY_ _WITH_
   _REALLY_ _COMPELLING_ _RATIONALE_ that must be posted on the RFC.

> Will reply on your RFC tomorrow when I have more time but thanks for
> writing it! We were missing something to anchor the discussion around.

Likewise (I was ill yesterday, still am today, and trying to wade
through pull requests and MLs through a fog of decongestants).

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

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

weierophinney
Administrator
In reply to this post by Kevin McArthur-2
-- Kevin McArthur <[hidden email]> wrote
(on Monday, 29 August 2011, 10:25 AM -0700):
> The mailing list failure was pretty bad but, lack of process isn't
> why this discussion stalled.. We've now got the mailing list, blog,
> weekly summaries, etc...  I'll note there's no post on the zf2 dev
> blog

I'll get one out today. Enrico is now on vacation for two weeks, leaving
me this responsibility while he's gone. I had hoped to do so yesterday,
but was ill. Please, have a little patience; one or two days variance is
not ridiculous.

> and that the summaries are now out of date and dont reflect the
> post-irc-meeting discussion.

Which summaries are you talking about? And what's not reflected? I'll
try and correct, but I'm not sure what exactly might be missing/changed.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

weierophinney
Administrator
In reply to this post by akrabat
-- Rob Allen <[hidden email]> wrote
(on Monday, 29 August 2011, 10:34 PM +0100):
> On 29 Aug 2011, at 17:56, Kevin McArthur wrote:

<snip>

> > > Installing/upgrading modules
> > >
> > While a nice Zend_Tool downloader/file manager is a nice-to-have
> > feature. I'm not sure its a dependency, nor that we need explicit
> > installation/upgrade/etc phases. ZF install <package> should be
> > analgous to zf download <package>
> >
> > ZF remove <package> should be analogous to rm packagename.phar
> >
> > Overall, I think we need to look at the best and worst of modular
> > architectures in the market place and really consider usability for
> > end-users going forward. That means module admin should be
> > essentially drag-and-drop simple, and provide admin-ui-installation
> > possibilities.
>
> There seemed to be consensus being able to install a package directly
> from a remote repository and update it easily via a CLI tool was a
> requirement.
>
> I left Matthew's use of Zend\Tool on the assumption that no matter
> what packaging solution we picked, it would probably be proxied
> through a Zend\Tool provider anyway. In terms of the RFC, the
> technology used doesn't really matter as it essentially just says that
> they'll be an easy way to install, update and remove modules via a CLI
> as it uses the word "could".
>
> Having said that, personally, I quite like the idea of dropping a
> folder/phar into modules/ and say adding a line to application.ini to
> tell my app that it exists and all works.
>
> Further input required from others please: Other than remote install,
> what does using a CLI to install a module give us?

A few things:

 * Ability to uninstall a module cleanly.
   Once a module is installed, you will likely now have some artifacts
   in the application configuration, DI setup, routing tables, and more.
   Removing the module directory is likely not enough.

 * Ability to upgrade a module.
   I'd expect any CLI tool would likely also manage upgrades -- checking
   to see if one is available, and then executing upgrade tasks to
   ensure that the module is properly configured in the application.

 * Ability to execute tasks in the module for installation purposes.
   These might include:
   * Providing events to register
   * Handling non-code assets (images, css, etc.)
   * Providing DI definitions to the application
   * Providing routing configuration
   * Updating the application configuration.

On the latter point, one thing I've been thinking is that we should
investigate the idea of "imports" in configuration files. This would
allow us to simply add a new import statement to the application
configuration that points at the module configuration. The benefit would
be easy maintainability. We could have configuration for each of
application configuration, DI, routing, i18n/l10n, etc. at the
application level, and simply import in artifacts from modules as
required.


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

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Benoît Durand
Le 30 août 11 à 19:10, Matthew Weier O'Phinney a écrit :
> On the latter point, one thing I've been thinking is that we should
> investigate the idea of "imports" in configuration files. This would
> allow us to simply add a new import statement to the application
> configuration that points at the module configuration. The benefit  
> would
> be easy maintainability. We could have configuration for each of
> application configuration, DI, routing, i18n/l10n, etc. at the
> application level, and simply import in artifacts from modules as
> required.
I like this idea :)

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

padraicb
In reply to this post by weierophinney
> I had no disagreements. I may have additions. Basically, I think the RFC
> process should probably work similar to the one php-internals has
> recently adopted, though with potentially shorter time frames:
>
> * RFC posted on wiki
> * RFC announced on ML for discussion
> * Discussion to last X number of days/weeks at _minimum_
> * Author calls for votes
>     * This entails editing the RFC and pushing in a voting block, and
>       announcing it on the list
> * Voting occurs for X number of days/weeks _maximum_
> * Voting result can be vetoed by CR-Team or Zend ZF team _ONLY_ _WITH_
>    _REALLY_ _COMPELLING_ _RATIONALE_ that must be posted on the RFC.

I'd agree with all bar the potential time limit on discussions. Since an author (or the author of a rival RFC) can call for a vote at any time, I don't see the need to push them along - they'll get to voting when they're ready. Unlike the ML if something fizzles out before a vote, it will be because the author abandoned or deferred the idea. A max time limit would only end up promoting last minute RFCs or keeping RFCs off the table and stuck on the MLs until to evade the time limit and allow a longer gestation for ideas. That actually works against RFCs since they should be posted very early in the process to support an ML debate by forcing everyone to keep an eye on how the RFC develops over time. If anyone feels an RFC is taking too long, they can simply create a rival RFC and push it to a vote.

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


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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

padraicb
In reply to this post by weierophinney
----- Original Message -----

> From: Matthew Weier O'Phinney <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Tuesday, August 30, 2011 6:10 PM
> Subject: Re: [zf-contributors] RFC: ZF2 Modules
>
>>
>>  There seemed to be consensus being able to install a package directly
>>  from a remote repository and update it easily via a CLI tool was a
>>  requirement.
>>
>>  I left Matthew's use of Zend\Tool on the assumption that no matter
>>  what packaging solution we picked, it would probably be proxied
>>  through a Zend\Tool provider anyway. In terms of the RFC, the
>>  technology used doesn't really matter as it essentially just says that
>>  they'll be an easy way to install, update and remove modules via a CLI
>>  as it uses the word "could".
>>
>>  Having said that, personally, I quite like the idea of dropping a
>>  folder/phar into modules/ and say adding a line to application.ini to
>>  tell my app that it exists and all works.
>>
>>  Further input required from others please: Other than remote install,
>>  what does using a CLI to install a module give us?
>
> A few things:
>
> * Ability to uninstall a module cleanly.
>    Once a module is installed, you will likely now have some artifacts
>    in the application configuration, DI setup, routing tables, and more.
>    Removing the module directory is likely not enough.


conf.d? Split the config. Since we're already looking at a form of compilation for production, we can have a cleanup routine to remove artifacts and rebuild any central configuration cache.


> * Ability to upgrade a module.
>    I'd expect any CLI tool would likely also manage upgrades -- checking
>    to see if one is available, and then executing upgrade tasks to
>    ensure that the module is properly configured in the application.


Makes sense, of course.


> * Ability to execute tasks in the module for installation purposes.
>    These might include:
>    * Providing events to register
>    * Handling non-code assets (images, css, etc.)
>    * Providing DI definitions to the application
>    * Providing routing configuration
>    * Updating the application configuration.
>
> On the latter point, one thing I've been thinking is that we should
> investigate the idea of "imports" in configuration files. This would
> allow us to simply add a new import statement to the application
> configuration that points at the module configuration. The benefit would
> be easy maintainability. We could have configuration for each of
> application configuration, DI, routing, i18n/l10n, etc. at the
> application level, and simply import in artifacts from modules as
> required.

Add to the list DB operations and migrations for those modules reliant on a database.

There's positives and negatives depending on how configuration is managed. In an "import" scenario, we need to directly edit configuration files via PHP to add the import statement, in a conf.d sort of setup we establish conventions for where a pool of configurations can be placed to be auto-merged during development, or cached/rebuilt in production. I favour the second since it appears to be a bit simpler (convention trumping configuration editing). The editing route also raises a question over what to edit. I'm not a particular fan of INI configs - they're pretty verbose and repetitive compared to plain old PHP or YAML. So we'd need to support editing multiple formats, rather than just merging them all via Zend\Config into a single cached object. I just feel the second is slightly cleaner and more drop-and-go in nature.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Kevin McArthur-2
Still seems like you guys are talking about a codebase as a state
machine system. Whats wrong with module self/automatic configuration
with overrides in cache?

--

Kevin

On 11-08-30 11:06 AM, Pádraic Brady wrote:

> ----- Original Message -----
>> From: Matthew Weier O'Phinney<[hidden email]>
>> To: [hidden email]
>> Cc:
>> Sent: Tuesday, August 30, 2011 6:10 PM
>> Subject: Re: [zf-contributors] RFC: ZF2 Modules
>>
>>>   There seemed to be consensus being able to install a package directly
>>>   from a remote repository and update it easily via a CLI tool was a
>>>   requirement.
>>>
>>>   I left Matthew's use of Zend\Tool on the assumption that no matter
>>>   what packaging solution we picked, it would probably be proxied
>>>   through a Zend\Tool provider anyway. In terms of the RFC, the
>>>   technology used doesn't really matter as it essentially just says that
>>>   they'll be an easy way to install, update and remove modules via a CLI
>>>   as it uses the word "could".
>>>
>>>   Having said that, personally, I quite like the idea of dropping a
>>>   folder/phar into modules/ and say adding a line to application.ini to
>>>   tell my app that it exists and all works.
>>>
>>>   Further input required from others please: Other than remote install,
>>>   what does using a CLI to install a module give us?
>> A few things:
>>
>> * Ability to uninstall a module cleanly.
>>     Once a module is installed, you will likely now have some artifacts
>>     in the application configuration, DI setup, routing tables, and more.
>>     Removing the module directory is likely not enough.
>
> conf.d? Split the config. Since we're already looking at a form of compilation for production, we can have a cleanup routine to remove artifacts and rebuild any central configuration cache.
>
>
>> * Ability to upgrade a module.
>>     I'd expect any CLI tool would likely also manage upgrades -- checking
>>     to see if one is available, and then executing upgrade tasks to
>>     ensure that the module is properly configured in the application.
>
> Makes sense, of course.
>
>
>> * Ability to execute tasks in the module for installation purposes.
>>     These might include:
>>     * Providing events to register
>>     * Handling non-code assets (images, css, etc.)
>>     * Providing DI definitions to the application
>>     * Providing routing configuration
>>     * Updating the application configuration.
>>
>> On the latter point, one thing I've been thinking is that we should
>> investigate the idea of "imports" in configuration files. This would
>> allow us to simply add a new import statement to the application
>> configuration that points at the module configuration. The benefit would
>> be easy maintainability. We could have configuration for each of
>> application configuration, DI, routing, i18n/l10n, etc. at the
>> application level, and simply import in artifacts from modules as
>> required.
> Add to the list DB operations and migrations for those modules reliant on a database.
>
> There's positives and negatives depending on how configuration is managed. In an "import" scenario, we need to directly edit configuration files via PHP to add the import statement, in a conf.d sort of setup we establish conventions for where a pool of configurations can be placed to be auto-merged during development, or cached/rebuilt in production. I favour the second since it appears to be a bit simpler (convention trumping configuration editing). The editing route also raises a question over what to edit. I'm not a particular fan of INI configs - they're pretty verbose and repetitive compared to plain old PHP or YAML. So we'd need to support editing multiple formats, rather than just merging them all via Zend\Config into a single cached object. I just feel the second is slightly cleaner and more drop-and-go in nature.
>
>  
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

padraicb
Not sure I follow, how would a module self-configure itself? And how does that differ substantially from what we've been mentioning previously?

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



----- Original Message -----

> From: Kevin McArthur <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Tuesday, August 30, 2011 7:17 PM
> Subject: Re: [zf-contributors] RFC: ZF2 Modules
>
> Still seems like you guys are talking about a codebase as a state
> machine system. Whats wrong with module self/automatic configuration
> with overrides in cache?
>
> --
>
> Kevin

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


Reply | Threaded
Open this post in threaded view
|

Re: RFC: ZF2 Modules

Kevin McArthur-2
A module would receive an initialization hook from the module loader.

It could then inject config values into a responsble configuration
object. Since the plugin load/init process is cached to disk, everything
is fast but still happens automatically. The idea here is to generalize
the plugin api to the extent where modules are truly encapsulated, but
have code access to everything.

This is opposite to the idea of installing something that permanently
changes an external [to the module] config file and is expected to be
able to cleanly remove its values at a later time.

--

Kevin

On 11-08-30 11:21 AM, Pádraic Brady wrote:

> Not sure I follow, how would a module self-configure itself? And how does that differ substantially from what we've been mentioning previously?
>
>  
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
>
>
>
> ----- Original Message -----
>> From: Kevin McArthur<[hidden email]>
>> To: [hidden email]
>> Cc:
>> Sent: Tuesday, August 30, 2011 7:17 PM
>> Subject: Re: [zf-contributors] RFC: ZF2 Modules
>>
>> Still seems like you guys are talking about a codebase as a state
>> machine system. Whats wrong with module self/automatic configuration
>> with overrides in cache?
>>
>> --
>>
>> Kevin

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


1234