ZF2 MVC Prototype

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

ZF2 MVC Prototype

weierophinney
Administrator
Hey, all --

As promised (though a little later than hoped), I've committed a
prototype for what the MVC _could_ look like for ZF2. It's in my
"prototype/mvc-module" branch on github:

    https://github.com/weierophinney/zf2/tree/prototype/mvc-module

In talking with Rob Allen (Akrabat) last week, I decided to try making
the MVC a "module", which means that you'll find it in the
"modules/Zf2Mvc" subdirectory:

    https://github.com/weierophinney/zf2/tree/prototype/mvc-module/modules/Zf2Mvc

There are a few artifacts in there yet to be discussed/implemented.
composer.json is a file describing the module; it does not necessarily
indicate a decision to use Composer at this time (I simply liked the
idea of a JSON metadata file). Information.php is a class that might be
read by a module manager to determine how to "install" the module into
the application. Finally, classmap.php is an autoloader classmap.

I pulled in DASPRiD's current work on the Router refactoring; many
thanks to him for building something I could easily use in prototyping!

The fun stuff is in the src, tests, and docs directories. If you want to
jump in and start playing with it, I recommend the following:

    https://github.com/weierophinney/zf2/blob/prototype/mvc-module/modules/Zf2Mvc/docs/zf2-mvc.examples.md

It contains some examples of usage, and outlines the main entry points,
as well as how controllers should look and operate.

The tests also show off a fair bit of functionality. Should you wish to
run them, the test runner assumes that the ZF2 library is somewhere on
your include_path. If nothing else, they helped verify two things for
me:

 * Short-circuiting execution is very fast, by either returning a
   Response from your actions, or having an event listener do so.
 * The HTTP component makes *so* many things dead easy.

Please note, I do _not_ address rendering views, or, really, anything
view related in the prototype. This prototype is mainly about getting
a potential application workflow in front of folks to test, in order to
start a conversation about what we need.

A few things:

 * The "AppContext" and "Application" objects are pretty slim, and could
   likely use more thought. I figured the basic needs were some sort of
   dependency/service container, a router, and potentially event
   listeners for the main application itself (these are roughly
   analagous to ZF 1's front controller plugins). Other frameworks will
   often also define things like logging and caching at this level. I
   personally feel those can be injected via the container, but would
   love to know what others think.

 * The "RestfulController" is pretty naive. Any REST folks out there who
   want to tear it apart, please do! :)

 * In writing the portion around the locator, I discovered that our
   ServiceLocation and DependencyInjection interfaces do not share a
   common interface around the get() method. They probably should. (The
   current signatures of those methods are identical between the two
   interfaces.)

 * We need to inject the request object with the PHP environment. Ralph
   actually wrote an object for this, Zend\Http\PhpEnvironment\Request,
   but I wonder if it could simply be done via a decorator within the
   Application object. Thoughts?

Finally, if nothing else, this prototype tells me we need to come up
with a story surrounding both object/component configuration and
application configuration, and soon. If the prototype helps spark any
ideas, start sharing them!

I plan to create a new branch of the zf-quickstart project that utilizes
this module in order to show how we might build applications (a) using
the prototype, and (b) using modules as we've been discussing them on
the RFC. I'll post a link to that when ready.

Looking forward to hearing back from all of you!

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

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


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

Wil Moore III
First of all, thanks for getting this out.


> Other frameworks will often also define things like logging and caching at
> this level. I personally feel those can be injected via the container, but
> would love to know what others think.
>

I can't quite wrap my head around why one wouldn't want this injected via
the container; however, I'd love to hear someone speak up that has a strong
opinion on the other side of the fence.


> The "RestfulController" is pretty naive. Any REST folks out there who want
> to tear it apart, please do! :)
>

Yeah...about that :)

So, I'd love to see us do the semantic thing here where other frameworks
falsely claim REST we can skip this mistake and call it what it is:

Zf2Mvc\Controller\CrudHttpController

We _COULD_ build a true REST component, but why? It is _extremely_ involved
to get right and there is little value in what it provides given the
context. That said, CrudHttpController could be the basis of anyone's
attempt at a true REST controller implementation. I say keep it light and
simple.

... uses HTTP verbs in order to determine what to do


Would love to see HEAD in there and have it do the right thing by default.

Thanks... excellent work.
--
Wil Moore III

Best Practices for Working with Open-Source Developers
http://www.faqs.org/docs/artu/ch19s02.html

Why is Bottom-posting better than Top-posting:
http://www.caliburn.nl/topposting.html

DO NOT TOP-POST and DO trim your replies:
http://linux.sgms-centre.com/misc/netiquette.php#toppost
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

robertbasic
In reply to this post by weierophinney
Hi Matthew!

Will give the module a spin today, just wanted to share a "tip" for others
how to checkout your branch :) I didn't want to fork your zf2 repo, as I
already have one and I'm not in the mood to find out what happens when I
have two github repos with the same name :)

I'm assuming the pwd is /path/to/zf2

prompt> git remote add weierophinney
https://github.com/weierophinney/zf2.git
prompt> git fetch weierophinney
prompt> git checkout -b prototype/mvc-module
weierophinney/prototype/mvc-module

and the module can be easily used now. Don't know how pull requests can be
sent against your branch now, but hey, at least I can easily test the code
now 8)

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

Re: ZF2 MVC Prototype

EvanDotPro
Hey Matthew,

Glad to see this up, thanks! In addition to Robert's tip on checking out
your branch, I'll also mention that in docs/zf2-mvc.examples.md, where you
mention adding the literal route for /hello, you have "use
Zend\Http\Router\Http\LiteralRoute;". However, it looks as though you have
placed the Http\Router stuff under the Zf2Mvc namespace for the time being.

So if that throws anyone off, try "use
Zf2Mvc\Http\Router\Http\LiteralRoute;" instead.

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

weierophinney
Administrator
-- Evan Coury <[hidden email]> wrote
(on Tuesday, 06 September 2011, 07:51 AM -0700):
> Glad to see this up, thanks! In addition to Robert's tip on checking out
> your branch, I'll also mention that in docs/zf2-mvc.examples.md, where you
> mention adding the literal route for /hello, you have "use
> Zend\Http\Router\Http\LiteralRoute;". However, it looks as though you have
> placed the Http\Router stuff under the Zf2Mvc namespace for the time being.

Ooops! Fixed now. :)

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

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


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

robertbasic
In reply to this post by EvanDotPro
A few more things:

- All Router\Http\* classes are throwing non-existent
Exception\InvalidArgumenException (they are loaded from
Zf2Mvc\Router\Exception, yet they are defined only in Zf2Mvc\Exception);

- In the example, in the section of setting up the gateway,
$response->send() is called, yet the response object has no send method. It
has a toString() method, tho, maybe that's needed?

- Finally, the Router fails to match anything because the Request is empty.
See dump here: http://pastebin.com/z767xMDp this is dumped in
Zf2Mvc\Router\Http\Literal, method match(), line 100.

As for the DI aliasing in the example: controller.hello-world.hello the "dot
notation" (or whatever it's called), would be unusable if moved to a INI
config, no?

Again, see my messing around with this here:
https://github.com/robertbasic/zf2phpplaneta/tree/mvc-prototype

Happy hackin'! :)

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

Re: ZF2 MVC Prototype

weierophinney
Administrator
-- Robert Basic <[hidden email]> wrote
(on Tuesday, 06 September 2011, 05:38 PM +0200):
> A few more things:
>
> - All Router\Http\* classes are throwing non-existent
> Exception\InvalidArgumenException (they are loaded from
> Zf2Mvc\Router\Exception, yet they are defined only in Zf2Mvc\Exception);

Those are probably artifacts from me importing them from the main
library; I'll look into them shortly.

> - In the example, in the section of setting up the gateway,
> $response->send() is called, yet the response object has no send method. It
> has a toString() method, tho, maybe that's needed?

Yes -- or we need to create wrappers for the request/response objects to
ensure they have the data they need (by default, the HTTP request object
actually doesn't have either GET or POST populated, either).

> - Finally, the Router fails to match anything because the Request is empty.
> See dump here: http://pastebin.com/z767xMDp this is dumped in
> Zf2Mvc\Router\Http\Literal, method match(), line 100.

See above -- it's something I identified this morning.

> As for the DI aliasing in the example: controller.hello-world.hello the "dot
> notation" (or whatever it's called), would be unusable if moved to a INI
> config, no?

Yes -- probably should stick with - and _ for separators.

> Again, see my messing around with this here:
> https://github.com/robertbasic/zf2phpplaneta/tree/mvc-prototype

Will check it out later! And thanks for the early feedback!

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

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


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

robertbasic
On Tue, Sep 6, 2011 at 5:46 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

> -- Robert Basic <[hidden email]> wrote
> (on Tuesday, 06 September 2011, 05:38 PM +0200):
>
> > As for the DI aliasing in the example: controller.hello-world.hello the
> "dot
> > notation" (or whatever it's called), would be unusable if moved to a INI
> > config, no?
>
> Yes -- probably should stick with - and _ for separators.
>
>
Maybe to restrict in Zend\Di that it can start only with a-z, contain A-Z,
0-9, - and _? Zend_Cache has a similar constraint for tags IIRC.

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

Re: ZF2 MVC Prototype

robertbasic
I forgot one thing:

the Application returns a Response. Will this always be the case? What
happens with CLI applications? Will they also be returning some sort of a
Response? Or would be better to create a WebApplication/CliApplication and,
for example, the WebApplication returns a Response, while CliApplication
returns a Status, which also would extend Zend\Stdlib\Message, just like the
Response?

Just noticed: in Application::getResponse() asks for an instance of
Response, maybe a better option would be to test for a Stdlib\Message? Same
goes for Request.

Sorry for spamming much :P

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

Re: ZF2 MVC Prototype

robzienert
On Tue, Sep 6, 2011 at 11:51 AM, Robert Basic <[hidden email]>wrote:

> I forgot one thing:
>
> the Application returns a Response. Will this always be the case? What
> happens with CLI applications? Will they also be returning some sort of a
> Response? Or would be better to create a WebApplication/CliApplication and,
> for example, the WebApplication returns a Response, while CliApplication
> returns a Status, which also would extend Zend\Stdlib\Message, just like
> the
> Response?
>
> Just noticed: in Application::getResponse() asks for an instance of
> Response, maybe a better option would be to test for a Stdlib\Message? Same
> goes for Request.
>
> Sorry for spamming much :P
>
> --
> ~Robert Basic;
> http://robertbasic.com/
>

I think a CliApplication should be able to return a Response. The status can
be part of that response, but what if you want output printed into the
terminal?

- Rob
Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

robertbasic
On Tue, Sep 6, 2011 at 8:07 PM, Rob Zienert <[hidden email]> wrote:

>
> I think a CliApplication should be able to return a Response. The status
> can be part of that response, but what if you want output printed into the
> terminal?
>
> - Rob
>

I was more referring to the fact that the current Application returns a
Http\Response, my apologies for not being explicit, been a long day :) Also,
the Status was more just an example; I just wanted to make a clear
distinction between the two Responses :)

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

Re: ZF2 MVC Prototype

weierophinney
Administrator
-- Robert Basic <[hidden email]> wrote
(on Tuesday, 06 September 2011, 08:13 PM +0200):
> On Tue, Sep 6, 2011 at 8:07 PM, Rob Zienert <[hidden email]> wrote:
> > I think a CliApplication should be able to return a Response. The status
> > can be part of that response, but what if you want output printed into the
> > terminal?
>
> I was more referring to the fact that the current Application returns a
> Http\Response, my apologies for not being explicit, been a long day :) Also,
> the Status was more just an example; I just wanted to make a clear
> distinction between the two Responses :)

I could see several potential ways to address this:

* Don't hardcode the response type. We could make it configurable
  (provide the class name of the response type we want).

* Don't worry about it. Really, Application simply checks that we have a
  Zend\Stdlib\ResponseDescription, not that it's HTTP. Let our
  application create an appropriate response.

* Have a separate module for CLI execution. This could likely be seeded
  all the same information that the web application is, but would be
  injecting CLI requests and returning CLI responses, and potentially
  replacing routing with Getopt.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

weierophinney
Administrator
In reply to this post by robertbasic
-- Robert Basic <[hidden email]> wrote
(on Tuesday, 06 September 2011, 05:50 PM +0200):

> On Tue, Sep 6, 2011 at 5:46 PM, Matthew Weier O'Phinney <[hidden email]>wrote:
> > -- Robert Basic <[hidden email]> wrote
> > (on Tuesday, 06 September 2011, 05:38 PM +0200):
> >
> > > As for the DI aliasing in the example: controller.hello-world.hello the
> > "dot
> > > notation" (or whatever it's called), would be unusable if moved to a INI
> > > config, no?
> >
> > Yes -- probably should stick with - and _ for separators.
> >
> >
> Maybe to restrict in Zend\Di that it can start only with a-z, contain A-Z,
> 0-9, - and _? Zend_Cache has a similar constraint for tags IIRC.

I've never liked that restriction, tbh... but it may make sense in this
particular case. Alternately, we could normalize the keys in the DI
configuration container; that would allow specifying them however you
want, even in a configuration format-specific way, and still ensure they
resolve well.

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

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


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

padraicb
In reply to this post by weierophinney
> Hey, all --
>
> As promised (though a little later than hoped), I've committed a
> prototype for what the MVC _could_ look like for ZF2. It's in my
> "prototype/mvc-module" branch on github:
>
>     https://github.com/weierophinney/zf2/tree/prototype/mvc-module
>
> In talking with Rob Allen (Akrabat) last week, I decided to try making
> the MVC a "module", which means that you'll find it in the
> "modules/Zf2Mvc" subdirectory:
>
>    
> https://github.com/weierophinney/zf2/tree/prototype/mvc-module/modules/Zf2Mvc

Come to me, pretty prototype :P. I'll try to find time to take it for a whirl soon.

I will disagree with the Module format - we don't need to encapsulate generic libraries (define that as you will) in framework specific structures. I'll hardly be taking new libraries I create outside ZF and putting them into a special ZF box when they can just as easily be installed through PEAR/Pyrus/Composer or cloned from Github. How do other users without Zend Framework MVC install these Modules-once-Components? What are the technical benefits of this approach? Before adopting such an architectural change we *should* have had an RFC describing it, especially since it's off on a tangent to the existing RFC. In noting this on IRC, I've even heard that the idea of using Pyrus has suddenly become another point needing a decision - presumably because turning Components into Modules requires a change in our assumptions. That's a quick and drastic turnabout in where we were originally heading with Modules as being pretty much what they were trying to be in
 ZF1 - sets of controllers/views/models/services/assets representing a reusable integratable piece of an application. I just don't see how pushing the trappings of one specific framework onto other libraries benefits anyone.


Paddy

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


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


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

Artur Bodera
In reply to this post by weierophinney
On Tue, Sep 6, 2011 at 8:24 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

> * Have a separate module for CLI execution. This could likely be seeded
>  all the same information that the web application is, but would be
>  injecting CLI requests and returning CLI responses, and potentially
>  replacing routing with Getopt.


Bleh. -1 to that :-)

I'm yet to see a PHP framework that has a true, request-type independent
MVC. I'm
aware of all quirks and why it currently is what it is on the market, but
I'm all in for
putting extra effort to create a book-example of a MVC and routing that can
digest
"any" type of a request, retrieve "any" named/unnamed parameters and then
return
a response blob that will be transformed to "any" type of
response appropriate at
that point.

A.

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

Re: ZF2 MVC Prototype

robertbasic
In reply to this post by weierophinney
On Tue, Sep 6, 2011 at 8:32 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

> I've never liked that restriction, tbh... but it may make sense in this
> particular case. Alternately, we could normalize the keys in the DI
> configuration container; that would allow specifying them however you
> want, even in a configuration format-specific way, and still ensure they
> resolve well.
>
>
Neither do I. I just wanted to point out that it has been done before :)

Normalization sounds fine, as long as it does not produce WTF moments with
the developer :)

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

Re: ZF2 MVC Prototype

Artur Bodera
In reply to this post by padraicb
On Tue, Sep 6, 2011 at 8:34 PM, Pádraic Brady <[hidden email]>wrote:

> How do other users without Zend Framework MVC install these
> Modules-once-Components? What are the technical benefits of this approach?
>

You clearly haven't skimmed through my proposal.

Modular architecture would be part of the __ZF core___, not MVC.
 * MVC is just a module (with classes and such).
 * Db-Adapter-Foobar would be a module (with classes extending
Db\Adapter\AdapterAbstract)
 * SEO-pack would be a module (with classes + routes + configs + adapters +
images + js + whatever else)
 * AllDb - would be a metapackage containing X other modules, with core Db\*
different adapters and such

This means, a module would be as small as a single class ("component") or as
big as a Magento.

Please jump through my proposal on that ;) I've written my a** off to
describe it (search for
"modular architecture != architecture for modules")





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

Re: ZF2 MVC Prototype

robertbasic
In reply to this post by weierophinney
On Tue, Sep 6, 2011 at 8:24 PM, Matthew Weier O'Phinney <[hidden email]>wrote:

> I could see several potential ways to address this:
>
> * Don't hardcode the response type. We could make it configurable
>  (provide the class name of the response type we want).
>
>
Different Response can be set already, via Application::setResponse(). Well,
could be, but that method as I pointed out tests for Http\Response. Change
that to test for Stdlib\ResponseDescription and all is fine again.


> * Don't worry about it. Really, Application simply checks that we have a
>  Zend\Stdlib\ResponseDescription, not that it's HTTP. Let our
>  application create an appropriate response.
>

Replied above.


>
> * Have a separate module for CLI execution. This could likely be seeded
>  all the same information that the web application is, but would be
>  injecting CLI requests and returning CLI responses, and potentially
>  replacing routing with Getopt.
>
>
Well, with the changes as above, a CLI module (or whatever it's/will be
called you thread stealers!) on top of this is not far away and most likely
would be implemented by the community in a matter of days :)

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

Re: ZF2 MVC Prototype

Gregory
In reply to this post by weierophinney
Hi Matthew,

In Application.php, initial presumption would be that

line 215:
$params['__RESULT__'] = $routeMatch;

and line 252
$params['result'] =& $result;

Should both use the same array key index, e.g. __RESULT__? Otherwise
it is not obvious without further examination why they are different
and for what purpose?

I would also ask what is the motivation in using a reference
assignment in the latter above?

And in the Application::dispatch method:

$params['result'] =& $result;
$events->trigger('dispatch.post', $this, $params);
return $result;

Infers that an event handler would have to exist in order to transform
a returned array, e.g. ActionController::index() returns
array('content' => 'Placeholder page'), into a Response object?

As much as I somewhat see/like the prototype, it still leaves me with
open questions such as how would a particular controller action get
access to the resources within the application. I realize that the
initial answer is from the ServiceLocator. What I'm wondering is if
the Application class should implement both AppContext and the
ServiceLocator interface?

I haven't tried to execute the prototype so my apologies if these
questions are ill-suited.

I think my outstanding concern in the all this is the forced usage of
a DI for controllers, for example a controller has 50 action methods,
each has varying dependencies, it would not be optimal to inject all
dependencies if the one action method being executed for that request
did not need all (or none) of them? Otherwise I'm not sure how
controller/DI implementation would not get out of hand.

--
Greg

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


Reply | Threaded
Open this post in threaded view
|

Re: ZF2 MVC Prototype

weierophinney
Administrator
In reply to this post by padraicb
-- Pádraic Brady <[hidden email]> wrote
(on Tuesday, 06 September 2011, 11:34 AM -0700):

> > As promised (though a little later than hoped), I've committed a
> > prototype for what the MVC _could_ look like for ZF2. It's in my
> > "prototype/mvc-module" branch on github:
> >
> >     https://github.com/weierophinney/zf2/tree/prototype/mvc-module
> >
> > In talking with Rob Allen (Akrabat) last week, I decided to try making
> > the MVC a "module", which means that you'll find it in the
> > "modules/Zf2Mvc" subdirectory:
> >
> >    
> > https://github.com/weierophinney/zf2/tree/prototype/mvc-module/modules/Zf2Mvc
>
> Come to me, pretty prototype :P. I'll try to find time to take it for a whirl soon.
>
> I will disagree with the Module format - we don't need to encapsulate
> generic libraries (define that as you will) in framework specific
> structures. I'll hardly be taking new libraries I create outside ZF
> and putting them into a special ZF box when they can just as easily be
> installed through PEAR/Pyrus/Composer or cloned from Github. How do
> other users without Zend Framework MVC install these
> Modules-once-Components? What are the technical benefits of this
> approach? Before adopting such an architectural change we *should*
> have had an RFC describing it, especially since it's off on a tangent
> to the existing RFC. In noting this on IRC, I've even heard that the
> idea of using Pyrus has suddenly become another point needing a
> decision - presumably because turning Components into Modules requires
> a change in our assumptions. That's a quick and drastic turnabout in
> where we were originally heading with Modules as being pretty much
> what they were trying to be in ZF1 - sets of
> controllers/views/models/services/assets representing a reusable
> integratable piece of an application. I just don't see how pushing the
> trappings of one specific framework onto other libraries benefits
> anyone.

The usage of a module was as much an idea to prototype as the MVC was
itself. The main things it enabled for me were as follows:

 * Ease of testing and prototyping. I could include only the exact new
   code I wanted to try out, and test it separately from the ZF2 library
   itself.

 * Enabled me to show off how one could build an MVC using the "building
   blocks" provided in the ZF2 library. This could serve as a blueprint
   for others with specific needs that lie outside what we deliver.

 * Provide documentation specific to a suite of functionality, rather
   than individual components.

The format is not unlike what is being discussed with the modules RFC:
http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+ZF2+Modules -- and,
in point of fact, I chose the format for the prototype based on a
discussion I was having with Rob Allen last week -- we felt it might
help show off some of the ideas surrounding the RFC in a more concrete
way.

All this said, I'm not necessarily advocating components as modules --
I'm simply prototyping two ideas:

 * A potential MVC that could exist parallel to the ZF1-style
   implementation currently in the core, and

 * A potential layout for a module, one that contains primarily library
   code.

--
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]


123