Fabian Jakobs schrieb: > Hi Sebastian, >> No, but I would be interested in your ideas :) >> > I want to use decorators in the layer, which renders the row > backgrounds. This layer uses plain HTML and DOM manipulations for fast > rendering. The decorators currently expect an instance of > "qx.html.Element" as first parameter in the "init", "resize" and "tint" > methods and this is a problem for me. > > This is the way the widget uses the decorators right now: > > 1. create the decorator element as instance of "qx.html.Element" > 2. initialize the decorator element: decorator.init(decoratorelement) > 2.1 The init method in all qooxdoo decorators is the same and looks > like "decoratorElement.useMarkup(this.getMarkup()); > 3. after the widget's final size has been calculated be the layout > engine the decorator element is resized: > decorator.resize(decoratorElement, width, height); > 3.1 The resize method in all qooxdoo decorators first get the real DOM > element of the decorator element and only work with this DOM element > > step three is repeated after each widget resize. This is how I plan to > use decorators in the widget: > > 1. create the decorator element as instance of "qx.html.Element" > 2. initialize the decorator element: > decoratorElement.useMarkup(decorator.getMarkup()); > 3. after the widget's final size has been calculated be the layout > engine the decorator element is resized: > decorator.resize(decoratorElement.getDomElement(), width, height); > > As you see it is easy the change the decorators to only work with HTML > strings and DOM elements. The init method will be removed and the > "resize" and "tint" method will work with plain DOM elements. The > changes to qooxdoo's decorators and the widget code is minimal. The > benefit is that we are able to use decorators in areas where only HTML > and DOM operations are used.
This is not a good solution. Not to say that it is quite bad. I see your idea behind, but I think this kind of implementation is not good for qooxdoo. The issue is that when you directly modify DOM nodes is, that these changes are not scheduled with the other framework changes. This is basically a thing which we should not do. We have spend so many time to make all these changes synchronous. Another implementation would possibility would be to stay with using qx.html.Element, and wrap the DOM nodes you want to modify by such an element. Maybe using some kind of fly-weight pattern to keep memory consumption down. This definitely needs some modifications to the Element class (basically at useMarkup()). The benefits here are that you: * keep the interface as it is * keep using the style/attribute normalization provided by qx.html.Element But now a little turnaround (after inspecting some decorators ;)) * the decorators mostly already use direct DOM access (the even use qx.bom.XXX already) * the interface change would maybe mean a more general usage pattern But, to be consequent, the whole classes have to be moved somewhere else as they are not exactly "ui" specific anymore. So, finally, it seems that you have my OK ;) Cheers, Sebastian > > Best Fabian > > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
