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. > * Sometimes you need to move nodes around I would say unfortunately. > * You must render inside already visible areas (which dramatically > reduces the performance) very slow > * qooxdoo's intention is not to generate interfaces defined in HTML. keep it there... > > 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. > > 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? > 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. > > 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. > > 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. > > 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... > > > > 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
