Hi Wil,
On 22 May 2008, at 02:26, Wil Sinclair wrote:
To be perfectly honest, Rob, if the standard library components will
be the only part of ZF that is maintained over time and major
releases, then we’ll need to start scaling back our expectations of
this project- and quick-like! Actually, I’d rather just build a
reality where the extras library will deliver a lot of components
that may be more useful, important, and possibly even more actively
developed than some in the standard library. J
This is what I'm hoping really hoping for. It will be interesting to
see what happens long term though, especially management of less well
maintained or less popular components.
I would strongly recommend you look in to building compatibility
with jQuery (and contributing it back!) if you have already made a
significant investment in this toolkit and/or you happen to prefer
it for whatever reason. The fact is, JS toolkits- like template
systems, persistence layers, etc.- are built very differently with
some working better than others for certain projects or developers.
The last thing we want to do is force a developer to use any one
technology when they feel there is a better one out there for them.
Please, Rob, investigate jQuery/ZF compatibility, help a community
effort to build support in to ZF, and then write a book about it.
In our case, it's YUI, but your point is taken. The question is
whether I want to saddle the company with the risk of extra
maintenance work of ZendX_Yui compared to no maintenance risks with
Zend_Dojo. Also, we will have to consider how much opportunity will be
lost because we aren't using the officially supported JS libraries
over the costs of migrating to Dojo.
BTW, I should take this opportunity to re-assert that extras library
components will *not* be second-class citizens in ZF. The only
effective difference is possibly in distribution (we might deliver a
lean/mean package with no extras, unit tests, locale files, etc.)
and support.
There's also the question of management.
My current impression is that as Zend Technologies is not prepared to
support ZendX components, then the company is not going to be funding
them like they pay for maintenance on the Zend Standard components. To
pick on myself as an example, if I ever stopped providing support for
Zend_Config, Zend Technologies will find someone else to do it and if
a volunteer can't be found, then one of the Zend Framework core team
employed by Zend Technologies will ensure that it is maintained. This
is the bit that my company has bought into and is why we have based
our code on Zend Framework.
I am unsure of how this will work for ZendX components. Who decides
what components go into ZendX? By definition, Zend Technologies isn't
as interested in them per se as the community may be. Who manages the
SVN rights for making changes to a given ZendX component? Will there
be an "owner" for each ZendX component who can decide which volunteers
also have SVN access? Who will decide when that should be changed? How
will disputes be resolved when a very useful improvement to ZendX_C2
depends on a change to ZendX_C1 that ZendX_C1's owner doesn't want to
do? What happens if a given component is orphaned and then ceases to
work due to a major ZF version change? Will it be removed? Who decides
that?
Maybe I'm overcomplicating it, but to me there's a lot of questions
about ZendX that arise precisely due to Zend Technologies lack of
support for its components.
We do not expect adoption of extras components to be affected by
their inclusion in the extras library vs. the standard library.
For my company, this will depend on the management of ZendX. For my
personal projects, it won't matter if they are ZendS or ZendX.
Ask yourself- if you really liked jQuery and it worked for you and
your project, and there were a jQuery component for ZF in extras
with the same quality guarantees as the standard library, and you
didn’t care that much about having full Zend support for every
component in your project, would you choose Dojo simply because it
was in the standard library? Maybe you would- fortunately it will be
there for you too. ;)
It's not so much the quality of the component, more its longevity and
ability to keep up with the officially blessed version that I'm
interested in. Shipping Dojo as an official component to the point of
including all the JS files in the distribution sends the signal that
Zend Framework provides significant value add for Dojo users over
other JS libraries (otherwise why bother shipping it?) so the number
of people who know Dojo and ZF will be much higher than those who know
Yui/JQuery/Prototype/etc and ZF.
To me, it's not significantly different than the choice of DB layer.
Sure, some people use Doctrine or Propel with ZF, but they are a tiny
proportion compared to the number who use Zend_Db. I don't see why it
won't be the same with Zend_Dojo.
I'm not saying its necessarily bad, but Zend has backed one of the
horses that does affect the race.
Regards,
Rob...
