Zend Framework 2.0 Roadmap

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Zend Framework 2.0 Roadmap

weierophinney
Administrator
Hey, all --

There have been a ton of questions about the ZF 2.0 roadmap, and my
answer has been consistently, "I'm working on it; I'll have something to
publish soon."

"Soon" is now:

    http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap

I'd like you, as contributors, to look over it, and start discussing the
various ramifications; we can do that either in comments to the pages or
on this list.

The roadmap is primarily a conceptual one right now, though a
proof-of-concept has been created for the proposed MVC. I'd like to stay
fairly high-level for now, and then start getting a flow of proposals
into the system for specific migration-related tasks.

Thanks everyone who has provided me input over the past many months, and
let's get started on the next generation of ZF!

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Benjamin Eberlei-2
looks great!

how will we conceptionally move from php 5.x to 5.3? might it be a good idea
to implement a rough tokenizer => transformer to apply for example the
following rules:

1. collect all classes and interfaces using Reflection and Zend_Reflection_File.

Package_Subpackage_Class => Package\Subpackage\Class

if(Class == Abstract)
Class = SubpackageAbstract

if(Class == Interface)
Class = Subpackage

if(Class == Exception)
class = ExceptionImpl implements Exception
+ Interface Exception

2. Define all exceptions to this rule in a simple array map (important for most
of the interfaces).

3. iterate over the code with a tokenizer on a file basis, find all INTERFACE
and CLASS tokens and when re-applying them to the file change with the new
code.

Imho this would be better than to ask all the maintainers to make the
migration, since that will probably take several months and make it incredible
hard to work with the trunk.

greetings,
Benjamin

On Wednesday 11 November 2009 07:38:57 pm Matthew Weier O'Phinney wrote:

> Hey, all --
>
> There have been a ton of questions about the ZF 2.0 roadmap, and my
> answer has been consistently, "I'm working on it; I'll have something to
> publish soon."
>
> "Soon" is now:
>
>    
> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>
> I'd like you, as contributors, to look over it, and start discussing the
> various ramifications; we can do that either in comments to the pages or
> on this list.
>
> The roadmap is primarily a conceptual one right now, though a
> proof-of-concept has been created for the proposed MVC. I'd like to stay
> fairly high-level for now, and then start getting a flow of proposals
> into the system for specific migration-related tasks.
>
> Thanks everyone who has provided me input over the past many months, and
> let's get started on the next generation of ZF!


--
Benjamin Eberlei
http://www.beberlei.de

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

weierophinney
Administrator
-- Benjamin Eberlei <[hidden email]> wrote
(on Wednesday, 11 November 2009, 08:06 PM +0100):

> looks great!
>
> how will we conceptionally move from php 5.x to 5.3? might it be a good idea
> to implement a rough tokenizer => transformer to apply for example the
> following rules:
>
> 1. collect all classes and interfaces using Reflection and Zend_Reflection_File.
>
> Package_Subpackage_Class => Package\Subpackage\Class
>
> if(Class == Abstract)
> Class = SubpackageAbstract
>
> if(Class == Interface)
> Class = Subpackage
>
> if(Class == Exception)
> class = ExceptionImpl implements Exception
> + Interface Exception
>
> 2. Define all exceptions to this rule in a simple array map (important for most
> of the interfaces).
>
> 3. iterate over the code with a tokenizer on a file basis, find all INTERFACE
> and CLASS tokens and when re-applying them to the file change with the new
> code.
>
> Imho this would be better than to ask all the maintainers to make the
> migration, since that will probably take several months and make it incredible
> hard to work with the trunk.

My thought is that we can do the first pass using something like this,
and then go through manually to do more targetted changes. Stas has done
something like this already previously, and I hope to get some code from
him so we can work on it.

In looking at your above notes, I realize that there's another change
that needs to be noted in the docs: targetting the PHP Interop Group's
specifications. The Exception usage is in line with our current
discussions, already. The package naming will work -- but the ideal is
to ship package names as all lowercase. Any script for migration will
need to take that into account as well.


> On Wednesday 11 November 2009 07:38:57 pm Matthew Weier O'Phinney wrote:
> > Hey, all --
> >
> > There have been a ton of questions about the ZF 2.0 roadmap, and my
> > answer has been consistently, "I'm working on it; I'll have something to
> > publish soon."
> >
> > "Soon" is now:
> >
> >    
> > http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
> >
> > I'd like you, as contributors, to look over it, and start discussing the
> > various ramifications; we can do that either in comments to the pages or
> > on this list.
> >
> > The roadmap is primarily a conceptual one right now, though a
> > proof-of-concept has been created for the proposed MVC. I'd like to stay
> > fairly high-level for now, and then start getting a flow of proposals
> > into the system for specific migration-related tasks.
> >
> > Thanks everyone who has provided me input over the past many months, and
> > let's get started on the next generation of ZF!
>
>
> --
> Benjamin Eberlei
> http://www.beberlei.de
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

padraicb
In reply to this post by Benjamin Eberlei-2
+1 to Benjamin's idea - though as a standalone script each maintainer can run in isolation per component (provide time for review/documentation changes). This is really a cleanup exercise more than anything - I'm guessing more than a few maintainers will not be sure of the 5.3 changes just yet. I know I messed up a bit on Zend_Feed_Reader scarcely days before the 1.9 release because of my own lack of attention on 5.3 minutiae.

Is 5.3 addressed anywhere in the coding standard yet?

Paddy
 
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative



From: Benjamin Eberlei <[hidden email]>
To: [hidden email]
Sent: Wed, November 11, 2009 7:06:10 PM
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

looks great!

how will we conceptionally move from php 5.x to 5.3? might it be a good idea
to implement a rough tokenizer => transformer to apply for example the
following rules:

1. collect all classes and interfaces using Reflection and Zend_Reflection_File.

Package_Subpackage_Class => Package\Subpackage\Class

if(Class == Abstract)
Class = SubpackageAbstract

if(Class == Interface)
Class = Subpackage

if(Class == Exception)
class = ExceptionImpl implements Exception
+ Interface Exception

2. Define all exceptions to this rule in a simple array map (important for most
of the interfaces).

3. iterate over the code with a tokenizer on a file basis, find all INTERFACE
and CLASS tokens and when re-applying them to the file change with the new
code.

Imho this would be better than to ask all the maintainers to make the
migration, since that will probably take several months and make it incredible
hard to work with the trunk.

greetings,
Benjamin

On Wednesday 11 November 2009 07:38:57 pm Matthew Weier O'Phinney wrote:
> Hey, all --
>
> There have been a ton of questions about the ZF 2.0 roadmap, and my
> answer has been consistently, "I'm working on it; I'll have something to
> publish soon."
>
> "Soon" is now:
>
>   
> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap

>
> I'd like you, as contributors, to look over it, and start discussing the
> various ramifications; we can do that either in comments to the pages or
> on this list.
>
> The roadmap is primarily a conceptual one right now, though a
> proof-of-concept has been created for the proposed MVC. I'd like to stay
> fairly high-level for now, and then start getting a flow of proposals
> into the system for specific migration-related tasks.
>
> Thanks everyone who has provided me input over the past many months, and
> let's get started on the next generation of ZF!


--
Benjamin Eberlei
http://www.beberlei.de
Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Robin Skoglund
In reply to this post by weierophinney
On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney <[hidden email]> wrote:
>
> In looking at your above notes, I realize that there's another change
> that needs to be noted in the docs: targetting the PHP Interop Group's
> specifications. The Exception usage is in line with our current
> discussions, already. The package naming will work -- but the ideal is
> to ship package names as all lowercase. Any script for migration will
> need to take that into account as well.

Do you have a link for the PHP Interop Group specifications? I was
about to make a comment in the wiki about the Exception usage, but I
guess I should read up on the mentioned docs first.

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

guilhermeblanco@gmail.com
http://groups.google.com/group/php-standards/web/final-proposal

On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[hidden email]> wrote:

> On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney <[hidden email]> wrote:
>>
>> In looking at your above notes, I realize that there's another change
>> that needs to be noted in the docs: targetting the PHP Interop Group's
>> specifications. The Exception usage is in line with our current
>> discussions, already. The package naming will work -- but the ideal is
>> to ship package names as all lowercase. Any script for migration will
>> need to take that into account as well.
>
> Do you have a link for the PHP Interop Group specifications? I was
> about to make a comment in the wiki about the Exception usage, but I
> guess I should read up on the mentioned docs first.
>



--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [hidden email]
URL: http://blog.bisna.com
São Paulo - SP/Brazil

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

umpirsky
Very nice!

What about Zend_Model? Will we have some official component for M in MVC, or we will stay on VC in zf 2.0?
Will Zend_Tool get more powerful, generating models from db scheme, unit tests etc?

Regards,
Saša Stamenković


On Wed, Nov 11, 2009 at 9:37 PM, Guilherme Blanco <[hidden email]> wrote:
http://groups.google.com/group/php-standards/web/final-proposal

On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[hidden email]> wrote:
> On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney <[hidden email]> wrote:
>>
>> In looking at your above notes, I realize that there's another change
>> that needs to be noted in the docs: targetting the PHP Interop Group's
>> specifications. The Exception usage is in line with our current
>> discussions, already. The package naming will work -- but the ideal is
>> to ship package names as all lowercase. Any script for migration will
>> need to take that into account as well.
>
> Do you have a link for the PHP Interop Group specifications? I was
> about to make a comment in the wiki about the Exception usage, but I
> guess I should read up on the mentioned docs first.
>



--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: [hidden email]
URL: http://blog.bisna.com
São Paulo - SP/Brazil

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

A.J. Brown-3
Integration with Doctrine 2.0 is currently being discussed.  It's
generally agreed that we don't need yet another ORM.

On Thu, Nov 12, 2009 at 2:22 AM, Саша Стаменковић <[hidden email]> wrote:

> Very nice!
> What about Zend_Model? Will we have some official component for M in MVC, or
> we will stay on VC in zf 2.0?
> Will Zend_Tool get more powerful, generating models from db scheme, unit
> tests etc?
>
> Regards,
> Saša Stamenković
>
>
> On Wed, Nov 11, 2009 at 9:37 PM, Guilherme Blanco
> <[hidden email]> wrote:
>>
>> http://groups.google.com/group/php-standards/web/final-proposal
>>
>> On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[hidden email]> wrote:
>> > On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney
>> > <[hidden email]> wrote:
>> >>
>> >> In looking at your above notes, I realize that there's another change
>> >> that needs to be noted in the docs: targetting the PHP Interop Group's
>> >> specifications. The Exception usage is in line with our current
>> >> discussions, already. The package naming will work -- but the ideal is
>> >> to ship package names as all lowercase. Any script for migration will
>> >> need to take that into account as well.
>> >
>> > Do you have a link for the PHP Interop Group specifications? I was
>> > about to make a comment in the wiki about the Exception usage, but I
>> > guess I should read up on the mentioned docs first.
>> >
>>
>>
>>
>> --
>> Guilherme Blanco - Web Developer
>> CBC - Certified Bindows Consultant
>> Cell Phone: +55 (16) 9215-8480
>> MSN: [hidden email]
>> URL: http://blog.bisna.com
>> São Paulo - SP/Brazil
>
>



--
A.J. Brown
web | http://ajbrown.org
phone | (937) 660-3969

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Kevin McArthur-2
In reply to this post by weierophinney
I guess I'll chime in, and stir the pot a bit. All IMHO of course....

The good:

Namespaces, Creation of components for general-purpose cross-functional actions, Usage of new language features within plugin architectures, Autoload-only.

The Bad:

1 ) Unified constructor. All constructors will (optionally) accept an array of options or Zend_Config object as the first argument.

I take exception to this because, well, it's just going to kill performance -- and it doesn't follow industry standard techniques for this type of thing. This shouldn't be a rule as a ton of classes have no reason to be configurable, or make a lot more sense to take real parameters, rather than instantiating a new object. Instead, I recommend a Configurable interface which _may_ mark classes as configurable as needed.

2 ) Exception interfacing

Why mess with it? All the SPL exceptions descend from Exception and can be caught/thrown as any normal exception can be. Exceptions should continue to contain the Exception class inheritance hierarchy.

>From the markup:

try { 
    throw new InvalidArgumentException(); 
} catch (\Foo\Bar\Exception $e) { 

Can just be:

try { 
    throw new InvalidArgumentException(); 
} catch (Exception $e) { 

Without the marker interface. I must be missing something?

3) Design By Contract

I'm actually a big fan of contract programming, but, a framework must be fast -- and optimized. Contract programming is great as part of business process management, but it has serious runtime performance implications -- and worse, increases contribution overhead. Makes testing, acceptance testing easier, sure. But this could be realllllly limiting.

4) Getting rid of singletons.

Why does it make more sense to access the front controller via a registry? Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier to pick up the framework.

The Ugly:

The proposed changes to the core api (and to a large extent the framework additions since 1.0) really add complexity to the framework to the benefit of testing and other 'advanced' use. These changes do little, if anything to advance three goals I see as core requirements for 2.0:

a) Can a skilled PHP developer read and understand Zend Framework application code without more than an hour's primer on ZFW? Could they trace execution of the framework logically without a debugger? Jumps like GOTO's, fancy routers, registries, helpers, plugins, and DI models all work against this goal. Keep it simple.

b) Can a skilled PHP developer contribute a change to the framework easily without being involved in the ZFW core politics, contribution processes, proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to reduce the contribution overhead and encourage community participation?

c) Can a ZFW developer create products and services that leverage ZFW in an ecosystem of components? Is there a financial incentive for this? Currently, there's very little going on in terms of commercialized redistributable components -- How will ZFW 2.0 create, and integrate itself into a marketplace for ZFW apps, components, and tools? Official ZFW app/component store? ZFW cloud services?

The Atrocious:

Still nothing about an upgrading / security patches system. Still no components for detecting if an application is vulnerable, notifying system admins, or shutting down an installed base of vulnerable apps dependent on the framework. If the problems of the other major framework and cms vendors continue to be ignored, there will almost certainly be some sort of incident that will tarnish the frameworks reputation for security. At some point the framework is going to have to take version management more seriously than publishing patches to the website (a good first step, but miles away from where it needs to be).

--

I'd also add that there's probably an opportunity to look at phar-ization within the 2.0 line. Will the new loader support phar'd components, and how will that look? Zend_Tool? Configurable site images?

I'm sure theres more, but thats my $0.02 for now

Kevin McArthur


Matthew Weier O'Phinney wrote:
Hey, all --

There have been a ton of questions about the ZF 2.0 roadmap, and my
answer has been consistently, "I'm working on it; I'll have something to
publish soon."

"Soon" is now:

    http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap

I'd like you, as contributors, to look over it, and start discussing the
various ramifications; we can do that either in comments to the pages or
on this list.

The roadmap is primarily a conceptual one right now, though a
proof-of-concept has been created for the proposed MVC. I'd like to stay
fairly high-level for now, and then start getting a flow of proposals
into the system for specific migration-related tasks.

Thanks everyone who has provided me input over the past many months, and
let's get started on the next generation of ZF!

  

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Tommy Smith
Great Points Kevin - more like $.04 :-)
 
I am mostly worried about the changes to the exception interfacing. I am reviewing everything now but will give a few cents too.
 
Thanks,
Tommy Smith


 
On Thu, Nov 12, 2009 at 11:32 AM, Kevin McArthur <[hidden email]> wrote:
I guess I'll chime in, and stir the pot a bit. All IMHO of course....

The good:

Namespaces, Creation of components for general-purpose cross-functional actions, Usage of new language features within plugin architectures, Autoload-only.

The Bad:

1 ) Unified constructor. All constructors will (optionally) accept an array of options or Zend_Config object as the first argument.

I take exception to this because, well, it's just going to kill performance -- and it doesn't follow industry standard techniques for this type of thing. This shouldn't be a rule as a ton of classes have no reason to be configurable, or make a lot more sense to take real parameters, rather than instantiating a new object. Instead, I recommend a Configurable interface which _may_ mark classes as configurable as needed.

2 ) Exception interfacing

Why mess with it? All the SPL exceptions descend from Exception and can be caught/thrown as any normal exception can be. Exceptions should continue to contain the Exception class inheritance hierarchy.

From the markup:

try { 
    throw new InvalidArgumentException(); 
} catch (\Foo\Bar\Exception $e) { 

Can just be:

try { 
    throw new InvalidArgumentException(); 
} catch (Exception $e) { 

Without the marker interface. I must be missing something?

3) Design By Contract

I'm actually a big fan of contract programming, but, a framework must be fast -- and optimized. Contract programming is great as part of business process management, but it has serious runtime performance implications -- and worse, increases contribution overhead. Makes testing, acceptance testing easier, sure. But this could be realllllly limiting.

4) Getting rid of singletons.

Why does it make more sense to access the front controller via a registry? Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier to pick up the framework.

The Ugly:

The proposed changes to the core api (and to a large extent the framework additions since 1.0) really add complexity to the framework to the benefit of testing and other 'advanced' use. These changes do little, if anything to advance three goals I see as core requirements for 2.0:

a) Can a skilled PHP developer read and understand Zend Framework application code without more than an hour's primer on ZFW? Could they trace execution of the framework logically without a debugger? Jumps like GOTO's, fancy routers, registries, helpers, plugins, and DI models all work against this goal. Keep it simple.

b) Can a skilled PHP developer contribute a change to the framework easily without being involved in the ZFW core politics, contribution processes, proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to reduce the contribution overhead and encourage community participation?

c) Can a ZFW developer create products and services that leverage ZFW in an ecosystem of components? Is there a financial incentive for this? Currently, there's very little going on in terms of commercialized redistributable components -- How will ZFW 2.0 create, and integrate itself into a marketplace for ZFW apps, components, and tools? Official ZFW app/component store? ZFW cloud services?

The Atrocious:

Still nothing about an upgrading / security patches system. Still no components for detecting if an application is vulnerable, notifying system admins, or shutting down an installed base of vulnerable apps dependent on the framework. If the problems of the other major framework and cms vendors continue to be ignored, there will almost certainly be some sort of incident that will tarnish the frameworks reputation for security. At some point the framework is going to have to take version management more seriously than publishing patches to the website (a good first step, but miles away from where it needs to be).

--

I'd also add that there's probably an opportunity to look at phar-ization within the 2.0 line. Will the new loader support phar'd components, and how will that look? Zend_Tool? Configurable site images?

I'm sure theres more, but thats my $0.02 for now

Kevin McArthur


Matthew Weier O'Phinney wrote:
Hey, all --

There have been a ton of questions about the ZF 2.0 roadmap, and my
answer has been consistently, "I'm working on it; I'll have something to
publish soon."

"Soon" is now:

    http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap

I'd like you, as contributors, to look over it, and start discussing the
various ramifications; we can do that either in comments to the pages or
on this list.

The roadmap is primarily a conceptual one right now, though a
proof-of-concept has been created for the proposed MVC. I'd like to stay
fairly high-level for now, and then start getting a flow of proposals
into the system for specific migration-related tasks.

Thanks everyone who has provided me input over the past many months, and
let's get started on the next generation of ZF!

  


Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Dolf Schimmel
In reply to this post by umpirsky
Zend_Tool is getting more powerful with every sunset, The first
results of this can be seen with 1.10. I propose however against an
'official' Zend_Model. There are zillions (not sure how many that is;
but it's a lot) ways of implementing models. We can impossibly think
of a model/class that supports all of these different methods.

Dolf

On Thu, Nov 12, 2009 at 8:22 AM, Саша Стаменковић <[hidden email]> wrote:

> Very nice!
> What about Zend_Model? Will we have some official component for M in MVC, or
> we will stay on VC in zf 2.0?
> Will Zend_Tool get more powerful, generating models from db scheme, unit
> tests etc?
>
> Regards,
> Saša Stamenković
>
>
> On Wed, Nov 11, 2009 at 9:37 PM, Guilherme Blanco
> <[hidden email]> wrote:
>>
>> http://groups.google.com/group/php-standards/web/final-proposal
>>
>> On Wed, Nov 11, 2009 at 6:28 PM, Robin Skoglund <[hidden email]> wrote:
>> > On Wed, Nov 11, 2009 at 20:40, Matthew Weier O'Phinney
>> > <[hidden email]> wrote:
>> >>
>> >> In looking at your above notes, I realize that there's another change
>> >> that needs to be noted in the docs: targetting the PHP Interop Group's
>> >> specifications. The Exception usage is in line with our current
>> >> discussions, already. The package naming will work -- but the ideal is
>> >> to ship package names as all lowercase. Any script for migration will
>> >> need to take that into account as well.
>> >
>> > Do you have a link for the PHP Interop Group specifications? I was
>> > about to make a comment in the wiki about the Exception usage, but I
>> > guess I should read up on the mentioned docs first.
>> >
>>
>>
>>
>> --
>> Guilherme Blanco - Web Developer
>> CBC - Certified Bindows Consultant
>> Cell Phone: +55 (16) 9215-8480
>> MSN: [hidden email]
>> URL: http://blog.bisna.com
>> São Paulo - SP/Brazil
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

weierophinney
Administrator
In reply to this post by Kevin McArthur-2
-- Kevin McArthur <[hidden email]> wrote
(on Thursday, 12 November 2009, 10:32 AM -0800):
<snip>

> The Bad:
>
> 1 ) Unified constructor. All constructors will (optionally) accept an array of
> options or Zend_Config object as the first argument.
>
> I take exception to this because, well, it's just going to kill performance --
> and it doesn't follow industry standard techniques for this type of thing. This
> shouldn't be a rule as a ton of classes have no reason to be configurable, or
> make a lot more sense to take real parameters, rather than instantiating a new
> object. Instead, I recommend a Configurable interface which _may_ mark classes
> as configurable as needed.

That makes sense, and I'm open to that.

That said, if a component has dependencies on other components or makes
use of other components, I think the pattern should be mandatory.
Dependency Injection -- note, I'm NOT saying DI containers -- is much
simpler with this pattern.

> 2 ) Exception interfacing
>
> Why mess with it? All the SPL exceptions descend from Exception and can be
> caught/thrown as any normal exception can be. Exceptions should continue to
> contain the Exception class inheritance hierarchy.

The rationale is because it allows us to catch either based on the SPL
exception type OR the component exception type. It's more flexible.

Each component Exception would inherit from the zend\Exception marker
interface -- so, again, there'd still be the Exception inheritance
hierarchy, but also a hierarchy for general purpose exceptions.

Finally, the paradigm encourages creating exceptions for each type of
exceptional situation, instead of having a generic exception per
component. This will make debugging easier, as well as

As an example, using an SPL-based exception:

    try {
        throw new InvalidArgumentException();
    } catch (\zend\foo\Exception $e) {        // or
    } catch (\zend\Exception $e) {            // or
    } catch (\InvalidArgumentException $e) {  // or
    } catch (\Exception $e) {
    }

All are viable - it gives you, the developer, more choices in how you
handle exceptions.

> From the markup:
>
> try {
>     throw new InvalidArgumentException();
> } catch (\Foo\Bar\Exception $e) {
> }
>
> Can just be:
>
> try {
>     throw new InvalidArgumentException();
> } catch (Exception $e) {
> }
>
> Without the marker interface. I must be missing something?

Yes. See above.

> 3) Design By Contract
>
> I'm actually a big fan of contract programming, but, a framework must be fast
> -- and optimized. Contract programming is great as part of business process
> management, but it has serious runtime performance implications -- and worse,
> increases contribution overhead. Makes testing, acceptance testing easier,
> sure. But this could be realllllly limiting.

Ummmmm.... I don't think we're talking about the same thing here.

Design by contract, in its most simplified form, refers to the idea of
programming to interfaces. This simply means that we'll be ensuring that
we have solid, concise interfaces for each component, which will allow
developers to create their own implementations when they're needs
deviate from those shipped.

This actually will have some substantial benefits. First, we can have a
more conventions based approach, which allows us to develop more
targetted, performant code since we're no longer worrying about edge
cases created by configurability. This brings me to my second point: it
pushes the burden of custom and fringe use cases onto individual
developers instead of the framework -- which allows us to focus on
maintaining the core functionality. This will lead to a better product
with fewer open issues. Third, it makes testing much easier,
particularly when considering components with adapters -- you can
implement a given interface in order to test the functionality instead
of needing to override an existing class.

In terms of contribution overhead, it means that part of any component
design will be ascertaining the basic, essential functionality and
creating an interface that encapsulates it; this is just good
programming.

Basically, everything you cite as potential problems are actually
addressed with this decision.

> 4) Getting rid of singletons.
>
> Why does it make more sense to access the front controller via a registry?
> Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier
> to pick up the framework.

We're not accessing the front controller via a registry. It's simply not
going to be a singleton. The ideas posted use injection to pass objects
around, and do so in a very simple manner. Take a look at the
proof-of-concept I posted before jumping to conclusions.

Singletons have been the source of a ton of pain in testing and
bugfixing -- and there's very little reason for most of them to exist.

> The Ugly:
>
> The proposed changes to the core api (and to a large extent the framework
> additions since 1.0) really add complexity to the framework to the benefit of
> testing and other 'advanced' use.

We're getting rid of complexity and focussing on a simplified,
consistent API. I fail to see how you're reaching your conclusions.

> These changes do little, if anything to advance three goals I see as
> core requirements for 2.0:
>
> a) Can a skilled PHP developer read and understand Zend Framework application
> code without more than an hour's primer on ZFW? Could they trace execution of
> the framework logically without a debugger? Jumps like GOTO's, fancy routers,
> registries, helpers, plugins, and DI models all work against this goal. Keep it
> simple.

Please, please, please read the code and examples before you make these
assumptions.

The new MVC design is not going to be something a developer will need to
understand in order to use it; they will simply need to *use* it. They
won't need to know that it uses a finite state machine under the hood --
they'll only need to know what events and states are available (and
there's *ahem* a finite number of them). Tracing the code execution
should rarely be necessary, but the new prototype is actually far, far
simpler than the current Zend_Controller execution cycle.

(Aside: the router is not likely changing much, except internally.)

> b) Can a skilled PHP developer contribute a change to the framework easily
> without being involved in the ZFW core politics, contribution processes,
> proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for
> this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to
> reduce the contribution overhead and encourage community participation?

Please elaborate on how "ZFW sucks for this."

Our policy has been that contributions require unit tests and
documentation, plain and simple. Yes, it's a barrier to entry -- but it
also helps to ensure the quality of the code and that users have the
information they need to use it. If we don't require that level of
contribution, we'll be doing everyone a dis-service.

Right now, there really are no "core politics". Everything goes through
the contribution process. Yes, myself and my team help determine the
roadmap -- but even the roadmap is open for discussion. This is open
source.

> c) Can a ZFW developer create products and services that leverage ZFW in an
> ecosystem of components? Is there a financial incentive for this? Currently,
> there's very little going on in terms of commercialized redistributable
> components -- How will ZFW 2.0 create, and integrate itself into a marketplace
> for ZFW apps, components, and tools? Official ZFW app/component store? ZFW
> cloud services?

My team has had zero time to focus on a forge-like site for components,
though it's something we'd all like to see.  A large part of the reason
for our lack of time is due to the amount of maintenance required on ZF.
Most of the changes proposed for 2.0 are intended to lighten that
burden, which would make the above much more possible in the future.

> The Atrocious:
>
> Still nothing about an upgrading / security patches system.

This is my bad -- I meant to include information on this as part of the
proposal. A big effort for 2.0 will be creating resources to aid in
migration. A big part of the MVC proof of concept was creating something
that could live side-by-side the current implementation and potentially
even make use of it (the demo uses a number of existing components).
We're taking that very seriously.

As for security patches, the plan is to patch existing stable code, as
well as the previous 2 minor branches, and make releases of each.

> Still no components for detecting if an application is vulnerable,
> notifying system admins, or shutting down an installed base of
> vulnerable apps dependent on the framework.  If the problems of the
> other major framework and cms vendors continue to be ignored, there
> will almost certainly be some sort of incident that will tarnish the
> frameworks reputation for security. At some point the framework is
> going to have to take version management more seriously than
> publishing patches to the website (a good first step, but miles away
> from where it needs to be).

If you're interested in such components, then please help make them a
possibility. Don't expect everyone else to do the work for you. As
noted, my team is small and our resources spread thin. Help us and the
rest of the community out.

> --
>
> I'd also add that there's probably an opportunity to look at phar-ization
> within the 2.0 line. Will the new loader support phar'd components, and how
> will that look? Zend_Tool? Configurable site images?

I've already experimented with Phar and ZF 1.X. It requires minimal
changes to the autoloader for it to work out of the box.


> I'm sure theres more, but thats my $0.02 for now
>
> Kevin McArthur
>
>
> Matthew Weier O'Phinney wrote:
>
>     Hey, all --
>
>     There have been a ton of questions about the ZF 2.0 roadmap, and my
>     answer has been consistently, "I'm working on it; I'll have something to
>     publish soon."
>
>     "Soon" is now:
>
>         http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>
>     I'd like you, as contributors, to look over it, and start discussing the
>     various ramifications; we can do that either in comments to the pages or
>     on this list.
>
>     The roadmap is primarily a conceptual one right now, though a
>     proof-of-concept has been created for the proposed MVC. I'd like to stay
>     fairly high-level for now, and then start getting a flow of proposals
>     into the system for specific migration-related tasks.
>
>     Thanks everyone who has provided me input over the past many months, and
>     let's get started on the next generation of ZF!
>
>
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Carlos Medina
In reply to this post by Kevin McArthur-2
1.- Unified constructor. *All* ...

Yes Kevin Agree that. Instead of Configurable Interface, you can add an
Object of Zend_Config, if you need to configure some thing.

2 ) Exception interfacing
Absolutlely

4) Getting rid of singletons.

Well yes. I agree that. I think that the ZF should be easy and simple to
use. At this moment i think that ZF pretend to be a big Framework for
all and at the end will be used only for two or tree developer.

Carlos



Kevin McArthur schrieb:

> I guess I'll chime in, and stir the pot a bit. All IMHO of course....
>
> The good:
>
> Namespaces, Creation of components for general-purpose
> cross-functional actions, Usage of new language features within plugin
> architectures, Autoload-only.
>
> The Bad:
>
> 1 ) Unified constructor. *All* constructors will (optionally) accept
> an array of options or Zend_Config object as the first argument.
>
> I take exception to this because, well, it's just going to kill
> performance -- and it doesn't follow industry standard techniques for
> this type of thing. This shouldn't be a rule as a ton of classes have
> no reason to be configurable, or make a lot more sense to take real
> parameters, rather than instantiating a new object. Instead, I
> recommend a *Configurable interface* which _may_ mark classes as
> configurable as needed.
>
> 2 ) Exception interfacing
>
> Why mess with it? All the SPL exceptions descend from Exception and
> can be caught/thrown as any normal exception can be. Exceptions should
> continue to contain the Exception class inheritance hierarchy.
>
> From the markup:
>
> try {    throw new InvalidArgumentException(); } catch
> (\Foo\Bar\Exception $e) { }
>
> Can just be:
>
> try {    throw new InvalidArgumentException(); } catch (Exception $e) { }
>
> Without the marker interface. I must be missing something?
>
> 3) Design By Contract
>
> I'm actually a big fan of contract programming, but, a framework must
> be fast -- and optimized. Contract programming is great as part of
> business process management, but it has serious runtime performance
> implications -- and worse, increases contribution overhead. Makes
> testing, acceptance testing easier, sure. But this could be realllllly
> limiting.
>
> 4) Getting rid of singletons.
>
> Why does it make more sense to access the front controller via a
> registry? Surely this can't meet the 80/20 rule? Keep the singletons,
> they make it easier to pick up the framework.
>
> The Ugly:
>
> The proposed changes to the core api (and to a large extent the
> framework additions since 1.0) really add complexity to the framework
> to the benefit of testing and other 'advanced' use. These changes do
> little, if anything to advance three goals I see as core requirements
> for 2.0:
>
> a) Can a skilled PHP developer read and understand Zend Framework
> application code without more than an hour's primer on ZFW? Could they
> trace execution of the framework logically without a debugger? Jumps
> like GOTO's, fancy routers, registries, helpers, plugins, and DI
> models all work against this goal. Keep it simple.
>
> b) Can a skilled PHP developer contribute a change to the framework
> easily without being involved in the ZFW core politics, contribution
> processes, proposal processes, test writing, doc writing, etc.
> Currently, ZFW sucks for this, but didn't until after the 1.0 line was
> out. What will ZFW 2.0 do to reduce the contribution overhead and
> encourage community participation?
>
> c) Can a ZFW developer create products and services that leverage ZFW
> in an ecosystem of components? Is there a financial incentive for
> this? Currently, there's very little going on in terms of
> commercialized redistributable components -- How will ZFW 2.0 create,
> and integrate itself into a marketplace for ZFW apps, components, and
> tools? Official ZFW app/component store? ZFW cloud services?
>
> The Atrocious:
>
> Still nothing about an upgrading / security patches system. Still no
> components for detecting if an application is vulnerable, notifying
> system admins, or shutting down an installed base of vulnerable apps
> dependent on the framework. If the problems of the other major
> framework and cms vendors continue to be ignored, there will almost
> certainly be some sort of incident that will tarnish the frameworks
> reputation for security. At some point the framework is going to have
> to take version management more seriously than publishing patches to
> the website (a good first step, but miles away from where it needs to
> be).
>
> --
>
> I'd also add that there's probably an opportunity to look at
> phar-ization within the 2.0 line. Will the new loader support phar'd
> components, and how will that look? Zend_Tool? Configurable site images?
>
> I'm sure theres more, but thats my $0.02 for now
>
> Kevin McArthur
>
>
> Matthew Weier O'Phinney wrote:
>> Hey, all --
>>
>> There have been a ton of questions about the ZF 2.0 roadmap, and my
>> answer has been consistently, "I'm working on it; I'll have something to
>> publish soon."
>>
>> "Soon" is now:
>>
>>    
>> http://framework.zend.com/wiki/display/ZFDEV2/Zend+Framework+2.0+Roadmap
>>
>> I'd like you, as contributors, to look over it, and start discussing the
>> various ramifications; we can do that either in comments to the pages or
>> on this list.
>>
>> The roadmap is primarily a conceptual one right now, though a
>> proof-of-concept has been created for the proposed MVC. I'd like to stay
>> fairly high-level for now, and then start getting a flow of proposals
>> into the system for specific migration-related tasks.
>>
>> Thanks everyone who has provided me input over the past many months, and
>> let's get started on the next generation of ZF!
>>
>>  
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Giorgio Sironi
On Thu, Nov 12, 2009 at 8:51 PM, Carlos Medina <[hidden email]> wrote:
4) Getting rid of singletons.

Well yes. I agree that. I think that the ZF should be easy and simple to use. At this moment i think that ZF pretend to be a big Framework for all and at the end will be used only for two or tree developer.

I could not understand if you favor singletons or their removal. Anyway, "singletons are pathological liars" and presents global state which makes hard to debug and test classes that use them. It is actually simpler to provide a collaborator in the constructor instead of hide it in a singleton accessed via static functions.

--
Giorgio Sironi
Piccolo Principe & Web Engineer
http://giorgiosironi.blogspot.com
http://twitter.com/giorgiosironi
Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Kevin McArthur-2
In reply to this post by weierophinney
Reply inline.

Matthew Weier O'Phinney wrote:
<snip>

That makes sense, and I'm open to that. 

That said, if a component has dependencies on other components or makes
use of other components, I think the pattern should be mandatory.
Dependency Injection -- note, I'm NOT saying DI containers -- is much
simpler with this pattern.

  
Can we define components? Classes within their own namespace? If so, I'm cool with that. Off the top of my head my main thinking is like PDF Points, Rects, Cirlces etc... these make no sense to be 'configurable'. But they all exist within their own namespace.  Configuration standards when crossing namespaces... that makes sense.
The rationale is because it allows us to catch either based on the SPL
exception type OR the component exception type. It's more flexible.

Each component Exception would inherit from the zend\Exception marker
interface -- so, again, there'd still be the Exception inheritance
hierarchy, but also a hierarchy for general purpose exceptions.

Finally, the paradigm encourages creating exceptions for each type of
exceptional situation, instead of having a generic exception per
component. This will make debugging easier, as well as 

As an example, using an SPL-based exception:

    try {
        throw new InvalidArgumentException();
    } catch (\zend\foo\Exception $e) {        // or
    } catch (\zend\Exception $e) {            // or
    } catch (\InvalidArgumentException $e) {  // or
    } catch (\Exception $e) {
    }

All are viable - it gives you, the developer, more choices in how you
handle exceptions.
  
So we're trying to add an extra catch-case for zend specific exceptions? If so dont we already have Zend_Exception? I don't see any reason not to do this, but then, I'm not sure its really necessary? With autoloading the overhead should be relatively small (classes arent computed till needed)... so... whatever?


Ummmmm.... I don't think we're talking about the same thing here.
  
We are.
Design by contract, in its most simplified form, refers to the idea of
programming to interfaces. This simply means that we'll be ensuring that
we have solid, concise interfaces for each component, which will allow
developers to create their own implementations when they're needs
deviate from those shipped.

  
The issue is that programming by contract adds little value when applied universally (i've got some really nasty db-binding interfaces growing around here)

Interfaces are useful sure, but like tests, they're only useful when written from a different perspective than the implementation. My attempt to fix a bug in zend's wildfire layer only to run into a case where a test checked for not implemented as a response being a prime example. The same will happen with rigid interfaces as with rigid tests.

I strongly suggest only using interfaces where there are actual points of interoperability, instead of for each public method for example.
This actually will have some substantial benefits. First, we can have a
more conventions based approach, which allows us to develop more
targetted, performant code since we're no longer worrying about edge
cases created by configurability. This brings me to my second point: it
pushes the burden of custom and fringe use cases onto individual
developers instead of the framework -- which allows us to focus on
maintaining the core functionality. This will lead to a better product
with fewer open issues. Third, it makes testing much easier,
particularly when considering components with adapters -- you can
implement a given interface in order to test the functionality instead
of needing to override an existing class.
  
I agree that it makes testing easier, but disagree that it leads to performance. Loading large interfaces (picture the size of an interface for Zend_Pdf or Zend_Db for examples) .... really adds to loading overhead.  Also, if you start really talking about interfaces and DI, you get into a lot of runtime use of the instanceof operator -- and that saps performance too.
In terms of contribution overhead, it means that part of any component
design will be ascertaining the basic, essential functionality and
creating an interface that encapsulates it; this is just good
programming.
  
This is where it will get in the way. Now not only do you have to write the code you want to contribute (something many of us do as an ancillary benefit to 'Actually Getting Stuff Done') but also an Interface, Tests, Documentation and probably some ZF tracker stuff. Wow, overhead. I don't have time for it -- and I'm not alone in that, I assure you. Don't get me wrong, its nice to have all those things, but not at the expense of the actual functionality getting checked in. Maybe I'm ****ing in the wind, but can we try to lower the contribution overhead? I'm willing to send in commented, code-level patches as I go about my normal dev, but those who sponsor that work aren't willing to pay for me to write tests and docs for the stuff I improve. This leads to most of my zfw improvements going uncontributed, or when they encompass major libs, forked off from the core and released independently where they don't do as many people as good as they could if they were part of zfw.

Basically, everything you cite as potential problems are actually
addressed with this decision
  
4) Getting rid of singletons.

Why does it make more sense to access the front controller via a registry?
Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier
to pick up the framework.
    

We're not accessing the front controller via a registry. It's simply not
going to be a singleton. The ideas posted use injection to pass objects
around, and do so in a very simple manner. Take a look at the
proof-of-concept I posted before jumping to conclusions.

Singletons have been the source of a ton of pain in testing and
bugfixing -- and there's very little reason for most of them to exist.

  
I'm poking around in it, but I'm not sure I see how 'the' front controller will be accessed. Whats the equivilent call to Zend_Controller_Front::getInstance().... somewhere's gonna have to be a registry (or at least a responsible object) if thats not singleton-ized.

I'm looking at
http://github.com/weierophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php
for example, and I definitely don't think this is easier to grasp than the singleton fc approach.

  
The Ugly:

The proposed changes to the core api (and to a large extent the framework
additions since 1.0) really add complexity to the framework to the benefit of
testing and other 'advanced' use. 
    

We're getting rid of complexity and focussing on a simplified,
consistent API. I fail to see how you're reaching your conclusions.
  
Maybe you see it that way... I'm not sure I do. The DI stuff is definitely not straightforward compared to whats there now. The comment refers to the new things since 1.0 really that haven't helped make
things better. See the end of (a) below. The <=1.0 line was dead simple, wasn't much use of helpers, plugins, brokers, registries etc... everything kinda flowed from a->b->c and it was more mvc-ish in its code separation. now its definitely a lot more RDMVCHP.. (router-dispatcher-model-view-controller-helper-plugin) ... add a few layers of Zend_Application+Zend_Config integration and the like and it gets even worse.

  
These changes do little, if anything to advance three goals I see as
core requirements for 2.0:

a) Can a skilled PHP developer read and understand Zend Framework application
code without more than an hour's primer on ZFW? Could they trace execution of
the framework logically without a debugger? Jumps like GOTO's, fancy routers,
registries, helpers, plugins, and DI models all work against this goal. Keep it
simple.
    

Please, please, please read the code and examples before you make these
assumptions.
  
I have read what is linked from that page you posted. So some of this might be assumption, but im not sure much is.
The new MVC design is not going to be something a developer will need to
understand in order to use it; they will simply need to *use* it.
I don't agree with this. IMHO, If you can't trace it under the hood -- it's too complicated. I can't stress enough how important it is for people working with ZFW to actually
understand how ZFW works, and to be able to trace their application's execution conceptually. PHP isn't an SDK language and ZFW shouldn't aim to be a SDK framework. The whole execution process should follow an easily traced path from start to finish.

 They won't need to know that it uses a finite state machine under the hood --
they'll only need to know what events and states are available (and
there's *ahem* a finite number of them). Tracing the code execution
should rarely be necessary, but the new prototype is actually far, far
simpler than the current Zend_Controller execution cycle.
  
I disagree. I think its important that the average user can _easily_ understand how the application works through all phases of execution.


  
b) Can a skilled PHP developer contribute a change to the framework easily
without being involved in the ZFW core politics, contribution processes,
proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for
this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to
reduce the contribution overhead and encourage community participation?
    

Please elaborate on how "ZFW sucks for this."
Our policy has been that contributions require unit tests and
documentation, plain and simple. Yes, it's a barrier to entry -- but it
also helps to ensure the quality of the code and that users have the
information they need to use it. If we don't require that level of
contribution, we'll be doing everyone a dis-service.
Right now, there really are no "core politics". Everything goes through
the contribution process. Yes, myself and my team help determine the
roadmap -- but even the roadmap is open for discussion. This is open
source.

  

See previous comments on the interface stuff. Same stuff applies.

c) Can a ZFW developer create products and services that leverage ZFW in an
ecosystem of components? Is there a financial incentive for this? Currently,
there's very little going on in terms of commercialized redistributable
components -- How will ZFW 2.0 create, and integrate itself into a marketplace
for ZFW apps, components, and tools? Official ZFW app/component store? ZFW
cloud services?
    

My team has had zero time to focus on a forge-like site for components,
though it's something we'd all like to see.  A large part of the reason
for our lack of time is due to the amount of maintenance required on ZF.
Most of the changes proposed for 2.0 are intended to lighten that
burden, which would make the above much more possible in the future.
  
Fair enough, though, I'm less concerned with the 'forge' site and more concerned about flushing out the component model (packs, modules, phars?, plugins... what are we calling an encapsulated archive of zfw 'stuff' now). That should definitely be considered pre-2.0 as it will require considerations on everything from routers, dispatchers, layouts, controllers and views.
  
The Atrocious:

Still nothing about an upgrading / security patches system. 
    

This is my bad -- I meant to include information on this as part of the
proposal. A big effort for 2.0 will be creating resources to aid in
migration. A big part of the MVC proof of concept was creating something
that could live side-by-side the current implementation and potentially
even make use of it (the demo uses a number of existing components).
We're taking that very seriously.
  
:) Glad to hear this.
As for security patches, the plan is to patch existing stable code, as
well as the previous 2 minor branches, and make releases of each.
  
A good first step as I said below, but we need the USN's, the 'is this site afflicted' data. (Eg does line x of /library/zend/whatever.php = this, if so, vuln)... we need this type of data on an ongoing basis to build out the tools -> see below..

  
Still no components for detecting if an application is vulnerable,
notifying system admins, or shutting down an installed base of
vulnerable apps dependent on the framework.  If the problems of the
other major framework and cms vendors continue to be ignored, there
will almost certainly be some sort of incident that will tarnish the
frameworks reputation for security. At some point the framework is
going to have to take version management more seriously than
publishing patches to the website (a good first step, but miles away
from where it needs to be).
    

If you're interested in such components, then please help make them a
possibility. Don't expect everyone else to do the work for you. As
noted, my team is small and our resources spread thin. Help us and the
rest of the community out.
  
I don't expect them to, and I've been trying to help get this done for some time. That said, theres no tool I can make without vulnerability data. There's no disclosure list, no feed or web service that we could script against. This has to come from the release management side of things. I've had some productive discussions about doing the scripting within the Zend_Tool framework -- but thats as far as it gets.

If you publish the data, I'll write the tools (though, i'll leave it to your team to write the tests <grin>)

Ideally a csv (or xml) like....

ZFV (zend framework vulnerability) Number  | File | Line | Match | Patch | Remarks
ZFV-123 | library/Zend/Whatever.php | 12 | if($this->somethingIsBad) | ZFV-123.patch | You'll have to also change your bootstrap from this to that.

Given that, we can write sites, and potentially tools that would check themselves automatically.

I've previously proposed adding this to Zend_Version, but maybe theres a more appropriate place?  IMHO this should be a 2.0 line build requirement.


--

I'd also add that there's probably an opportunity to look at phar-ization
within the 2.0 line. Will the new loader support phar'd components, and how
will that look? Zend_Tool? Configurable site images?
    

I've already experimented with Phar and ZF 1.X. It requires minimal
changes to the autoloader for it to work out of the box.
  
OooOOo gimme gimme.... Docs, blog post? How does it work with overlaying views, layouts, controllers, models, extending/replacing core zend libraries, etc?

Anyway, hope that elaborates and is more helpful than it is not =P

Kevin


Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Andy Thompson
*Unified constructor
*Is the overhead in converting to camelCase worth using
underscore_seperated keys? It would seem more practical to stick to
camelCase as that requires minimal conversion to function standards.
*
**Exceptions*.
Interesting use of exception intefaces and namespaces, I like the
possibilities of doing this.

*Design By Contract*.
I agree that ZF should use interfaces a lot more in the library,
especially for things like Zend_Db_Adapter. There have been many times
that I've been frustrated that I have to subclass an abstract that I
have to override all the functions. These cases tend to be where the
abstract is fullfilling the role of an interface, so an interface placed
there wont cause additional overhead.

This also helps with writing proxy classes that still need to use the
framework's implementations.

*Elimination of most singletons*.
I agree, Singletons are just as bad as having globals. In most cases it
should be up to the developer what should be accessible like this. I
tend to try to only have a single top level class (Application.php),
which defines the application's globals, and passes these into the
component classes.

*Usage of new language features within plugin architectures
*Definitely, I see these features as a much needed improvement to the
php language, and ZF supporting them just makes it easier

*Autoload-only
*I'm a recent convert to the autoload process, so yes I like this idea

*goto
*(cringe) but I guess if it makes things structurally better sense
*

Regards

Andy
*

Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

padraicb
In reply to this post by Kevin McArthur-2
We should probably get rid of the "design by contract" terminology - many of us will take it at face value as referring to the software engineering concept with all the bells and whistles attached.

>This is where it will get in the way. Now not only do you have to write the code you want to contribute
>(something many of us do as an ancillary benefit to 'Actually Getting Stuff Done') but also an Interface,
>Tests, Documentation and probably some ZF tracker stuff. Wow, overhead. I don't have time for it -- and
>I'm not alone in that, I assure you. Don't get me wrong, its nice to have all those things, but not at
>the expense of the actual functionality getting checked in. Maybe I'm ****ing in the wind, but can we try
>to lower the contribution overhead? I'm willing to send in commented, code-level patches as I go about my
>normal dev, but those who sponsor that work aren't willing to pay for me to write tests and docs for the
>stuff I improve. This leads to most of my zfw improvements going uncontributed, or when they encompass
>major libs, forked off from the core and released independently where they don't do as many people as
>good as they could if they were part of zfw.

To be honest, I don't follow Kevin's objections. Every line of code written is a constant fight between two metrics - performance and flexibility. Interfaces assist flexibility by allowing for substitution - an amazingly powerful capability in a framework (as a certain framework outside of PHP has quickly learned with a little prompting from a more flexible sibling). Eliminating flexibility for the sake of performance is a dangerous road to follow blindly. Conventions play a role in minimising the risks, and experience eliminates the remainder - and this is exactly what Matthew is identifying. With a few years of ZF 1.0 behind us, 2.0 can balance both a lot better where it really really counts.

The main wall Kevin just hit is simply never going away. If it ever did, ZF wouldn't be far behind it as a untested, undocumented morass of code that (allegedly) does stuff. We need all the "contribution overhead". It is absolutely essential. There are components in the ZF which, to be generous, are pretty bad in terms of testing, documentation and flexibility already - and that's with the requirement! I have worse descriptions. Catch me on IRC during a bug hunt and I'll share some ;).

The fact is, if you cannot handle the additional work that underpins, supports and ensures ease of maintenance for a component - then you are begging for a developer to start swearing over IRC. I had the joy of dealing with such a component a few weeks back. It took me hours to figure out a bug. Why? Because the unit tests DID NOT TEST the functionality of the component. I could have deleted every single test with no ill effect - they were all busy with XML parsing or something (performed by a completely different component with its own perfectly functional unit tests).

But worse than all this, is the assumption that lowering the contribution overhead is a positive thing. It's not - it merely shifts that work onto someone else. Someone else with precious little time and a chargeout rate to justify work with. And surprise - they won't like that in the slightest. Sometimes you get lucky - I spent about 10 hours of otherwise chargeable time in September's bug hunt (which I enjoyed a lot by the way) along with several evenings but generally everyday work will always lean towards ignoring contributions where no supporting "contribution overhead" has also been committed. Such contributions/patches/whatever can be horrible to work on. No tests, poor explanations, lack of communication, differing assumptions - ugh. If it's not worth contributing in full, don't expect someone else to do it - they probably won't.

Sorry for the ranty piece - but code doesn't write itself. It is great to have a contribution - so long as you don't pin it all on someone else ;).

>Interfaces are useful sure, but like tests, they're only useful when written from a different perspective
>than the implementation. My attempt to fix a bug in zend's wildfire layer only to run into a case where a
>test checked for not implemented as a response being a prime example. The same will happen with rigid
>interfaces as with rigid tests.

Interfaces are supposed to be rigid. What Matthew is attempting to emphasis to you is that an interface should address the "core" functionality. Adding interface defs for every single public method is all too common, and all too unnecessary.

If you described the example a bit, it might help you see what is being aimed at here - and where that wildfire component probably went awry.

>I agree that it makes testing easier, but disagree that it leads to performance. Loading large interfaces
>(picture the size of an interface for Zend_Pdf or Zend_Db for examples) .... really adds to loading
>overhead.  Also, if you start really talking about interfaces and DI, you get into a lot of runtime use
>of the instanceof operator -- and that saps performance too.

Missing the point. Interfaces are rigid - less scope for edge cases, mishaps, misunderstandings - i.e. the resulting code can afford to be leaner, focused and (by praying to XDebug and sacrificing goats on the alter of "try, try again") hopefully be more performant.

>>In terms of contribution overhead, it means that part of any component
>>design will be ascertaining the basic, essential functionality and
>>creating an interface that encapsulates it; this is just good
>>programming.
>
>This is where it will get in the way. [...]

No, this is where it's supposed to begin. If, like me, you are a total TDD fanboy ;). In TDD, the API comes first. From the targeted API flows the Interface. From the Interface flows an obedient implementing class. Granted it's a very specific methodology I'm using as an example. For someone using TDD, an Interface is almost a certainty - it will warp and change over time but that evolution will reflect the very core functionality of the implementation. Even without TDD, that should be pretty common - where else is the API coming from?

>I'm poking around in it, but I'm not sure I see how 'the' front controller will be accessed. Whats the
>equivilent call to Zend_Controller_Front::getInstance().... somewhere's gonna have to be a registry (or
>at least a responsible object) if thats not singleton-ized.

Which one? Nobody said there would be one front controller. My guess, is that it will be accessible from your bootstrap, which is registered to the front controller, which is registered to...I'm lost now. It will be injected into wherever it tends to be most useful. Just not globally as a singleton. Bear in the current singleton usage encourages a disregard for injection - which is used by the other 99% of inputs into classes like helpers, plugins, etc. Replace Frontcontroller with any other component - you should get the same answer for the new Frontcontroller. It's not some oddball, hyper-weird class that needs special treatment.

>The DI stuff is definitely not straightforward compared to whats there now.

What's there right now is DI - as a patchwork of different approaches however which make the APIs more unpredictable than they should be. If you mean a DI Framework - pretty sure that is not on the agenda. The closest to a DI Framework is Zend_Application - which is stretching that concept an awful lot.

>I don't agree with this. IMHO, If you can't trace it under the hood -- it's too complicated. I can't
>stress enough how important it is for people working with ZFW to actually
>understand how ZFW works, and to be able to trace their application's execution conceptually. PHP isn't
>an SDK language and ZFW shouldn't aim to be a SDK framework. The whole execution process should follow an
>easily traced path from start to finish.

Trace what under the hood? Request->Route->Dispatch->Controller->Action <- stick plugins in between. It's not rocket science. If you doubled the complexity of the implementation today, it would still quack like the same duck it was yesterday. Right now you can still conceptually grasp MVC and use it, without ever reading the source code. In fact, right now MVC is a pretty complex beast in ZF. It would take a serious effort to complicate it further :).

>Can a skilled PHP developer contribute a change to the framework easily
>without being involved in the ZFW core politics, contribution processes,
>proposal processes, test writing, doc writing, etc.

ZF may be one of the few non-political projects around. I've had some fun of course butting heads in the past, but the last two years have been politics free. Everything else is answered "no". Who else is going to miraculously write someone else's tests/docs/proposals? Not me :P.

Paddy.
 
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative



From: Kevin McArthur <[hidden email]>
To: [hidden email]
Sent: Thu, November 12, 2009 9:41:59 PM
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Reply inline.

Matthew Weier O'Phinney wrote:
<snip>
That makes sense, and I'm open to that. 

That said, if a component has dependencies on other components or makes
use of other components, I think the pattern should be mandatory.
Dependency Injection -- note, I'm NOT saying DI containers -- is much
simpler with this pattern.

Can we define components? Classes within their own namespace? If so, I'm cool with that. Off the top of my head my main thinking is like PDF Points, Rects, Cirlces etc... these make no sense to be 'configurable'. But they all exist within their own namespace.  Configuration standards when crossing namespaces... that makes sense.
The rationale is because it allows us to catch either based on the SPL
exception type OR the component exception type. It's more flexible.

Each component Exception would inherit from the zend\Exception marker
interface -- so, again, there'd still be the Exception inheritance
hierarchy, but also a hierarchy for general purpose exceptions.

Finally, the paradigm encourages creating exceptions for each type of
exceptional situation, instead of having a generic exception per
component. This will make debugging easier, as well as

As an example, using an SPL-based exception:

try {
throw new InvalidArgumentException();
} catch (\zend\foo\Exception $e) { // or
} catch (\zend\Exception $e) { // or
} catch (\InvalidArgumentException $e) { // or
} catch (\Exception $e) {
}

All are viable - it gives you, the developer, more choices in how you
handle exceptions.
So we're trying to add an extra catch-case for zend specific exceptions? If so dont we already have Zend_Exception? I don't see any reason not to do this, but then, I'm not sure its really necessary? With autoloading the overhead should be relatively small (classes arent computed till needed)... so... whatever?

Ummmmm.... I don't think we're talking about the same thing here.
We are.
Design by contract, in its most simplified form, refers to the idea of
programming to interfaces. This simply means that we'll be ensuring that
we have solid, concise interfaces for each component, which will allow
developers to create their own implementations when they're needs
deviate from those shipped.

The issue is that programming by contract adds little value when applied universally (i've got some really nasty db-binding interfaces growing around here)

Interfaces are useful sure, but like tests, they're only useful when written from a different perspective than the implementation. My attempt to fix a bug in zend's wildfire layer only to run into a case where a test checked for not implemented as a response being a prime example. The same will happen with rigid interfaces as with rigid tests.

I strongly suggest only using interfaces where there are actual points of interoperability, instead of for each public method for example.
This actually will have some substantial benefits. First, we can have a
more conventions based approach, which allows us to develop more
targetted, performant code since we're no longer worrying about edge
cases created by configurability. This brings me to my second point: it
pushes the burden of custom and fringe use cases onto individual
developers instead of the framework -- which allows us to focus on
maintaining the core functionality. This will lead to a better product
with fewer open issues. Third, it makes testing much easier,
particularly when considering components with adapters -- you can
implement a given interface in order to test the functionality instead
of needing to override an existing class.
I agree that it makes testing easier, but disagree that it leads to performance. Loading large interfaces (picture the size of an interface for Zend_Pdf or Zend_Db for examples) .... really adds to loading overhead.  Also, if you start really talking about interfaces and DI, you get into a lot of runtime use of the instanceof operator -- and that saps performance too.
In terms of contribution overhead, it means that part of any component
design will be ascertaining the basic, essential functionality and
creating an interface that encapsulates it; this is just good
programming.
This is where it will get in the way. Now not only do you have to write the code you want to contribute (something many of us do as an ancillary benefit to 'Actually Getting Stuff Done') but also an Interface, Tests, Documentation and probably some ZF tracker stuff. Wow, overhead. I don't have time for it -- and I'm not alone in that, I assure you. Don't get me wrong, its nice to have all those things, but not at the expense of the actual functionality getting checked in. Maybe I'm ****ing in the wind, but can we try to lower the contribution overhead? I'm willing to send in commented, code-level patches as I go about my normal dev, but those who sponsor that work aren't willing to pay for me to write tests and docs for the stuff I improve. This leads to most of my zfw improvements going uncontributed, or when they encompass major libs, forked off from the core and released independently where they don't do as many people as good as they could if they were part of zfw.

Basically, everything you cite as potential problems are actually
addressed with this decision
4) Getting rid of singletons.

Why does it make more sense to access the front controller via a registry?
Surely this can't meet the 80/20 rule? Keep the singletons, they make it easier
to pick up the framework.
We're not accessing the front controller via a registry. It's simply not
going to be a singleton. The ideas posted use injection to pass objects
around, and do so in a very simple manner. Take a look at the
proof-of-concept I posted before jumping to conclusions.

Singletons have been the source of a ton of pain in testing and
bugfixing -- and there's very little reason for most of them to exist.

I'm poking around in it, but I'm not sure I see how 'the' front controller will be accessed. Whats the equivilent call to Zend_Controller_Front::getInstance().... somewhere's gonna have to be a registry (or at least a responsible object) if thats not singleton-ized.

I'm looking at
http://github.com/weierophinney/phly/blob/mvcfsm/Phly_Mvc/demo/application/Bootstrap.php
for example, and I definitely don't think this is easier to grasp than the singleton fc approach.

  
The Ugly:

The proposed changes to the core api (and to a large extent the framework
additions since 1.0) really add complexity to the framework to the benefit of
testing and other 'advanced' use.
We're getting rid of complexity and focussing on a simplified,
consistent API. I fail to see how you're reaching your conclusions.
Maybe you see it that way... I'm not sure I do. The DI stuff is definitely not straightforward compared to whats there now. The comment refers to the new things since 1.0 really that haven't helped make
things better. See the end of (a) below. The <=1.0 line was dead simple, wasn't much use of helpers, plugins, brokers, registries etc... everything kinda flowed from a->b->c and it was more mvc-ish in its code separation. now its definitely a lot more RDMVCHP.. (router-dispatcher-model-view-controller-helper-plugin) ... add a few layers of Zend_Application+Zend_Config integration and the like and it gets even worse.

  
These changes do little, if anything to advance three goals I see as
core requirements for 2.0:

a) Can a skilled PHP developer read and understand Zend Framework application
code without more than an hour's primer on ZFW? Could they trace execution of
the framework logically without a debugger? Jumps like GOTO's, fancy routers,
registries, helpers, plugins, and DI models all work against this goal. Keep it
simple.
Please, please, please read the code and examples before you make these
assumptions.
I have read what is linked from that page you posted. So some of this might be assumption, but im not sure much is.
The new MVC design is not going to be something a developer will need to
understand in order to use it; they will simply need to *use* it.
I don't agree with this. IMHO, If you can't trace it under the hood -- it's too complicated. I can't stress enough how important it is for people working with ZFW to actually
understand how ZFW works, and to be able to trace their application's execution conceptually. PHP isn't an SDK language and ZFW shouldn't aim to be a SDK framework. The whole execution process should follow an easily traced path from start to finish.

 They won't need to know that it uses a finite state machine under the hood --
they'll only need to know what events and states are available (and
there's *ahem* a finite number of them). Tracing the code execution
should rarely be necessary, but the new prototype is actually far, far
simpler than the current Zend_Controller execution cycle.
I disagree. I think its important that the average user can _easily_ understand how the application works through all phases of execution.


  
b) Can a skilled PHP developer contribute a change to the framework easily
without being involved in the ZFW core politics, contribution processes,
proposal processes, test writing, doc writing, etc. Currently, ZFW sucks for
this, but didn't until after the 1.0 line was out. What will ZFW 2.0 do to
reduce the contribution overhead and encourage community participation?
Please elaborate on how "ZFW sucks for this."
Our policy has been that contributions require unit tests and
documentation, plain and simple. Yes, it's a barrier to entry -- but it
also helps to ensure the quality of the code and that users have the
information they need to use it. If we don't require that level of
contribution, we'll be doing everyone a dis-service.
Right now, there really are no "core politics". Everything goes through
the contribution process. Yes, myself and my team help determine the
roadmap -- but even the roadmap is open for discussion. This is open
source.


See previous comments on the interface stuff. Same stuff applies.

c) Can a ZFW developer create products and services that leverage ZFW in an
ecosystem of components? Is there a financial incentive for this? Currently,
there's very little going on in terms of commercialized redistributable
components -- How will ZFW 2.0 create, and integrate itself into a marketplace
for ZFW apps, components, and tools? Official ZFW app/component store? ZFW
cloud services?
My team has had zero time to focus on a forge-like site for components,
though it's something we'd all like to see. A large part of the reason
for our lack of time is due to the amount of maintenance required on ZF.
Most of the changes proposed for 2.0 are intended to lighten that
burden, which would make the above much more possible in the future.
Fair enough, though, I'm less concerned with the 'forge' site and more concerned about flushing out the component model (packs, modules, phars?, plugins... what are we calling an encapsulated archive of zfw 'stuff' now). That should definitely be considered pre-2.0 as it will require considerations on everything from routers, dispatchers, layouts, controllers and views.
  
The Atrocious:

Still nothing about an upgrading / security patches system.
This is my bad -- I meant to include information on this as part of the
proposal. A big effort for 2.0 will be creating resources to aid in
migration. A big part of the MVC proof of concept was creating something
that could live side-by-side the current implementation and potentially
even make use of it (the demo uses a number of existing components).
We're taking that very seriously.
:) Glad to hear this.
As for security patches, the plan is to patch existing stable code, as
well as the previous 2 minor branches, and make releases of each.
A good first step as I said below, but we need the USN's, the 'is this site afflicted' data. (Eg does line x of /library/zend/whatever.php = this, if so, vuln)... we need this type of data on an ongoing basis to build out the tools -> see below..

  
Still no components for detecting if an application is vulnerable,
notifying system admins, or shutting down an installed base of
vulnerable apps dependent on the framework. If the problems of the
other major framework and cms vendors continue to be ignored, there
will almost certainly be some sort of incident that will tarnish the
frameworks reputation for security. At some point the framework is
going to have to take version management more seriously than
publishing patches to the website (a good first step, but miles away
from where it needs to be).
If you're interested in such components, then please help make them a
possibility. Don't expect everyone else to do the work for you. As
noted, my team is small and our resources spread thin. Help us and the
rest of the community out.
I don't expect them to, and I've been trying to help get this done for some time. That said, theres no tool I can make without vulnerability data. There's no disclosure list, no feed or web service that we could script against. This has to come from the release management side of things. I've had some productive discussions about doing the scripting within the Zend_Tool framework -- but thats as far as it gets.

If you publish the data, I'll write the tools (though, i'll leave it to your team to write the tests <grin>)

Ideally a csv (or xml) like....

ZFV (zend framework vulnerability) Number  | File | Line | Match | Patch | Remarks
ZFV-123 | library/Zend/Whatever.php | 12 | if($this->somethingIsBad) | ZFV-123.patch | You'll have to also change your bootstrap from this to that.

Given that, we can write sites, and potentially tools that would check themselves automatically.

I've previously proposed adding this to Zend_Version, but maybe theres a more appropriate place?  IMHO this should be a 2.0 line build requirement.


--

I'd also add that there's probably an opportunity to look at phar-ization
within the 2.0 line. Will the new loader support phar'd components, and how
will that look? Zend_Tool? Configurable site images?
I've already experimented with Phar and ZF 1.X. It requires minimal
changes to the autoloader for it to work out of the box.
OooOOo gimme gimme.... Docs, blog post? How does it work with overlaying views, layouts, controllers, models, extending/replacing core zend libraries, etc?

Anyway, hope that elaborates and is more helpful than it is not =P

Kevin


Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Kevin McArthur-2
Pádraic Brady wrote:

The main wall Kevin just hit is simply never going away. If it ever did, ZF wouldn't be far behind it as a untested, undocumented morass of code that (allegedly) does stuff.
I doubt this greatly, ZF to 1.0 was a huge success and had none of this stuff. A decent vetting by interested coders was all it took to keep the quality up. Most of that code still comprises the code base today, and it still runs fine. The docs were enough to get interested developers over the initial hurdles and the rest came through other sources like blogs, irc, books and sample code. I'm not saying we go back to totally untested code or anything like that, I guess I just see tests like icing, not an ingredient. If there's tests, great, if not, put it on the todo and move on. Instead we've got tests that are at times even counter-productive as you describe.

We need all the "contribution overhead". It is absolutely essential. There are components in the ZF which, to be generous, are pretty bad in terms of testing, documentation and flexibility already - and that's with the requirement! I have worse descriptions. Catch me on IRC during a bug hunt and I'll share some ;).

I'd argue that some of those components are bad in part because of the requirement.

The fact is, if you cannot handle the additional work that underpins, supports and ensures ease of maintenance for a component - then you are begging for a developer to start swearing over IRC. I had the joy of dealing with such a component a few weeks back. It took me hours to figure out a bug. Why? Because the unit tests DID NOT TEST the functionality of the component. I could have deleted every single test with no ill effect - they were all busy with XML parsing or something (performed by a completely different component with its own perfectly functional unit tests).
That sounds about right.

But worse than all this, is the assumption that lowering the contribution overhead is a positive thing. It's not - it merely shifts that work onto someone else.
That assumes that a large amount of this work isn't optional -- when it is. Those useless tests are there because someone said 'must have tests', many, possibly most, of them are totally unneeded except to up the code coverage report statistics. A minority of the ZFW tests do any useful testing, and for those, I'm glad there's tests... and I believe those tests would still be there if they weren't required to be.
Someone else with precious little time and a chargeout rate to justify work with. And surprise - they won't like that in the slightest. Sometimes you get lucky - I spent about 10 hours of otherwise chargeable time in September's bug hunt (which I enjoyed a lot by the way) along with several evenings but generally everyday work will always lean towards ignoring contributions where no supporting "contribution overhead" has also been committed. Such contributions/patches/whatever can be horrible to work on. No tests, poor explanations, lack of communication, differing assumptions - ugh. If it's not worth contributing in full, don't expect someone else to do it - they probably won't.
I suspect many wont expect their contributions to be accepted -- and instead of capitulating to the requirements, will simply abandon the contribution.

Sorry for the ranty piece - but code doesn't write itself. It is great to have a contribution - so long as you don't pin it all on someone else ;).
Pin what? When I developed the Zend PDF image parsers for example, I didn't write any tests, I did functional testing to the best I could.... and we went from there. Those classes exist in the framework today in basically the same format. That contribution process was very different from today, but it worked great. I'd hate to think what it would take to get a class as complicated as Zend_Pdf_Resource_Image_Tiff committed today....

Which one? Nobody said there would be one front controller.
For 99.999% of uses theres only one url, and only a need for one front controller.
My guess, is that it will be accessible from your bootstrap, which is registered to the front controller, which is registered to...I'm lost now.
I think you just made my point.

Trace what under the hood? Request->Route->Dispatch->Controller->Action <- stick plugins in between. It's not rocket science.
Add into that Zend_Application->Zend_Config->Get Bootstrap Name Setting->do whatever *secret sauce*->all before you get to the mvc dispatch process above. Now, from the code source I looked at before, its going to require creating some sort of methodinvokers, event delegates and hooking into a series of events. Tracing back from output to figure out where something is happening truly is a science these days -- most of the time I end up pecking around in the leaves, instead of tracing from the trunk. It gets even more complicated when you start talking partials, helpers( think actionstack ), and the myriad of other ways to inject into the request cycle.
If you doubled the complexity of the implementation today, it would still quack like the same duck it was yesterday.
We agree here. Today is too complicated... Tomorrow will be too complicated... I was hoping with 2.0 that we would figure out where the redundancies are and nix em --> i'd start at the actionstack, but thats just me. Now we're talking FSM's, and DI systems... which is cool in a compsci kinda way, but fantastically complicated out of the box.

Is it a SDK, a black box, or are we helping people make applications they understand? Whats the implication of blind use of the framework?
Right now you can still conceptually grasp MVC and use it, without ever reading the source code. In fact, right now MVC is a pretty complex beast in ZF. It would take a serious effort to complicate it further :).
Theres a reason we write books on this stuff instead of user docs.....

>Can a skilled PHP developer contribute a change to the framework easily
>without being involved in the ZFW core politics, contribution processes,
>proposal processes, test writing, doc writing, etc.

ZF may be one of the few non-political projects around. I've had some fun of course butting heads in the past, but the last two years have been politics free. Everything else is answered "no". Who else is going to miraculously write someone else's tests/docs/proposals? Not me :P.
"No" is a policy, and its not a very good one.

$0.02

Kevin
Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

padraicb
>I doubt this greatly, ZF to 1.0 was a huge success and had none of this stuff. A decent vetting by interested coders was all it took to keep the quality up. Most of that
>code still comprises the code base today, and it still runs fine. The docs were enough to get interested developers over the initial hurdles and the rest came through other
>sources like blogs, irc, books and sample code. I'm not saying we go back to totally untested code or anything like that, I guess I just see tests like icing, not an
>ingredient. If there's tests, great, if not, put it on the todo and move on. Instead we've got tests that are at times even counter-productive as you describe.

That's a massively misleading statement. I was around pre-1.0 too. The number of components and lines-of-code were a tiny fraction of what currently exists, and oddly enough, even at that there were tests and docs. ZF 0.x without those would never have been a success. Counter-productive tests are a problem - unfortunately overview has been lacking in the past otherwise they'd have been noticed a lot sooner. Not to drag this into a present context - as far as I know Matthew does review new test suites as part of the review process.

>I'd argue that some of those components are bad in part because of the requirement.

No, they are bad in spite of the requirement. Tests, docs or nothing at all - bad code is bad code.

>That assumes that a large amount of this work isn't optional -- when it is. Those useless tests are there because someone said 'must have tests', many, possibly most, of
>them are totally unneeded except to up the code coverage report statistics. A minority of the ZFW tests do any useful testing, and for those, I'm glad there's tests... and I
>believe those tests would still be there if they weren't required to be.

I agree the code coverage is sometimes horribly artificial (personally I believe a coverage of 60% is acceptable in a lot of cases - I do add stupid little tests to get to 85% like testing getters (ye gods) or worse). It's always a complaint when I run code coverage on a shiny new class and it pops a 55% coverage ;). I know the tests are sufficient but a rule is a rule since, as many tests prove, you really can't trust all developers. Even I make silly typos at times - even in dumb getters sometimes.

Nevertheless, whether the rule adds work or not - the point is that the work must get done one way or another before any contribution can be committed to trunk for the next release.

>I suspect many wont expect their contributions to be accepted -- and instead of capitulating to the requirements, will simply abandon the contribution.

Already happening to be honest. Unfortunately, I'm unwilling to vet every single contribution and patch, and so are the contributors. It's going to happen a lot.

>I think you just made my point.

Rest of quote? ;) The front controller is just another object - how do you get any other object in whatever class you need it? It's not something magical...

>I'd hate to think what it would take to get a class as complicated as Zend_Pdf_Resource_Image_Tiff committed today....

Probably the same effort - with testing. I'm a fan of TDD though so I'm totally biased in favour of a test driven approach - I've yet to find anything too complex to handle with it.

>We agree here. Today is too complicated... Tomorrow will be too complicated... I was hoping with 2.0 that we would figure out where the redundancies are and nix em >--> i'd start at the actionstack, but thats just me. Now we're talking FSM's, and DI systems... which is cool in a compsci kinda way, but fantastically complicated out of >the box.
>Is it a SDK, a black box, or are we helping people make applications they understand? Whats the implication of blind use of the framework?

Same could be said of namespaces, closures, all that other compsci ECMA stuff. DI and FSM are not complicated or weird or conceptually difficult - they are merely different. What we have at the moment is more familiar - and a mess. Unfortunately, ZF or not, MVC is always going to be more complicated as it needs more features. The C part of MVC remains the most expensive part of ZF performance wise. That won't change, but maybe the new concepts will help. They surely will NOT make it more complex. Whether it simplifies anything - open question to Matthew? ;)

>Theres a reason we write books on this stuff instead of user docs.....

Devs are horrible writers. Unrelated, but true! The manual has become a monster read.

>"No" is a policy, and its not a very good one.

Don't get me wrong - I agree it's not the best policy ever, but who's going to contribute the resources to make the policy "yes"? In reality a "no" is the only possible answer in an open source project with limited resources.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative



From: Kevin McArthur <[hidden email]>
To: Pádraic Brady <[hidden email]>
Cc: Zend Framework Contributors <[hidden email]>
Sent: Fri, November 13, 2009 12:58:43 AM
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Pádraic Brady wrote:

The main wall Kevin just hit is simply never going away. If it ever did, ZF wouldn't be far behind it as a untested, undocumented morass of code that (allegedly) does stuff.
I doubt this greatly, ZF to 1.0 was a huge success and had none of this stuff. A decent vetting by interested coders was all it took to keep the quality up. Most of that code still comprises the code base today, and it still runs fine. The docs were enough to get interested developers over the initial hurdles and the rest came through other sources like blogs, irc, books and sample code. I'm not saying we go back to totally untested code or anything like that, I guess I just see tests like icing, not an ingredient. If there's tests, great, if not, put it on the todo and move on. Instead we've got tests that are at times even counter-productive as you describe.

We need all the "contribution overhead". It is absolutely essential. There are components in the ZF which, to be generous, are pretty bad in terms of testing, documentation and flexibility already - and that's with the requirement! I have worse descriptions. Catch me on IRC during a bug hunt and I'll share some ;).

I'd argue that some of those components are bad in part because of the requirement.

The fact is, if you cannot handle the additional work that underpins, supports and ensures ease of maintenance for a component - then you are begging for a developer to start swearing over IRC. I had the joy of dealing with such a component a few weeks back. It took me hours to figure out a bug. Why? Because the unit tests DID NOT TEST the functionality of the component. I could have deleted every single test with no ill effect - they were all busy with XML parsing or something (performed by a completely different component with its own perfectly functional unit tests).
That sounds about right.

But worse than all this, is the assumption that lowering the contribution overhead is a positive thing. It's not - it merely shifts that work onto someone else.
That assumes that a large amount of this work isn't optional -- when it is. Those useless tests are there because someone said 'must have tests', many, possibly most, of them are totally unneeded except to up the code coverage report statistics. A minority of the ZFW tests do any useful testing, and for those, I'm glad there's tests... and I believe those tests would still be there if they weren't required to be.
Someone else with precious little time and a chargeout rate to justify work with. And surprise - they won't like that in the slightest. Sometimes you get lucky - I spent about 10 hours of otherwise chargeable time in September's bug hunt (which I enjoyed a lot by the way) along with several evenings but generally everyday work will always lean towards ignoring contributions where no supporting "contribution overhead" has also been committed. Such contributions/patches/whatever can be horrible to work on. No tests, poor explanations, lack of communication, differing assumptions - ugh. If it's not worth contributing in full, don't expect someone else to do it - they probably won't.
I suspect many wont expect their contributions to be accepted -- and instead of capitulating to the requirements, will simply abandon the contribution.

Sorry for the ranty piece - but code doesn't write itself. It is great to have a contribution - so long as you don't pin it all on someone else ;).
Pin what? When I developed the Zend PDF image parsers for example, I didn't write any tests, I did functional testing to the best I could.... and we went from there. Those classes exist in the framework today in basically the same format. That contribution process was very different from today, but it worked great. I'd hate to think what it would take to get a class as complicated as Zend_Pdf_Resource_Image_Tiff committed today....

Which one? Nobody said there would be one front controller.
For 99.999% of uses theres only one url, and only a need for one front controller.
My guess, is that it will be accessible from your bootstrap, which is registered to the front controller, which is registered to...I'm lost now.
I think you just made my point.

Trace what under the hood? Request->Route->Dispatch->Controller->Action <- stick plugins in between. It's not rocket science.
Add into that Zend_Application->Zend_Config->Get Bootstrap Name Setting->do whatever *secret sauce*->all before you get to the mvc dispatch process above. Now, from the code source I looked at before, its going to require creating some sort of methodinvokers, event delegates and hooking into a series of events. Tracing back from output to figure out where something is happening truly is a science these days -- most of the time I end up pecking around in the leaves, instead of tracing from the trunk. It gets even more complicated when you start talking partials, helpers( think actionstack ), and the myriad of other ways to inject into the request cycle.
If you doubled the complexity of the implementation today, it would still quack like the same duck it was yesterday.
We agree here. Today is too complicated... Tomorrow will be too complicated... I was hoping with 2.0 that we would figure out where the redundancies are and nix em --> i'd start at the actionstack, but thats just me. Now we're talking FSM's, and DI systems... which is cool in a compsci kinda way, but fantastically complicated out of the box.

Is it a SDK, a black box, or are we helping people make applications they understand? Whats the implication of blind use of the framework?
Right now you can still conceptually grasp MVC and use it, without ever reading the source code. In fact, right now MVC is a pretty complex beast in ZF. It would take a serious effort to complicate it further :).
Theres a reason we write books on this stuff instead of user docs.....

>Can a skilled PHP developer contribute a change to the framework easily
>without being involved in the ZFW core politics, contribution processes,
>proposal processes, test writing, doc writing, etc.

ZF may be one of the few non-political projects around. I've had some fun of course butting heads in the past, but the last two years have been politics free. Everything else is answered "no". Who else is going to miraculously write someone else's tests/docs/proposals? Not me :P.
"No" is a policy, and its not a very good one.

$0.02

Kevin
Reply | Threaded
Open this post in threaded view
|

Re: Zend Framework 2.0 Roadmap

Kevin McArthur-2
That's a massively misleading statement.

I don't have much more to say on this subject, as I think I've made my vision clear. But don't underestimate the power of engaged component leaders to maintain code quality without formal process. This current process is of but one way to do things, it hasn't always been this way, and it doesn't have to be in the future. It can be re-evaluated, especially in the 2.0 context -- and it's certainly not massively misleading to say 1.0 was achieved [or that it was a success] without the current level of process involved.

Kevin

Pádraic Brady wrote:
>I doubt this greatly, ZF to 1.0 was a huge success and had none of this stuff. A decent vetting by interested coders was all it took to keep the quality up. Most of that
>code still comprises the code base today, and it still runs fine. The docs were enough to get interested developers over the initial hurdles and the rest came through other
>sources like blogs, irc, books and sample code. I'm not saying we go back to totally untested code or anything like that, I guess I just see tests like icing, not an
>ingredient. If there's tests, great, if not, put it on the todo and move on. Instead we've got tests that are at times even counter-productive as you describe.

That's a massively misleading statement. I was around pre-1.0 too. The number of components and lines-of-code were a tiny fraction of what currently exists, and oddly enough, even at that there were tests and docs. ZF 0.x without those would never have been a success. Counter-productive tests are a problem - unfortunately overview has been lacking in the past otherwise they'd have been noticed a lot sooner. Not to drag this into a present context - as far as I know Matthew does review new test suites as part of the review process.

>I'd argue that some of those components are bad in part because of the requirement.

No, they are bad in spite of the requirement. Tests, docs or nothing at all - bad code is bad code.

>That assumes that a large amount of this work isn't optional -- when it is. Those useless tests are there because someone said 'must have tests', many, possibly most, of
>them are totally unneeded except to up the code coverage report statistics. A minority of the ZFW tests do any useful testing, and for those, I'm glad there's tests... and I
>believe those tests would still be there if they weren't required to be.

I agree the code coverage is sometimes horribly artificial (personally I believe a coverage of 60% is acceptable in a lot of cases - I do add stupid little tests to get to 85% like testing getters (ye gods) or worse). It's always a complaint when I run code coverage on a shiny new class and it pops a 55% coverage ;). I know the tests are sufficient but a rule is a rule since, as many tests prove, you really can't trust all developers. Even I make silly typos at times - even in dumb getters sometimes.

Nevertheless, whether the rule adds work or not - the point is that the work must get done one way or another before any contribution can be committed to trunk for the next release.

>I suspect many wont expect their contributions to be accepted -- and instead of capitulating to the requirements, will simply abandon the contribution.

Already happening to be honest. Unfortunately, I'm unwilling to vet every single contribution and patch, and so are the contributors. It's going to happen a lot.

>I think you just made my point.

Rest of quote? ;) The front controller is just another object - how do you get any other object in whatever class you need it? It's not something magical...

>I'd hate to think what it would take to get a class as complicated as Zend_Pdf_Resource_Image_Tiff committed today....

Probably the same effort - with testing. I'm a fan of TDD though so I'm totally biased in favour of a test driven approach - I've yet to find anything too complex to handle with it.

>We agree here. Today is too complicated... Tomorrow will be too complicated... I was hoping with 2.0 that we would figure out where the redundancies are and nix em >--> i'd start at the actionstack, but thats just me. Now we're talking FSM's, and DI systems... which is cool in a compsci kinda way, but fantastically complicated out of >the box.
>Is it a SDK, a black box, or are we helping people make applications they understand? Whats the implication of blind use of the framework?

Same could be said of namespaces, closures, all that other compsci ECMA stuff. DI and FSM are not complicated or weird or conceptually difficult - they are merely different. What we have at the moment is more familiar - and a mess. Unfortunately, ZF or not, MVC is always going to be more complicated as it needs more features. The C part of MVC remains the most expensive part of ZF performance wise. That won't change, but maybe the new concepts will help. They surely will NOT make it more complex. Whether it simplifies anything - open question to Matthew? ;)

>Theres a reason we write books on this stuff instead of user docs.....

Devs are horrible writers. Unrelated, but true! The manual has become a monster read.

>"No" is a policy, and its not a very good one.

Don't get me wrong - I agree it's not the best policy ever, but who's going to contribute the resources to make the policy "yes"? In reality a "no" is the only possible answer in an open source project with limited resources.

Paddy

 Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
OpenID Europe Foundation Irish Representative



From: Kevin McArthur [hidden email]
To: Pádraic Brady [hidden email]
Cc: Zend Framework Contributors [hidden email]
Sent: Fri, November 13, 2009 12:58:43 AM
Subject: Re: [zf-contributors] Zend Framework 2.0 Roadmap

Pádraic Brady wrote:

The main wall Kevin just hit is simply never going away. If it ever did, ZF wouldn't be far behind it as a untested, undocumented morass of code that (allegedly) does stuff.
I doubt this greatly, ZF to 1.0 was a huge success and had none of this stuff. A decent vetting by interested coders was all it took to keep the quality up. Most of that code still comprises the code base today, and it still runs fine. The docs were enough to get interested developers over the initial hurdles and the rest came through other sources like blogs, irc, books and sample code. I'm not saying we go back to totally untested code or anything like that, I guess I just see tests like icing, not an ingredient. If there's tests, great, if not, put it on the todo and move on. Instead we've got tests that are at times even counter-productive as you describe.

We need all the "contribution overhead". It is absolutely essential. There are components in the ZF which, to be generous, are pretty bad in terms of testing, documentation and flexibility already - and that's with the requirement! I have worse descriptions. Catch me on IRC during a bug hunt and I'll share some ;).

I'd argue that some of those components are bad in part because of the requirement.

The fact is, if you cannot handle the additional work that underpins, supports and ensures ease of maintenance for a component - then you are begging for a developer to start swearing over IRC. I had the joy of dealing with such a component a few weeks back. It took me hours to figure out a bug. Why? Because the unit tests DID NOT TEST the functionality of the component. I could have deleted every single test with no ill effect - they were all busy with XML parsing or something (performed by a completely different component with its own perfectly functional unit tests).
That sounds about right.

But worse than all this, is the assumption that lowering the contribution overhead is a positive thing. It's not - it merely shifts that work onto someone else.
That assumes that a large amount of this work isn't optional -- when it is. Those useless tests are there because someone said 'must have tests', many, possibly most, of them are totally unneeded except to up the code coverage report statistics. A minority of the ZFW tests do any useful testing, and for those, I'm glad there's tests... and I believe those tests would still be there if they weren't required to be.
Someone else with precious little time and a chargeout rate to justify work with. And surprise - they won't like that in the slightest. Sometimes you get lucky - I spent about 10 hours of otherwise chargeable time in September's bug hunt (which I enjoyed a lot by the way) along with several evenings but generally everyday work will always lean towards ignoring contributions where no supporting "contribution overhead" has also been committed. Such contributions/patches/whatever can be horrible to work on. No tests, poor explanations, lack of communication, differing assumptions - ugh. If it's not worth contributing in full, don't expect someone else to do it - they probably won't.
I suspect many wont expect their contributions to be accepted -- and instead of capitulating to the requirements, will simply abandon the contribution.

Sorry for the ranty piece - but code doesn't write itself. It is great to have a contribution - so long as you don't pin it all on someone else ;).
Pin what? When I developed the Zend PDF image parsers for example, I didn't write any tests, I did functional testing to the best I could.... and we went from there. Those classes exist in the framework today in basically the same format. That contribution process was very different from today, but it worked great. I'd hate to think what it would take to get a class as complicated as Zend_Pdf_Resource_Image_Tiff committed today....

Which one? Nobody said there would be one front controller.
For 99.999% of uses theres only one url, and only a need for one front controller.
My guess, is that it will be accessible from your bootstrap, which is registered to the front controller, which is registered to...I'm lost now.
I think you just made my point.

Trace what under the hood? Request->Route->Dispatch->Controller->Action <- stick plugins in between. It's not rocket science.
Add into that Zend_Application->Zend_Config->Get Bootstrap Name Setting->do whatever *secret sauce*->all before you get to the mvc dispatch process above. Now, from the code source I looked at before, its going to require creating some sort of methodinvokers, event delegates and hooking into a series of events. Tracing back from output to figure out where something is happening truly is a science these days -- most of the time I end up pecking around in the leaves, instead of tracing from the trunk. It gets even more complicated when you start talking partials, helpers( think actionstack ), and the myriad of other ways to inject into the request cycle.
If you doubled the complexity of the implementation today, it would still quack like the same duck it was yesterday.
We agree here. Today is too complicated... Tomorrow will be too complicated... I was hoping with 2.0 that we would figure out where the redundancies are and nix em --> i'd start at the actionstack, but thats just me. Now we're talking FSM's, and DI systems... which is cool in a compsci kinda way, but fantastically complicated out of the box.

Is it a SDK, a black box, or are we helping people make applications they understand? Whats the implication of blind use of the framework?
Right now you can still conceptually grasp MVC and use it, without ever reading the source code. In fact, right now MVC is a pretty complex beast in ZF. It would take a serious effort to complicate it further :).
Theres a reason we write books on this stuff instead of user docs.....

>Can a skilled PHP developer contribute a change to the framework easily
>without being involved in the ZFW core politics, contribution processes,
>proposal processes, test writing, doc writing, etc.

ZF may be one of the few non-political projects around. I've had some fun of course butting heads in the past, but the last two years have been politics free. Everything else is answered "no". Who else is going to miraculously write someone else's tests/docs/proposals? Not me :P.
"No" is a policy, and its not a very good one.

$0.02

Kevin

12