[Framework-Team] Re: AJAX decision must be made THIS WEEK
Martin Aspeli wrote: Hi guys, We've meandered, wondered, hued and hawwwed for long enough. I am +1 Azax/KSS -0 Bling I recommend merging the Azax bundle *provided*: - PloneAzax and ATAzax go away, being merged into Plone and AT or componentised further - templates can be merged back - we should not ship Plone with any templates that override other templates in the skin layers out of the box! Also, these should work without a hard dependency on the server-side components (as I believe would be the case anyway) - server-side views could potentially move to plone.app.azax and archetypes.azax or similar packages. There is a fair amount of code here, probably too much to put into Archetypes core and CMFPlone. It seems wrong to stuff them in the Products/ folder though, since this is essentially new code. - MochiKit is not included in page download by default (it's used only for logging panel) - Demo products like azaxdemo and KSSMultiSelectWidget go away - A migration step is set up to enable this properly without needing to install a separate products I would prefer - If we used azax in lib/python rather than Products/ (I believe it supports this) - Some of the pre-Zope 2.10 BBB/compat code was branched off and cleaned out To summarise my recommendation: Bling: + Simple approach + Re-uses Prototype closesly + Follows proven Ruby-on-Rails model - Bundle does not work, has never worked - Almost no checkins since review process began - Seems to have only a single maintainer - I find it hard to follow the Prototype way so closely in a Plone context, and expect that a certain class of integrators would too - Inline JavaScript and JS-specific TAL replace/attribute statements increases risk of making pages that are too JS-dependent Azax + Focus on development model + Conceptually clean (for the most part) + Two active core maintainers + One sprint completed + 3-5 other developers with enthusiasm + Theoretical possibility of migrating to e.g. mochikit in the future due to abstraction of JS functions from server code and KSS stylesheets. - More code to maintain in the future - More JS to maintain in the future - Possibly harder to extend with new functionality (if that needs to be made generic) - Possibly harder to integrate with certain Prototype-dependent libraries In the end, there is one overwhelming reason for prefering Azax/KSS - Bling is a one-man job which no-one has taken overall responsibility for driving forward or adopting into the community. Azax/KSS by contrast has dedicated and passionate developers and the support of many other developers and integrators. If I felt Bling was a vastly superior technical solution, I may have tried to impose that will on the wider community, but I don't feel that way, and the technical opinions of many people that I respect seems to agree with me. That is not to say we're not adopting some risk, and I sincerely hope that the Azax/KSS team would continue to be as responsible and supportive as they have been in providing the necessary polish and bug fixes to make this shine in Plone - there is still much work to be done (starting from either bundle). Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] AJAX decision must be made THIS WEEK
Benjamin Saller wrote: It hardly seems like an issue at this point. I think the idea is clear. Ignoring what you may think of the technology I've been on other projects and won't be putting significant time into Bling. There was a time when this was possible but that time is past. I think that is what we were all implying. The problem is not at all what you alone can and cannot achieve, the problem is that you seem to be in the position to need to achieve it alone, which places too much risk on us all. If I ever expressed frustration it was with this, not with you or the quality of your outputs, but I hope and think you know that. :) I think its smart of the community to go with what they feel is well supported and the efforts of the Azax/KSS team are more than commendable. Personally I believe that the goals of both projects, to protect the developer from Javascript were based on the climate of a year or two ago and that with the documents, books, frameworks and libraries rich web UI's are much more accessible now than they were when I started the project. Bling was (and I think KSS is) designed around the idea of making additive changes to existing UIs without requiring the developer to learn JS. In todays world its unlikely that existing UIs are compelling enough to warrant minor additive improvements without considering the entire toolset available to the modern interface designer. Leading applications are simply getting more sophisticated and require the same thought as designing traditional GUI applications. For doing additive changes I think Azax might be too much framework but this is not my call. For doing completely new UIs Bling would be too little. I think there are some very valid points here, but at the same time we need to move forward - we can't stay still and assess and wonder forever. I fully expect that our toolset will evolve, possibly quite rapidly over the next few years. At the same time, some things that are acceptable to Google Maps (you need a modern, JS-enabled browser for anything all to work) also face more conservative concerns in Plone. Perhaps we'll come full circle, or perhaps some of the Ajax tools will end up being baked more closely into Zope itself and therefore change in nature. Perhaps we'll rewrite Plone in Rails, I dunno. That's why I prefer to defer to the democracy and observe what the community seems to have adopted. Maybe for reasons of politics and marketing as well as technical assessment, but in real terms I think those factors are equally valid and important. Wouldn't it be nice if we'd all just agreed? :) Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: AJAX decision must be made THIS WEEK
I spent some time looking at azax/kss while waiting for valgrind runs to finish. I have not looked at the azax implementation in detail, but I do have a few comments on it below. I was pleasantly surprised by how simple atazax and livesearch were. Since creating and using plugins is what most developers will be exposed to that is an important quality. Previously Martin Aspeli wrote: I recommend merging the Azax bundle *provided*: - PloneAzax and ATAzax go away, being merged into Plone and AT or componentised further - templates can be merged back - we should not ship Plone with any templates that override other templates in the skin layers out of the box! Also, these should work without a hard dependency on the server-side components (as I believe would be the case anyway) The livesearch product can also be merged into CMFPlone. - server-side views could potentially move to plone.app.azax and archetypes.azax or similar packages. There is a fair amount of code here, probably too much to put into Archetypes core and CMFPlone. It seems wrong to stuff them in the Products/ folder though, since this is essentially new code. plone.archetypes? Has anyone decided on a namespace for AT? This seems to be related to something I noticed: ploneazax duplicates a lot of interface and zcml that Plone 3.0 (and 2.5) already have. This seems to stay compatible with older Plone releases, but I fear that people will be tempted to use those instead of the plone interfaces and that we will be dragging that along for a long time. I would prefer - If we used azax in lib/python rather than Products/ (I believe it supports this) it seems to; there already is some support for it where it fiddles around with sys.modules to be usable outside of Products. So here is my new vote: -1 on Bling +1 on Azax/KSS Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
