From: Alexander M. <fo...@al...> - 2006-03-21 16:34:37
|
Hi, due to time-constraints I haven't done much lately. And sadly I wasn't even= =20 able to follow current developments, because CVS-mails from batawata(and so= me=20 others) don't arrive. They aren't even in the CVS-list-archive. I wonder ho= w=20 CIA is able to announce the commits! :O Onto AJAX: If I understood that correctly, the current 'proposal' pushes complete=20 HTML-document-parts over httprequest instead of just updating the relevant= =20 innerHTML or attributes? While it for sure is an easy to implement solution, I don't like it. It creates really unnecessary traffic, may we say bandwidth-bloat-by-design? I think, you'll create just, what you wanted to prevent: incentivating peop= le=20 to do things extremely 'simple'. I can't already sleep any more, because I= =20 see tiki-templates being ripped apart, people pushing useless stuff over aj= ax=20 just because 'it is sooo cool and everybody does ajax and now I can do it,= =20 too, and yes, sure it's perfect to push tiki.tpl over xmlhttprequest'. I think, I really have to agree with luciash, it seems, that people see AJA= X=20 as a must-have-in-there-or-we're-obsolete, a feature for end in itself! But= =20 your firefox icon not being animated, is just a necessary, not a sufficient= =20 condition for it being good. And I clearly abstain here from saying that=20 AJAX=3D=3Dgood. While it is fascinating technology, that has very serious a= nd=20 advantageous uses - anything used for the sake of itself is always dangerou= s.=20 I don't see page-reloading being eliminated completely in Tiki 1.x. And if= =20 so, then it's imho again crazy to push complete documents over=20 xmlhttprequest. With your addition of addScriptCall() there is the possibility to transfer= =20 structured-data. But I don't see many people using that. Noobs will be=20 happily using the above mentioned possibility and coders will abstain from= =20 doing much serious ajax, because they don't have the full power of designin= g=20 XML-responses like they want or need. Why did you remove cpaint already? There's still stuff depending on it! While HEAD surely is a playground for more grown-up kids, it is not meant t= o=20 be a theatre of war. There has been a lot of rampaging going on, that reall= y=20 frustrates me. greets amette Am Montag 20 M=E4rz 2006 08:45 schrieb Luis Henrique Fagundes: > hi everybody > > I'm happy to announce a new proposal :-). it's based on xajax: > > http://dev.tikiwiki.org/AjaxDev > > this one makes things very simple, one can make dinamic components > from parts of a page in 5 minutes, and disabling feature_ajax will > preserve the result completely. > > I also added the addScriptCall() function to xajaxResponse object, > that allows data transfer from php to js: > > http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1454076&grou= p_id=3D1 >39736&atid=3D744316 > > cheers > batawata > > On 3/19/06, Luis Henrique Fagundes <lhf...@gm...> wrote: > > On 3/17/06, luci aka Lukas Masek <lu...@sh...> wrote: > > > greetings Tiki devs, > > > i think it's time to make some notes from me on this whole AJAX > > > stuff... > > > > > > sorry if i will sound a bit rude here: > > > > no prob, many point of views, great topic :-) > > > > > 1. of course it's nice it is discussed here now but shouldn't this be > > > done way before all the code suddenly appeared in the HEAD ? > > > 2. if it was so, it could be discussed to put both (cpaint and xajax > > > libs) as CVS modules for the testing etc. as mose mentioned on irc > > > without polluting the current Tiki base structure in HEAD > > > > well, maybe we should have more discussion, but it's something that > > just happened. we wanted to do ajax things and started coding, then > > more people got interested and the discussion emerged. in fact, I see > > that we have many lone-coders working on different places, but few > > places with real collaboration of a group working together in same > > piece of code. this helps to cause the tiki-bloat-effect. I agree that > > code got a bit polluted with all this - and tks for caring - but this > > makes me think that we might be lacking a good playground, and I don't > > feel that a mod is already a good one, because people are not using > > and don't know much about how to use this. if I ask wesley and fabio > > to try my mod and make another proposal as a mod it would be like > > inviting him to practice some soccer and suggest a place 100 miles > > away, they would have to research about mods first, and they might not > > have proposed xajax. > > > > imo, mods are necessary, but they're not ready. in things like mods or > > ajax, that are also guidelines for developers, a good and well > > documented api is more important than a good and functional code. > > maybe we lack a good discussion about mods. I also feel that sometimes > > mods is seen more as damian's stuff than good feature for tiki, now if > > we want it to be used someone has to adopt it. > > > > > 3. imho AJAX is cool enhancement and a must for some people to have it > > > on Tiki's next feature list as "AJAX included ! (TM)" but Tiki > > > shouldn't depend or rely on it. so, ok, let's choose some AJAX lib but > > > only include it, connect it with some wrapper as simple as possible > > > with tiki, document it (if it's simple wrapper it can't be much work), > > > and update it regularly as we do with other included libs. maybe some > > > little things of current Tiki features can be optionally made enhanced > > > using that AJAX lib but, please, do not make another AJAX/Tiki fork ! > > > > ok, that's also something I realized about cpaint, it would be > > difficult not to incrust it in tiki. with xajax is much easier to make > > parts of tiki dinamic using same templates and simple $feature_ajax > > tests. we just have to modularize more the templates. > > > > > everything else (more complex features dependent on AJAX) should be > > > made as *mods* ! > > > > don't agree here, mods politics have been marginalizing features. I > > agree with damian that tiki is becoming a bloat and that we need a > > solution, but mods haven't solved this so far. > > > > > 4. talking about mods, devs should really focus on the functionality = of > > > this feature first, instead of adding more and more cool stuff to HEAD > > > directly (develop functionality to make language translations of mods > > > easily, enhance installation/upgrading/patching of mods, etc.) > > > > hehe, I was about to say some more things about mods when I finally > > got to item 4, had forgotten it :-). of course, that's true, now we > > got to the point. but we have a rithym of adding things, we can't just > > stop everything to make mods work. we can, and should, pay more > > attention to it. if we reach a good model we can refactor tiki, and > > all this added stuff won't be a problem. > > > > > that's my opinion (and i believe some other's too). just wanted to ma= ke > > > it clearly stated ( before someone else will ask me if i prefer qooxd= oo > > > over xajax ;) )... > > > > tks! please tolerate the kid's playing at HEAD for a bit, it's been > > very productive, and pull our ears if we don't clear it later ;-). > > > > and btw, qooxdoo looks cool, but I guess I didn't see the examples > > properly. it's a concept very far from tiki's. > > > > > > batawata > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > 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=3Dlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > Tikiwiki-devel mailing list > Tik...@li... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel |