Further on the idea of support that Rob brings up, what are the plans
for supporting Dojo related questions on the mailing list? Will there
be a ZF/Dojo list and/or will there be a policy on this general one as
to how far a question is ZF/Dojo related or just Dojo related and
therefore to be directed to their support? I can just imagine this
list getting a lot of traffic that is off-topic otherwise.
Nick
On 22/05/2008, at 7:05 PM, Rob Allen wrote:
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...
