Starting the 3.0 branch

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Marco Pivetta

On 3 June 2013 19:02, Matthew Weier O'Phinney <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 10:22 AM, Marco Pivetta <[hidden email]> wrote:
> As discussed on IRC, I also suggest dropping service manager canonicalized
> names (basically the normalization process happening in the service manager
> names). Will add it to the list, since it's basically causing problems in:
>
>  * circular dependency tracking
>  * abstract factories
>  * performance

Can you detail your claims for the first two points, please? This is
the first I've heard of them, and I'd like to know what the issues
are... (I'm aware of the performance issues already, though you
improved those greatly for either 2.1 or 2.2, IIRC.)

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


Yes, sorry.

To be more clear, normalizing (canonicalizing) service names is a lossy (not reversible) conversion: whenever we hop through aliases and canonicalized service names we lose 1 step to get back and understand what was requested by the client.
The technical problem behind this is that abstract factories cannot have the actual service name when an alias is requested, so there's some loss of flexibility.
Same goes for dependency tracking, which chokes in understanding how each service was requested (because of the lossy conversion).

There's little to no advantage in converting service names like `Foo\\Bar` and `foo_bar` in `foobar`: we introduced this logic to avoid breakages in service names (such as changing a service name from `config` to `Config`).

I don't think we need that anymore: service names are stable and won't change for core services now, and we can throw exceptions that are "smart" and tell us the nearest matching service name instead (such as "You requested service '%s' - did you mean '%s' instead?").

The only real advantage is for helper plugins, where a user may want to call `$this->layout()` or `$this->Layout()`, but even there, it's just a matter of using `strtolower` instead for those abstract plugin managers that provide such kind of functionality.

Makes sense?
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Sascha-Oliver Prolic
agree


2013/6/3 Marco Pivetta <[hidden email]>

On 3 June 2013 19:02, Matthew Weier O'Phinney <[hidden email]> wrote:
On Mon, Jun 3, 2013 at 10:22 AM, Marco Pivetta <[hidden email]> wrote:
> As discussed on IRC, I also suggest dropping service manager canonicalized
> names (basically the normalization process happening in the service manager
> names). Will add it to the list, since it's basically causing problems in:
>
>  * circular dependency tracking
>  * abstract factories
>  * performance

Can you detail your claims for the first two points, please? This is
the first I've heard of them, and I'd like to know what the issues
are... (I'm aware of the performance issues already, though you
improved those greatly for either 2.1 or 2.2, IIRC.)

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


Yes, sorry.

To be more clear, normalizing (canonicalizing) service names is a lossy (not reversible) conversion: whenever we hop through aliases and canonicalized service names we lose 1 step to get back and understand what was requested by the client.
The technical problem behind this is that abstract factories cannot have the actual service name when an alias is requested, so there's some loss of flexibility.
Same goes for dependency tracking, which chokes in understanding how each service was requested (because of the lossy conversion).

There's little to no advantage in converting service names like `Foo\\Bar` and `foo_bar` in `foobar`: we introduced this logic to avoid breakages in service names (such as changing a service name from `config` to `Config`).

I don't think we need that anymore: service names are stable and won't change for core services now, and we can throw exceptions that are "smart" and tell us the nearest matching service name instead (such as "You requested service '%s' - did you mean '%s' instead?").

The only real advantage is for helper plugins, where a user may want to call `$this->layout()` or `$this->Layout()`, but even there, it's just a matter of using `strtolower` instead for those abstract plugin managers that provide such kind of functionality.

Makes sense?



--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Marco Pivetta
Just came up with another weird idea: what if we ship supported vagrant boxes with ZF3? :)
Wouldn't that be totally awesome?
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Mike Willbanks

Just came up with another weird idea: what if we ship supported vagrant boxes with ZF3? :)
Wouldn't that be totally awesome?

I'm not certain that I would find that awesome.  It is especially easy to find a vagrant box with zend server on it already and boot that up.  Then have the framework available but I don't think that is very useful and would take more time to support and answer questions.  It does not take much to create a base box with it but then there will be people that say... what about freebsd, what about centos, what about fedora, what about ubuntu, what about [insert other distro here].  

Does not sound like something fun to do.
 

Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Ralf Eggert
In reply to this post by Ralf Eggert
Hi,

today I noticed that my suggestion to the ZF3 branch got the most dislikes.

http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6c41fa&v=4

I accept that and have no problem at all with it. But I noticed in the
last weeks that a lot of ZF1 developers feel lost and left alone when it
comes to migration from ZF1 to ZF2. The migration support is currently
at least improvable.

Here is my answer to this issue:

> But I am just afraid of this situation: when ZF3 comes out,
> people start to migrate their ZF2 application and all their
> modules. If they cannot get them to run within a couple of
> minutes with the help of a proper and complete migration guide,
> a lot of them might be pissed of. We already lost a lot of ZF1
> users because they feel left alone when it comes to ZF1 -> ZF2
> migration. We should not make the same mistake again.

So, if I need to rephrase it:

Migration from ZF2 to ZF3 should be as easy as changing a diaper.

Thanks,

Ralf
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Wesley Overdijk
Right, so in theory it's simple, but you're bound to get shit on your hands.

As to a serious response, I do agree. It should come in degrees. "What has changed". zf1 > zf2 is difficult because the answer to that question would be "everything, except for the components that were refactored, but not altered in API.". The biggest problem there is that we basically changed all of the big components.

Reading this thread, I'd say that the changes between zf2 and zf3 aren't that spectacular. So a simple guide is a very good idea.

On 7 jun. 2013, at 15:08, Ralf Eggert <[hidden email]> wrote:

> Hi,
>
> today I noticed that my suggestion to the ZF3 branch got the most dislikes.
>
> http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6c41fa&v=4
>
> I accept that and have no problem at all with it. But I noticed in the
> last weeks that a lot of ZF1 developers feel lost and left alone when it
> comes to migration from ZF1 to ZF2. The migration support is currently
> at least improvable.
>
> Here is my answer to this issue:
>
>> But I am just afraid of this situation: when ZF3 comes out,
>> people start to migrate their ZF2 application and all their
>> modules. If they cannot get them to run within a couple of
>> minutes with the help of a proper and complete migration guide,
>> a lot of them might be pissed of. We already lost a lot of ZF1
>> users because they feel left alone when it comes to ZF1 -> ZF2
>> migration. We should not make the same mistake again.
>
> So, if I need to rephrase it:
>
> Migration from ZF2 to ZF3 should be as easy as changing a diaper.
>
> Thanks,
>
> Ralf

Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

zburnham
I'm as guilty of this as the next guy, but can we maybe have a bit of a conversation about documentation?  The docs for ZF2 are, frankly, pretty terrible.  I probably spent as much time browsing through the source as consulting the reference guide / API docs (which are a whole different flavor of terrible themselves.)  One page for InputFilter?  Really?  

Now while I have no real experience managing a project like this, I would think there would be SOMETHING we could do to require documentation with all contributed code that would not drive people away from contributing.  I know I owe InputFilter some docs myself, but I knew that had I submitted a pull request that didn't include unit tests Matthew would have thrown it back at me.  Would that work for docs?


On Fri, Jun 7, 2013 at 9:23 AM, Wesley Overdijk <[hidden email]> wrote:
Right, so in theory it's simple, but you're bound to get shit on your hands.

As to a serious response, I do agree. It should come in degrees. "What has changed". zf1 > zf2 is difficult because the answer to that question would be "everything, except for the components that were refactored, but not altered in API.". The biggest problem there is that we basically changed all of the big components.

Reading this thread, I'd say that the changes between zf2 and zf3 aren't that spectacular. So a simple guide is a very good idea.

On 7 jun. 2013, at 15:08, Ralf Eggert <[hidden email]> wrote:

> Hi,
>
> today I noticed that my suggestion to the ZF3 branch got the most dislikes.
>
> http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6c41fa&v=4
>
> I accept that and have no problem at all with it. But I noticed in the
> last weeks that a lot of ZF1 developers feel lost and left alone when it
> comes to migration from ZF1 to ZF2. The migration support is currently
> at least improvable.
>
> Here is my answer to this issue:
>
>> But I am just afraid of this situation: when ZF3 comes out,
>> people start to migrate their ZF2 application and all their
>> modules. If they cannot get them to run within a couple of
>> minutes with the help of a proper and complete migration guide,
>> a lot of them might be pissed of. We already lost a lot of ZF1
>> users because they feel left alone when it comes to ZF1 -> ZF2
>> migration. We should not make the same mistake again.
>
> So, if I need to rephrase it:
>
> Migration from ZF2 to ZF3 should be as easy as changing a diaper.
>
> Thanks,
>
> Ralf


Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

automatix
In reply to this post by EvanDotPro
Hello!

There are some places in ZF2, where method checks are used instead of interfaces. E.g. the for configs in the Module class. It would be great, if the ZF3 would use interfaces in such cases: 1. It's a clean object oriented way. 2. It makes the application/framework more transparent and understandable (especially for the framework newbies).



Am 30.05.2013 15:21, schrieb Evan Coury:
Hi everyone!

(Sorry, I meant to send this earlier, but had some email issues.)

I'd like to begin the process of getting our 3.0 branch started.

Besides the obvious of making use of 5.4 features such as traits, I think we should come up with some sort of list of goals / ideas for ZF 3.0, to start getting an idea of what we want to work towards. I'll also be starting and maintaining a 3.0 branch in the near future so that we'll have somewhere to begin merging pull requests that can't fit into a 2.x release.

To get things started:

- PHP 5.4 (minimum), utilizing features such as traits internally in the framework.
- While we have the freedom to break BC for 3.0, we need to keep it much less dramatic as what we saw from ZF1 -> ZF2 -- we should keep track of BC breaks as we introduce them into a 3.0 branch and make sure each one is well-justified.
- Remove all deprecated methods and classes that are in 2.x for the purpose of backwards compatibility.
- ???

Once we have some good ideas floating around, I'll compile them into a wiki page and we'll have something clear to start with.

Please do not bring up ZF2 support lifetime or which PHP version ZF3 should require in this thread -- if you want to have those discussions, feel free to start another thread.

--
Evan Coury, ZCE

Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Pavel Kačer
In reply to this post by Marco Pivetta
If I may add my opinion into discussion regarding documentation. I would
suggest to follow more the model of JavaDoc. Most of the code
description would be with the API doc. That would make it easier for
both Zend developers and app developers.

I really found the reference useful so I do not propose to drop it. But
when I am developing I need to look into the API anyway and then it
would help much to have most of the information there. Some methods are
very poorly documented in the API and not mentioned in the reference at
all.

I guess there is not enough manpower to keep both up-to-date so I think
focusing more at the API doc would make more sense. By the way a lot of
text for the reference doc might be used from the API, too.

Cheers,
--
Pavel Kačer

Join us and use free software.
http://www.fsf.org/
I am FSF member decimal number 10000 (0x2710).
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Spabby

What your saying is that in a room full of ZF1 users the adoption rate of ZF2 was very poor.

On 7 Jun 2013 20:04, "Pavel Kačer" <[hidden email]> wrote:
If I may add my opinion into discussion regarding documentation. I would
suggest to follow more the model of JavaDoc. Most of the code
description would be with the API doc. That would make it easier for
both Zend developers and app developers.

I really found the reference useful so I do not propose to drop it. But
when I am developing I need to look into the API anyway and then it
would help much to have most of the information there. Some methods are
very poorly documented in the API and not mentioned in the reference at
all.

I guess there is not enough manpower to keep both up-to-date so I think
focusing more at the API doc would make more sense. By the way a lot of
text for the reference doc might be used from the API, too.

Cheers,
--
Pavel Kačer

Join us and use free software.
http://www.fsf.org/
I am FSF member decimal number 10000 (0x2710).
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Mike Willbanks
It's actually been poor overall.  If you were to poll the ZF users many of them have not gone to ZF 2 or moved on to other frameworks.  ZF 2 is far more difficult and takes a long longer for people to become proficient at it (noticed from my own training of people).  There is certainly a harder learning curve than ZF 1.  I've had conversations with several people in passing on the adoption of ZF 2 and there has not been much excitement about it still.

I think we do need to create a balance between ease of use and also extendability.  


On Fri, Jun 7, 2013 at 11:06 AM, Gary Hockin <[hidden email]> wrote:

What your saying is that in a room full of ZF1 users the adoption rate of ZF2 was very poor.

On 7 Jun 2013 20:04, "Pavel Kačer" <[hidden email]> wrote:
If I may add my opinion into discussion regarding documentation. I would
suggest to follow more the model of JavaDoc. Most of the code
description would be with the API doc. That would make it easier for
both Zend developers and app developers.

I really found the reference useful so I do not propose to drop it. But
when I am developing I need to look into the API anyway and then it
would help much to have most of the information there. Some methods are
very poorly documented in the API and not mentioned in the reference at
all.

I guess there is not enough manpower to keep both up-to-date so I think
focusing more at the API doc would make more sense. By the way a lot of
text for the reference doc might be used from the API, too.

Cheers,
--
Pavel Kačer

Join us and use free software.
http://www.fsf.org/
I am FSF member decimal number 10000 (0x2710).

Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Tomáš Fejfar
On Fri, Jun 7, 2013 at 8:16 PM, Mike Willbanks <[hidden email]> wrote:
There is certainly a harder learning curve than ZF 1.  
And ZF1's worst problem was long learning curve - it took really long to get it right. 
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Magnus Berglund

I feel this is related to the documentation issue. Some of the structures that ZF2 is based on are extremely useful when you know how to actually use them, but getting there from not knowing much about those concepts is a pain in my opinion. 

---
Best regards
Magnus Berglund


7 jun 2013 kl. 20:22 skrev Tomáš Fejfar <[hidden email]>:

On Fri, Jun 7, 2013 at 8:16 PM, Mike Willbanks <[hidden email]> wrote:
There is certainly a harder learning curve than ZF 1.  
And ZF1's worst problem was long learning curve - it took really long to get it right. 

Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Stewart Lord
Initially I found ZF2 off-putting despite having had some (very minor)
involvement in its development. It took a few days to warm to it. Now I
am a big fan because the architecture and quality of the code are
exceptional! I have encountered far fewer bugs in ZF2 than in ZF1.
Everyone who had a hand in it should be very proud.

I would point to poor baseline performance and boilerplate code as key
reasons for lower adoption. Perhaps the biggest reason is the vacuum
that was created between ZF1/ZF2 that allowed other frameworks to gain
marketshare. The most important lesson to take away from that transition
is don't try to boil the ocean!

Regards,
Stew


On 2013-06-07 12:17 PM, Magnus Berglund wrote:

>
> I feel this is related to the documentation issue. Some of the
> structures that ZF2 is based on are extremely useful when you know how
> to actually use them, but getting there from not knowing much about
> those concepts is a pain in my opinion.
>
> ---
> Best regards
> Magnus Berglund
>
>
> 7 jun 2013 kl. 20:22 skrev Tomáš Fejfar <[hidden email]
> <mailto:[hidden email]>>:
>
>> On Fri, Jun 7, 2013 at 8:16 PM, Mike Willbanks <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     There is certainly a harder learning curve than ZF 1.
>>
>> And ZF1's worst problem was long learning curve - it took really long
>> to get it right.


Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Xerkus
In reply to this post by automatix
On 08.06.2013 1:36, Ilya Khanataev wrote:
Hello!

There are some places in ZF2, where method checks are used instead of interfaces. E.g. the for configs in the Module class. It would be great, if the ZF3 would use interfaces in such cases: 1. It's a clean object oriented way. 2. It makes the application/framework more transparent and understandable (especially for the framework newbies).

Interfaces in Module class was made optional to allow to reuse modules outside of zf2 while not introducing dependency on it (if those interfaces is the only part required zf2).

Other than that i agree.

-- 
Aleksey Khudyakov
Web developer, ZCE
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Yurii Korotia
hello people
 
I just signed for mail and got your 3.0 discussion.
here’s my point of view of guy who set up skeleton/album app for 2.x, ran some debugger sessions and tried to import your code into diagrams. I’ve got like 6-8 tries to get into this, still not see any sense to continue.
it looks expensive, class name Null, traits (it’s horrible, right?), very huge hierarchy of classes even for simple filters. events are good way to keep things in tact of course, but where’s the list of available events and config.. maybe it should be xml/xsd with some parser? it feels like zf2 is for chosen ones. I cannot find real (quality) example even on modules website. people write as they understand.. and it looks
like lights during new year.
 
please, consider official example for zf3 which will utilize functionality you want developers to utilize. you have events? show me! you have cool ways to make new services fast? show me! I’m a noob.
 
so far it’s more like framework for album with expensive db mapper (which will be replaced anyway with like doctrine, etc). extending json encoder.. come on.
 
p.s.
my bad for writing here, forum looks dead.
 
__
Yurii
 
 
Sent: Saturday, June 8, 2013 10:13 PM
Subject: Re: [zf-contributors] Starting the 3.0 branch
 
On 08.06.2013 1:36, Ilya Khanataev wrote:
Hello!

There are some places in ZF2, where method checks are used instead of interfaces. E.g. the for configs in the Module class. It would be great, if the ZF3 would use interfaces in such cases: 1. It's a clean object oriented way. 2. It makes the application/framework more transparent and understandable (especially for the framework newbies).

Interfaces in Module class was made optional to allow to reuse modules outside of zf2 while not introducing dependency on it (if those interfaces is the only part required zf2).

Other than that i agree.

-- 
Aleksey Khudyakov
Web developer, ZCE
Reply | Threaded
Open this post in threaded view
|

AW: [zf-contributors] Starting the 3.0 branch

Marc Tempelmeier

Full ack!

 

It´s what bugs me the most, the documentation. Most times I give up and ask the developer in irc directly.

But they can´t handle all of us…

The second problem I have is composer. Until recently composer had a big problem with proxies:

https://github.com/composer/composer/issues/1946

Which stopped me from using it most of my time. But a few of modules out there are only useable with it,

yes I mean you RWOverdijk. J

 

Marc

 

 

Von: Yurii Korotia [mailto:[hidden email]]
Gesendet: Sonntag, 9. Juni 2013 17:21
An: [hidden email]
Betreff: Re: [zf-contributors] Starting the 3.0 branch

 

hello people

 

I just signed for mail and got your 3.0 discussion.

here’s my point of view of guy who set up skeleton/album app for 2.x, ran some debugger sessions and tried to import your code into diagrams. I’ve got like 6-8 tries to get into this, still not see any sense to continue.

it looks expensive, class name Null, traits (it’s horrible, right?), very huge hierarchy of classes even for simple filters. events are good way to keep things in tact of course, but where’s the list of available events and config.. maybe it should be xml/xsd with some parser? it feels like zf2 is for chosen ones. I cannot find real (quality) example even on modules website. people write as they understand.. and it looks

like lights during new year.

 

please, consider official example for zf3 which will utilize functionality you want developers to utilize. you have events? show me! you have cool ways to make new services fast? show me! I’m a noob.

 

so far it’s more like framework for album with expensive db mapper (which will be replaced anyway with like doctrine, etc). extending json encoder.. come on.

 

p.s.

my bad for writing here, forum looks dead.

 

__

Yurii

 

 

Sent: Saturday, June 8, 2013 10:13 PM

Subject: Re: [zf-contributors] Starting the 3.0 branch

 

On 08.06.2013 1:36, Ilya Khanataev wrote:

Hello!

There are some places in ZF2, where method checks are used instead of interfaces. E.g. the for configs in the Module class. It would be great, if the ZF3 would use interfaces in such cases: 1. It's a clean object oriented way. 2. It makes the application/framework more transparent and understandable (especially for the framework newbies).

Interfaces in Module class was made optional to allow to reuse modules outside of zf2 while not introducing dependency on it (if those interfaces is the only part required zf2).

Other than that i agree.


-- 
Aleksey Khudyakov
Web developer, ZCE
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

EvanDotPro
In reply to this post by Yurii Korotia
On Sun, Jun 9, 2013 at 8:21 AM, Yurii Korotia <[hidden email]> wrote:
please, consider official example for zf3 which will utilize functionality you want developers to utilize. you have events? show me! you have cool ways to make new services fast? show me! I’m a noob.

There are absolutely countless fantastic examples out there of well-architectured modules modules that take advantage of all of this functionality. There's even full-stack open source applications out there that you can reference. I'm unsure how you could possibly be having trouble finding quality examples for ZF2.

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

Re: Starting the 3.0 branch

EvanDotPro
In reply to this post by automatix
On Fri, Jun 7, 2013 at 7:36 AM, Ilya Khanataev <[hidden email]> wrote:
Hello!

There are some places in ZF2, where method checks are used instead of interfaces. E.g. the for configs in the Module class. It would be great, if the ZF3 would use interfaces in such cases: 1. It's a clean object oriented way. 2. It makes the application/framework more transparent and understandable (especially for the framework newbies).


 In addition to what Aleksey said, the other side of this is that for every person that complains about the duck typing, there are just as many that complain when you take it away and force interfaces only -- that's one of those very inconsequential things that some people seem to get oddly opinionated about, and not matter what decision you make, someone is going to be bothered by it.

I'm not commenting one way or the other on the issue, as I don't think it's important enough or even worth the time to debate, but just keep that in mind with little things like this.

--
Evan Coury

Reply | Threaded
Open this post in threaded view
|

AW: [zf-contributors] Starting the 3.0 branch

Marc Tempelmeier
In reply to this post by EvanDotPro

Hi,

 

the problem right there I see every day in my company. They simply don´t want to search good examples.

The second argument against that is, how do you know if that are good examples in the first place?

You can spot that, beginners don´t!

In many companies they people don´t have time to educate themselfs much. They have to have a good

Documentation with _good_ examples.

I don´t get why everyone here is refering to other places or their blogs for that. They is _no reson_ to

Prefer multiple blogs etc. over examples on the official site.

 

Just my multiple cents on this

 

Greetings

 

Marc

 

Von: Evan Coury [mailto:[hidden email]]
Gesendet: Mittwoch, 19. Juni 2013 05:14
An: Yurii Korotia
Cc: [hidden email]
Betreff: Re: [zf-contributors] Starting the 3.0 branch

 

On Sun, Jun 9, 2013 at 8:21 AM, Yurii Korotia <[hidden email]> wrote:

please, consider official example for zf3 which will utilize functionality you want developers to utilize. you have events? show me! you have cool ways to make new services fast? show me! I’m a noob.

 

There are absolutely countless fantastic examples out there of well-architectured modules modules that take advantage of all of this functionality. There's even full-stack open source applications out there that you can reference. I'm unsure how you could possibly be having trouble finding quality examples for ZF2.

 

--

Evan Coury

12345