Kent Olsson wrote: > > Hej! > >> Jose Henrique Steckelberg F. schrieb: >> > I've been following qooxdoo devel for some time, and would like to >> > propose something which is somewhat related to the PHP framework >> > discussion thread: could dojo's way of "templating" applications be >> > implemented in qooxdoo? >> >> There are several issues with this type: >> >> * To reuse existing dom-nodes is only possible for really simple widgets >> (even in dojo) > > it is a restriction in several ways. >
I can't see how XUL would allow this but inlined HTML wouldn't. Kent Olsson wrote: > >> * Sometimes you need to move nodes around > > I would say unfortunately. > Again, I can't see how XUL would allow this but inlined HTML wouldn't. Kent Olsson wrote: > > >> * You must render inside already visible areas (which dramatically >> reduces the performance) > > very slow > > Dojo seems to be doing fine in this regard, but I am not so sure of that. Their problem right now is bloat, btw... ;) Kent Olsson wrote: > > >> * qooxdoo's intention is not to generate interfaces defined in HTML. > > keep it there... > > Neither did I suggest that, my suggestion is to use HTML as a templating file, in the same way XUL would be used. It would just use existing HTML tags (DIVs, SPANs, etc.) to define the lay-out and widget structure of an application page. The original HTML could be completelly dropped after parsing, if required. Kent Olsson wrote: > > >> > QxBuilder should be able to read the page's >> > html at onLoad and parse its contents, changing it dinamically for >> > QxWidgets by means of innerHtml/outerHtml, but only those specifically >> > tagged, and leave the rest untouched, so the page's html could turn >> > into its own template and content at the same time. >> >> I think QxBuilder is nice, but unusable for large applications. I think >> a server-side transformation would be the better choice here. > > Not unusable, but performance-wise difficult to manage. Performance is > always relative to each user's previous experience. > > Doing it server side would mean there would have to be a server-side integration system for each language/technology out there (one for PHP, one for Java, one for Ruby, etc.). There is a benefit in creating something server-side agnostic. Kent Olsson wrote: > > >> > Something like: >> > >> > <html> >> > <form> >> > <input qxWidget="qxInput"/> >> > </form> >> > some text here >> > <div qxWidget="qxTree" icon="..." title="..."> >> > <div qxWidget="qxTreeFolder" title="..." > >> > <div qxWidget="qxTreeFile" title="..." > >> > </div> >> > </div> >> > </div> >> > some text there >> > </html> >> >> Looks something like dojo ;) >> >> > >> > QxBuilder could read and modify the page above, so each tag with >> > qxWidget attribute >> > would be switched for it's corresponding qxWidget, with it's attributes >> > set from >> > the html source too. >> > >> > Benefits: >> > 1) ability to use standard html editors for app design >> >> Not really. The layout features have couldn't be modeled with simple >> HTML. qooxdoo has many more features than realizable with "simple" HTML. >> As qooxdoo is more a application than a page design toolkit, I think the >> best choice is to model some XML dialect like XUL or XAML. > > XUL is well established, XAML too but I guess XUL will have a more > narrow applicability because of design issues. Will it ever be fully > accepted? That might be one of the reasons for the growth of > JavaScript!!! JavaScript is not at all the optimal language, but what > else is there which is widely accepted? > > Again, I think it is possible to "extend" HTML to include qx's attributes, the same way XUL would include tags and attributes to describe some app lay-outs. We don't have to be restricted to XHTML's DTD. Current browsers and most page editors ignore these additional attributes. Kent Olsson wrote: > > >> Even if you use HTML you are the most of the time restricted to the >> attributes you have defined somewhere in your additional DTD. It's just >> not as intuitive to write qxWidget="qxTree" >> qxSetup="width:200,height:400", ... or where ever you want to define the >> additional properties for your widgets. > > What is more intuitive than something you have learned before? > Sebastian, we have different backgrounds, way of thinking and the way we > do things. This is the never ending problem with all standards. When the > model becomes so flexible that the definitions can be overcome the > interest and usage of the technology will increase pretty fast. > > Either that or we'll have to learn XUL's tags, properties and attributes anyway. HTML is something everyone knows today. Kent Olsson wrote: > > >> > 2) no separate download of XML/JSON/JS/other app UI templates >> >> In my opinion this could also be an advantage, because the browser is >> able to cache this stuff. > > I agree. > > me too Kent Olsson wrote: > > > >> > 3) easier integration with current web server frameworks, which already >> > work with html, >> > (like JSF or wicket) they would not need to generate qx's proprietary >> > xml format or >> > something else, just plain html tags with qx's attributes mixed in. >> >> I think real application frameworks which could provide application >> parts for single requests are the better choice. Especially for large >> applications with many dialogs and sub-windows. > > Modularity is the best choice. Scale every small unit down to its > smallest and absolutely most necessary parts, then many problems will be > ruled out. > > Wicket framework is capable of that today, it can make partial updates to existing pages. It is all based on components, so it can redraw just parts of your pages as needed using AJAX. It is done today with dojo, but I am evaluating how qooxdoo could be used for that too. Kent Olsson wrote: > > >> > 4) no need to learn yet another XML dialect >> >> Also what's about updates? How do you like to open a window which other >> content for example. How to realize dynamic interfaces? How to define >> initially invisible parts? > > Initial invisible parts created fill up space and take time to transfer > and process. It also increases the overhead. Even better to be dynamic > as you mention... > > If I get it right, Wicket framework can do that, as I explained above. Kent Olsson wrote: > > >> > >> > I imagine it wouldn't be so hard to adapt qxBuilder to read page's >> html. >> > Plus it could demand >> > pages to be XHTML compliant in order to make parsing >> > simpler/easier/faster too. >> >> Just my 2 cents. > > XHTML is maybe the most accepted and the most compatible model so far. > Parsing is not always so simple, but probably from a performance > perspective a useful way to go. The way to go! > > Kent > >> Sebastian >> >> > What do you think? >> > -- >> > ------------------------------ >> > Zenrique Steckelberg >> >> >> >> ------------------------------------------------------- >> 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 >> _______________________________________________ >> Qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-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 > _______________________________________________ > Qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > Add my 0.02$ there too! ;) Regards, Zenrique Steckelberg -- View this message in context: http://www.nabble.com/QxBuilder-%2B-Server-side-integration-ideas-t1433940.html#a3887660 Sent from the qooxdoo-devel forum at Nabble.com. ------------------------------------------------------- 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 _______________________________________________ Qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
