Tarek Ziadé wrote:
Florent Guillaume wrote:
Tarek Ziadé wrote:
Some UI works have been done lately around and in Zope 3. I am thinking
about the work that has been done at Neckar sprint (Zope3.org website,
Viewlets, etc..), and on projects like CPSSkins for Z3 at ECM.
I am planning to work on UI things as well, and on Ajax things in
particular, both for Zope 2 and Zope 3 applications, and trying to
Before starting it up, I was thinking that it would be nice if the whole
Z3 community would be using the same toolkit, and maybe, even integrate
it into Z3 itself.
This would allow developers to start some js things today under Z2/Five
and port them. This would also probably lead into a "Z3 way" to do ajax
What people think ?
If this sounds like a good Idea, I would like to start a Z3 proposal on
this topic, and contribute on its integration in Z3.
Myself I absolutely love the approach taken by CrackAjax
improving the testability, etc.
Yes it needs inprovment indeed: the problem I had with this approach at
this time is that the python written that is meant to be translated in
see in this example:
the update_list() is using things like "document.getElementById()" and
the 'document' variable is not existing at all in python side, if i get
I was wondering in fact what was the benefit of doing it, beside having
a strong aversion of doing js coding (and that aversion can be
really improved by using toolkits like mochikit)
I haven't done it yet, but I'd like to see what patterns Ruby-on-Rails,
and other frameworks (e.g . TurboGears) are using, and why it makes such
a difference in terms of productivity.
one of the important factors that I've noticed tend to complicate the
code uselessly are:
* the lack of transparency when dealing with client-side and server-side
data structures (the need to convert data back and forth)
* the need to temporary store and pass data in an artificial way
(through URL parameters, storing temporary data in the request, inside
* representing a same thing with different names, for instance there are
in zope3 many options for naming objects:
- using one-word strings or strings without spaces (works best in
URLs, good as nicknames)
- using dotted names (less ambiguous than short strings because of the
- using zope interfaces (works best with z3 components, adapters,
- using unique ids (intids)
- using object names inside containers
- using interface identifiers ( IFoo.__identifier__ ) ...
- using interface names ( IFoo.__class__.__name__ )
once you've solved these issues, the rest is much easier.
Zope3-dev mailing list