HI batawata,

I understood your points. So, I've tried (15 min) to "rewrite" your chat using xajax, and i see the big difference with cpaint. Maybe, the best way is: to code a little layer for xajax; perhaps it can replace definitely the cpaint, but I am very confused..So, if We cant do that, we can use the both...like Fabio had said before...

Lets talk about it the next Monday, but I still need to confirm it with my boss, We have many things to delivery..


[]s
Wesley

On 3/17/06, Luis Henrique Fagundes <lhfagundes@gmail.com> wrote:
On 3/16/06, Fabio Rampazzo Mathias <fmathias@linux.ime.usp.br> wrote:
> Hi batawata,
>
> Maybe if we bring the simplicity of XAJAX implementation to cpaint and "make
> it optional" would be interestin
>
> If we have these 2 ways of doing the same thing (cpaint and xajax method) in
> the same framework is even better, cause those who wants simple things would
> use xajax method and those who wants some structured things (like your chat
> ;) would use cpaint method.
>
> I think cpaint is more powerful than xajax, but I like xajax cause is too
> much "user friendly" and tiki style than cpaint.

hi fabio

I've changed my mind. it's not worth anymore implementing that
simplicity in cpaint. it's designed to work in a lower layer, and so
we would have to build the framework, while xajax is there. I think
implementing the possibility of transfer data structures in xajax is
worth more, having two libs might make some confusion, or incentivate
developers to do simple things in cpaint, and this would break
environment by putting layout in javascript. there's no secret about
ajax libs, I have built mine, read others, extended others, we just
have to code it :-).

my idea now is to write a function similar to addScript in response
object, but that accepts php variables that will be converted to js
and passed as parameters to js functions (addScript just accepts a
string to eval).

so, current status is: I consider cpaint integration to be a succesful
project that is in time to be closed. we got there, researched,
thought about it a lot, coded some stuff, and can abandon it before
it's too late. I have a tiki-based project that xajax can't handle,
but this is already implemented with my own lib and despite future
features, I guess xajax handles everything we need now in tiki.

does anyone have other arguments in favor of cpaint?

wesley and fabio, it would be great if you can come next monday, we
have to design a way to include xajax in tiki (if we just follow xajax
manual and do like xajax_example we'll end with a mess of ajax files,
cut&pastes, etc).

cheers
batawata




>
> []s
> rampazzo
>
>
>
> On 3/16/06, Dimitri Smits <dsmits@aspects.be > wrote:
> >
> > Hi Luis,
> >
> > (gongo) typing here. Have you looked at the qooxdoo project. Some aspects
> > of it are really neat (for GUI-wise ajax clients as well as on the fly
> > data retrieval, event system and other neat features are available as
> well.
> >
> > (http://qooxdoo.sf.net)
> >
> > it is LGPL licenced. There are 2 things I dislike on it however.
> > First, it (on first look) has themes or 'look and feel', that is coded
> > in js (not in css for instance).
> > Secondly, it does require inclusion of js code in your generated page
> > (not in the data), and goes against the notion of 'unobtrusive
> javascript'.
> >
> > Nevertheless, try the demos on their pages. You'll be impressed.
> >
> > (notice: didn't look at xajax and cpaint though)
> >
> > kind regards,
> > Dimitri Smits
> > aka Gongo
> >
> > >----- Oorspronkelijk bericht -----
> > >Van: Luis Henrique Fagundes [mailto: lhfagundes@gmail.com ]
> > >Verzonden: donderdag, maart 16, 2006 04:13 AM
> > >Aan: tikiwiki-devel@lists.sourceforge.net
> > >Onderwerp: Re: [Tikiwiki-devel] Re: Ajax framework for Tiki
> > >
> > >hi everybody,
> > >
> > >I have talked to more people (tks luci and franck) and after coding a
> > >lot over cpaint, I now have a clearer vision about the difference
> > >between both frameworks.
> > >
> > >Since I have coded the part I like most about cpaint (the easyness to
> > >transfer data), I'm convinced that implementing this data transfer in
> > >xajax would not be harder than implementing the simplicity of xajax in
> > >cpaint. so, it's just a question of which approach we like most, and
> > >I'm starting to like xajax way :-).
> > >
> > >when doing ajax we can't avoid taking some layout logic that was in
> > >template to code. I first felt that xajax breaks more environment
> > >because it puts in php the manipulation of client-side data, but then
> > >I realized that with cpaint we do it even more, the difference is that
> > >this happens client-side, but in js code that is also not supposed to
> > >be handled by designer. the change in point of view happened as I
> > >realized that js is closer to php than to html.
> > >
> > >so now we have two different approaches: xajax is more like a
> > >server-push, once you call a function from client, the php will do all
> > >the job, you run everything from there. with xajax coder has never to
> > >handle javascript directly, we have wrappers to declare in js scope
> > >all exported php functions. in this approach, my suggestion would be
> > >to extend xajaxResponse class to have a method jsScriptCall that would
> > >call a js function and pass any data structure to it.
> > >
> > >the other approach, cpaint, starts from a powerful data transfer
> > >layer, but them we have to handle more code to do simpler stuff. it's
> > >focused more on data transfer than displaying html content, so forcing
> > >developers to also handle javascript. we have a more free way to code
> > >server-side, but we have to make a js other side to handle the
> > >request, while xajax you're limited to returning xajaxResponse object
> > >server-side, but don't need the extra js code. with cpaint my
> > >suggestion would be to add a lot of methods to do simple stuff over
> > >the powerful communication layer.
> > >
> > >handling data with javascript to render it client-side, as cpaint
> > >does, is much lighter for structures that will have a lot of html code
> > >repeated, but for other side with cpaint we have to build layout
> > >inside js code and go to pre-templating times, unless we have a
> > >dream-lib to parse smarty templates with js. with xajax we transfer
> > >more data, but we can make use of our templates and render it in php.
> > >xajax would make it much easier to make a system that would show
> > >exactly same code with or without ajax, without much extra code, by
> > >reloading just the $mid part of screen for example.
> > >
> > >so, any new thoughts about this?
> > >
> > >cheers
> > >batawata
> > >
> > >On 3/11/06, Luis Henrique Fagundes <lhfagundes@gmail.com> wrote:
> > >> On 3/11/06, Wesley Willians < wesleywillians@gmail.com> wrote:
> > >> > Hello, batawata!
> > >> >
> > >> > Now i understood what you said! I really dont know how to pass an
> array to
> > >> > the JS, but maybe you can you can use the function called: addscript
> on
> > >> > xajax... lets discuss it on next monday, perhaps i cant go, but we
> can talk
> > >> > via skype ok?
> > >>
> > >> ok!
> > >>
> > >> > I'll analyse your code,  but I really think which We cant have a file
> per
> > >> > function :-)
> > >>
> > >> yes, I agree with you, and I guess most people do :-). but you see
> > >> that this is technically the simplest point, we just need to decide
> > >> how to do that. I'm just trying to avoid poluting our environments
> > >> with one extra file per page.
> > >>
> > >> >
> > >> > Try to analyse the xajax documentation ( xajaxproject.org), maybe you
> have a
> > >> > good idea. I am sure, that xajax is very simple to be used and in the
> > >> > majority of the times it can works very well, however, cpaint is
> really
> > >> > powerful!
> > >>
> > >> yes, maybe we can use both, or work in implementing xajax simplicity.
> > >> another thing I don't like in xajax is that you hard code the name of
> > >> html elements in php files, imo it breaks the code/layout separation.
> > >> but if people prefer to do that way, maybe we should give them the
> > >> option.
> > >>
> > >> cheers
> > >> batawata
> > >>
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > >that extends applications into web and mobile media. Attend the live
> webcast
> > >and join the prime developer group breaking into this new coding
> territory!
> > >http://sel.as-us.falkag.net/sel?cmdlnk&kid
> 0944&bid$1720&dat 1642
> > >_______________________________________________
> > >Tikiwiki-devel mailing list
> > >Tikiwiki-devel@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > that extends applications into web and mobile media. Attend the live
> webcast
> > and join the prime developer group breaking into this new coding
> territory!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Tikiwiki-devel mailing list
> > Tikiwiki-devel@lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> >
>
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel