PDA

View Full Version : Fully dynamic generation of the BorderLayout example #6



gcsolaroli
8 Nov 2006, 9:42 AM
Hi,

I have started studying YUI-ext in order to use it on an application I am developing. I need to generate all the UI from Javascript (starting from an empty body element).

I have taken the example #6 (http://www.jackslocum.com/blog/examples/layout6.htm), and I have tried to make everything dynamic: I have remove all the body's content, and I have tried to fix the Javascript accordingly.

I have found the 'config.autoCreate' option for the YAHOO.ext.ContentPanel constructor, and so I can generate most of the panels empty (I have not found how to populate the panels content yet, but I will work on this soon).

My current problem is that I don't know how to create a YAHOO.ext.grid.PropsGrid (that is a specializazion of a YAHOO.ext.grid.EditorGrid) without using having a DOM element to pass as 'container' parameter.

Any suggesion on how to achieve this result?

Thanks for your attention.

Giulio Cesare Solaroli

jack.slocum
8 Nov 2006, 5:09 PM
Use DomHelper to generate it. Make sure you set a width/height and overflow:hidden on the container.


var propsEl = YAHOO.ext.DomHelper.append(document.body, {
tag: 'div', style: "width:200px;height:200px;overflow:hidden;", id: 'props-grid'
});

Compugasm
8 Nov 2006, 7:06 PM
I need to generate all the UI from Javascript (starting from an empty body element).

Wow, I'd rather drill woodscrews under my toenails, and dump salt in the holes. Good luck with that.

jarrod
8 Nov 2006, 10:13 PM
Actually, with the domhelper, it's not that painful - except for creating certain form elements, e.g. options in a select droplist.

Animal
9 Nov 2006, 12:11 AM
No indeed. With DomHelper it's very easy. I'd rather set a lot of things up dynamically than generate bulky markup.

My js code to create complex widgets will be, for the most part cached - page weight will be lighter. No point in generating (in JSPS) and downloading boilerplate containers as raw HTML. Just generate the dynamic content and essential page layout information in your JSP, and allow the javascript widgets to set up dynamic elements.

gcsolaroli
9 Nov 2006, 12:23 AM
>> I need to generate all the UI from Javascript (starting from an empty body element).
>
> Wow, I'd rather drill woodscrews under my toenails, and dump salt in the holes.
> Good luck with that.

:-)

Thanks!

I have already done a prototype using only MochiKit as support library, but MochiKit is short (by design) on widgets. It has only a DOM module that is very convenient to use, but it is just a little bit more sofisticated (but also slower) them the YUI-ext DomHelper.

Now I am trying to find the best arrangement to handle UI elements between elegance (MochiKit rules here) and features (YUI + YUI-ext win hands down here).

The single thing that I miss most from the YUI approach to widget, is the possibility to build full widgets not bound to any DOM element, in way similar to what DomHelper templates handle raw chunk of HTML.

I would like to create instance of widgets, configure them, keeping them around, and tell them where they should "draw" (aka render their html code) only when I need it. And later being able to "detach" a widget instance from the DOM, keeping it around fully setted as a "simple" object.

I am investigating if it is easier to hack the current YUI widget architecture, or wrap it with altogether with some brand new classes that whould delegate most of the feature to the original widget.

Thanks for your attention.

Best regards,

Giulio Cesare Solaroli

jack.slocum
9 Nov 2006, 1:39 AM
I have already done a prototype using only MochiKit as support library, but MochiKit is short (by design) on widgets. It has only a DOM module that is very convenient to use, but it is just a little bit more sofisticated (but also slower) them the YUI-ext DomHelper.

I would have to disagree on the "more sophisticated". Mochikits (MK) DOM functionality is a bunch of functions that create DOM elements using DOM. You can't even reuse a construction (like a DomHelper config object can be use over and over). It doesn't support templating either. It only supports one insertion method (DOM) while DomHelper can use DOM or innerHTML or html fragments.

Also the performance difference isn't slight, it's over 500%. That's a big different.


Now I am trying to find the best arrangement to handle UI elements between elegance (MochiKit rules here) and features (YUI + YUI-ext win hands down here).

MK is all a bunch of global functions. yui-ext is object oriented reusable components that can be customized by simply overriding methods. That's why there are more features. That's also why, if you think about it, yui is truly the more elegant approach.


The single thing that I miss most from the YUI approach to widget, is the possibility to build full widgets not bound to any DOM element, in way similar to what DomHelper templates handle raw chunk of HTML.

I would like to create instance of widgets, configure them, keeping them around, and tell them where they should "draw" (aka render their html code) only when I need it. And later being able to "detach" a widget instance from the DOM, keeping it around fully setted as a "simple" object.

I am confused by this? You could easily create another element and swap it out in the DOM. And creating a new object in JS is very lightweight, the overhead of a widget is it's rendering. So if you are just going to rerender anyway, then it will net better performance to swap out the node + make a new widget than to make a new node + detach and reattach everything. It would also be much less prone to bugs.

Take some time to full around with the library. Try extending some components. I think if you do I think you will find that there are many thing you can customize and do that wouldn't be possible had I used global functions like MK.

gcsolaroli
9 Nov 2006, 2:20 AM
I would have to disagree on the "more sophisticated". Mochikits (MK) DOM functionality is a bunch of functions that create DOM elements using DOM.

MochiKit use a functional programming style, where YUI uses an object-oriented programming style; thus code is arranged quite differently. I have a strong background on OOP, but I have learned to love functional programming too, thanks to JavaScript and MochiKit.

The "more sophisticated" judgment is very personal, so you have all the right to disagree. :-)


It doesn't support templating either.

That's is very true, but it is also true that with MochiKit.DOM you can avoid dealing with raw HTML altogether; you "simply" arrange DOM "objects" (there are no real DOM object in the MochiKit library, but you end up using the function in a way that looks very similar to how you would end up using objects) and let them populate the DOM.

But I don't want to be a MochiKit zealot at all. YUI-ext achievement are impressive, and I am studying on how to get the most out them.


I am confused by this? You could easily create another element and swap it out in the DOM. And creating a new object in JS is very lightweight, the overhead of a widget is it's rendering. So if you are just going to rerender anyway, then it will net better performance to swap out the node + make a new widget than to make a new node + detach and reattach everything. It would also be much less prone to bugs.

I have some issues understanding your suggestion, too. So I will keep reading it until I get what you mean, as my current understanding of most aspects of YUI (and probably also of JavaScript widget programming in general) is still quite weak.

What I would like to have (from an OOP point of view) is a further abstraction of the widget objects (in pure OOP terms I should say classes) from the DOM nodes. I would like to create, arrange, configure all my widgets without touching the DOM. When I am done with the setup, "simply" tell the widget where to "draw".

I will try to find a simple example I have arranged some time ago as a proof of concept of my idea, hoping that some real code could help me describing better what I am looking for.

Thanks for your patience.

gcsolaroli
9 Nov 2006, 5:57 AM
I have uploaded a small example of what I am looking for:
<http://www.clipperz.com/files/example/index.html>

This example consist of a very basic tabpanel; in the index.html file there are three different ways this element can be created.

# The first instance is created "enhancing" some static html:


<dl class="uiTabPanel">
<dt>tab 1</dt>
<dd><span>panel 1</span></dd>

<dt class="selected">tab 2</dt>
<dd><span>panel 2</span></dd>

<dt>tab 3</dt>
<dd>panel 3</dd>
</dl>


Here I have tried to choose a "template" format (used to setup the tabPanel object that is going to be created) that makes sense also when no JavaScript is executed


# The second instance is created using a very classic OO paradigm:


tabPanel = new UI.TabPanel();
tabPanel.addPanelWithLabel("dynamic panel 1", "dynamic tab 1");
tabPanel.addPanelWithLabel("dynamic panel 2", "dynamic tab 2");
tabPanel.addPanelWithLabel("dynamic panel 3", "dynamic tab 3");
tabPanel.selectTabAtIndex(0);


Once the tabPanel variable is fully configured, you can eventually "append" it to the DOM:


MochiKit.DOM.enhancedSwapDOM(divElement, tabPanel);



# The third example create the instance of the tabPanel, and inner panels, using a notation very similar to what MochiKit uses in its DOM module:


tabPanel = UI.DOM.TabPanel(null,
UI.DOM.Tab({label: "DOM tab 1"}, MochiKit.DOM.SPAN(null, "DOM panel 1")),
UI.DOM.Tab({label: "DOM tab 2"}, MochiKit.DOM.SPAN(null, "DOM panel 2")),
UI.DOM.Tab({label: "DOM tab 3"}, "DOM panel 3")
);


Note that the second parameter of the UI.DOM.Tab function, just like most of the similar functions, can be anything handled by the MochiKit "DOM Coercion Rules" (<http://www.mochikit.com/doc/html/MochiKit/DOM.html#dom-coercion-rules>): a string, a DOM node, a function, an object that implements the toDOM method, ...


However the tabPanel is instantiated, at the end it will render itself with an HTML that looks like this:


<div class="uiTabPanel">
<ul class="uiTabPanel_tabs">
<li class="uiTabPanel_selectedTab"><a ...>tab_1</a>
<li class="uiTabPanel_notSelectedTab"><a ...>tab_2</a>
<li class="uiTabPanel_notSelectedTab"><a ...>tab_3</a>
<li class="uiTabPanel_notSelectedTab"><a ...>tab_4</a>
[/list]

<ul class="uiTabPanel_panels">
<li class="uiTabPanel_selectedPanel">
... panel 1 ...

<li class="uiTabPanel_notSelectedPanel">
... panel 2 ...

<li class="uiTabPanel_notSelectedPanel">
... panel 3 ...

<li class="uiTabPanel_notSelectedPanel">
... panel 4 ...

[/list]
</div>


There is nothing special in this arrangement other that it was very convenient to write a CSS to achieve a very base tabPanel layout without fuzzing out.

Does this make any sense?

gcsolaroli
9 Nov 2006, 6:02 AM
I forgot to mention that these ideas have alreading been discussed on the UI4Web Google Group:
<http://groups-beta.google.com/group/ui4w>; and in particular in the following thread:
<http://groups-beta.google.com/group/ui4w/browse_thread/thread/2cd2b2a0b140345f>