[TYPO3-ect] Future of different AJAX-libs?

[R. van Twisk]

Elmar Hinz wrote:
> Joerg Schoppet wrote:
>   
>> Person1: We implement a new page-tree with prototype.
>>
>> My dream ;-) would be, to have the strengths of both approaches combined:
>> The easy of use of XAJAX for php-programmers and the different effects
>> of prototype.
>>
>> Comments?
>>
>> Joerg Schoppet
>>     
>
> Hi Joerg,
>
> I think both approaches can perfectly live side by side. I have no clue
> how they could be combined. Even the author of xajax uses xajax side by
> side with prototype, like hi posted in the xajax forum. The functional
> range of xajax is limited to every days tasks. But:
>
> * Programmers that don't want to fiddle around with javaScript will use
> xajax.
>   
I don't fully agree, when I look at the examples of xajax, for example 
the multiply
I still need to make onclick handers : 
http://www.xajaxproject.org/examples/multiply/multiply
So I do need to know about javascript to get values from components.

I think that prototype with there $ function solves that much better.

The a mouth of complex JS is also limited with prototype...

> * Programmers that want quality by prevention of errors in javaScript,
> will use xajax, because javascript is fully autogenerated.
>   
When it comes to the ajax part, this goes for prototype aswell.
> * Programmers that wish a slim library can use xajax.
>   
Agreed... But you still need to do something with the data you receive
this needs a good library like prototype.
> * Programmers that want a high production rate will use xajax.
>   
Totally not agreed... if you know prototype and it's functions you can
make your behaviors just as fast as with any other library.

No offence, but it sounds like you have a strong personal + for using
xajax without really looking into others needs.

In MY case we need for example a method the build DOM elements,
I don't think that xajax can help me with that, yet prototope and scripto...
can do that for me.


> So I am sure xajax will still stay for a while, until it will be
> replaced by somthing, that provides the same advantages, but is still
> ahead. Prototype doesn't provide this advantages. As you say it is not a
> direct competitor. Rather an addition to solve more complicated tasks.
>   
yup full ack!!
> I have some doubts that fat prototype is the best possible decision for
> the heavy used functions of the BE. I would take a very slim library
> with a slim data format, rather not XML, maybe JSON.
>   
it's fat because it contains many many functions to do any daily task. 
Any slim library
cannot handle what prototype can do. There are quite some good things in 
prototype.
TYPO3 is a 'fat' library, but it doesn't mean it's bad, it just contains 
a lot of goodies.
> ,
this is teh same for prototype.
> However, those who do the work, also make the decisions, for good or
> bad. That's a central rule in open source.
>
>   

kind regards,
Ries
>   

> Regards
>
> Elmar
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> TYPO3-team-extension-coordination mailing list
> TYPO3-team-extension-coordination at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-team-extension-coordination
>   


-- 
Ries van Twisk
Freelance Typo3 Developer
=== Private:
email: ries at vantwisk.nl
web:   http://www.rvantwisk.nl/freelance-typo3.html
skype: callto://r.vantwisk
=== Work:
email: ries at livetravelguides.com
web:   http://www.livetravelguides.com