-- Nick Lo <[EMAIL PROTECTED]> wrote (on Thursday, 22 May 2008, 08:39 PM +1000): > 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.
For now, fw-mvc will be the list for ZF+Dojo questions. My inclination is that if the questions become very specific to Dojo usage, we will point the user to the Dojo mailing lists and IRC channel. > 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... >> >> > -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend - The PHP Company | http://www.zend.com/
