[Zope3-dev] Re: Ajax in Zope 3

[Jean-Marc Orliaguet]

Tarek Ziadé wrote:

>Florent Guillaume wrote:
>
>  
>
>>Tarek Ziadé wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>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
>>>choose the right Javascript toolkit for this.
>>>
>>>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
>>>and javascript things.
>>>
>>>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
>>(http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework)
>>
>>
>>I'm sure lots could be improved like improving python->javascript
>>translation, allowing for explicit javascript when really needed,
>>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
>js via an ast engine. it makes the Python code looks like pseudo-javascript.
>
>see in this example:
>http://svn.subway.python-hosting.com/crackajax/trunk/itunes.py
>
>the update_list() is using things like "document.getElementById()" and
>the 'document' variable is not existing at all in python side, if i get
>it right.
>
>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)
>
>Tarek
>
>  
>


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 
javascript temporary objects)
* 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 
namespace)
  - using zope interfaces (works best with z3 components, adapters, 
utilities - useless in javascript)
  - 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.

/JM