How to properly implement custom widgets: onRender vs constructor?

[fother]

I can not say with any certainty what you said but in my testing machine had more success using the method onRender () than the objects created in the constructor method. It takes more the first time to create the objects, the more the second time that is accessed much more quickly, my application is necessarily great, and I have not had any problems with rendering so far and no use of high memory or CPU.

[LINEMAN78]

It all depends on what you are doing with your custom Widget. It is expected that you will have quicker access the second time, but at what cost? If this is a singleton object that will always be used by your application and never be removed from the panel, it really doesn't matter what method you use. But in some of my cases where I am constantly creating and tossing objects it can be a real issue. I actually managed to kill my entire OS by leaving my app running all weekend when I had forgotten to remove panels from a container and was just hiding them. This is just a simple example of an extreme case of not paying attention to garbage collection. If you treat everything as a singleton (or do everything onRender without proper GC) you are defeating some of the purpose of a thin app and might as well be creating a thick app.

[fother]

I returned to test the application and realized that the objects that I created the method onRender() are the DOM, and when I needed them to access rendering was quicker. you noticed that too?

[googelybear]

Hi guys,

thanks a lot for your ideas! This problem seems not as trivial as I thought first and there is apparently no single answer to this
From what I've read so far I will stick with my current scheme:

• create the static widget structure in the ctor: For most of my custom, composite components thiw will happen only once, when the init event is received by the view
• populate the widgets with data in custom methods (remove, change, add data) and afterwards call layout on the parent to refresh the widget (or loader.load() if it's a pager). This methods will be called multiple times

Any objections?

[darrellmeyer]

I try to offer some feedback on the issues raised.

What I am currently confused is whether I should populate these widgets in the constructor (gwt style) or in the onRender() method.

First, you need to understand that components are rendered lazily. What this means is that the DOM element(s) for a component are not created until needed. Because of this, constructing a component does not cause the DOM element to be created and therefore can be done without paying the price for element creation.

So I would say in most cases, it is perfectly acceptable to create sub components in your custom components constructor. This rule assumes that the child components are not executing any unneeded or expensive code when constructed.

There are two good reasons to defer construction to the onRender method of the custom component. One, for performance reasons, you want construction to occur only when the component is rendered. This only applies to slow performing component construction times as discussed in the previous paragraph. Two, you need to access the custom components DOM structure that is not available at construction time. For example, you may be inserting the child components into some custom markup.

I'm currently creating the static structure inside the constructor and add the actual data displayed in the widget later on in a custom method, followed by a layout() call to ensure it's updated correctly.

That sounds good.

I sometimes using the Constructor when i don't need to get the elements from the DOM, when i need to get the DOM i build inside onRender.

That is correct.

The layout() doesn't workout very well for me inside the constructor, don't know why.

layout() calls in the constructor will not work because the component has not been rendered and therefore nothing for the layout to do.

If you are trying to use some sort of external library that relies on accessing the DOM in order to render something (i.e. swfobject.js) you will need to use the onLoad() method.

Just to be clear, onRender, afterRender get called once when the component is rendered. onAttach on onLoad get called each time the component is attached. Unrelated, we just added a SwfObject and FlashComponent to the the trunk for 2.0.

I have found that if this is not the case, it tends to work best if you stick with the constructor method(less memory leaks).

I am not sure what you are saying here. There is no correlation between construction, onRender and memory leaks.

When you are using the onRender method, remember you will have to make sure you have error checking to see if the object has been drawn before calling any functions on it. If the object has not been rendered, you can simply change the parameters that the object will be rendered to. However, if the object has been rendered, you will need to perform changes to the object in the DOM, or change the perameters and redraw.

The purpose of onRender is for the component to create it's DOM structure. I am not sure what you mean in your comments.

but if I use the constructor who destroy my object?

You do not have to destroy components or widgets which is one of the benefits of the GWT event and listener model supported by attaching and detaching widgets.

This is risky if you do not know what you are doing and if this is not necessary you will end up making your entire app run on onRender calls, which will eliminate all pre-loading and be fairly cpu intensive because the object will either not be implemented correctly and you will get memory leaks, or it will re-create the objects instead of re-rendering them, which can cause more http requests or just more load time following user action.

I dont understand these comments and the references to memory leaks, cpu, and re-creating objects. As mentioned before, constuction vs onRender has nothing to do with memory leaks, re-creating objects, http requests, etc.

[sdc]

May I add that you can also defer construction of the widget in the beforeRender method instead of onRender. So you don't have to handle the Element stuff (calling setElement).

[gelgey]

I typically do the following:

class FooView extends LayoutContainer {

  // Fields that I want to reference throught the code.
  private final TextField<String> fooField = createFooField();
  private final TextField<String> barField = createBarField();

  // Assemble the UI.
  @Override protected void onRender(Element parent, int index) {
    super.onRender(parent, index);
    this.setLayout(...);
    this.setSize(...);
    this.setHeading(...):
    this.add(fooField);
    this.add(barField);
    this.add(createBazField()); // field created for display only
  }

  private TextField<String> createFooField() { ... etc ... }

}

I like to put all the UI assembling code (setting layouts, sizes, headings, adding components to containers, etc) in (or called from) a render method. If a component is purely for display purposes, it is created there.

Any components that also need to be referenced outside of the UI assembly logic I put into the constructor.

Although sometimes I see strange things such as text fields overlapping each other in a dialog, which is fixed when I move the dialog or tab between fields.

I guess this points to problem with putting all the UI assembly into onRender(). It may be that the parent container can't figure out the required sizes and offsets because the child components have not been added by the time onRender() is called. Or maybe layout() needs to be called somewhere.

Where is the best place to call setLayout() and setSize(), for example?

[sdc]

use beforeRender() instead of onRender

[gelgey]

use beforeRender() instead of onRender

I've tried that a few times. Sometimes it fixes a rendering problem for one class but when used in another class I get rendering problems (e.g. fields on top of each other) that I don't get when using onRender(). It's possible this has something to do with the parent container, however.

Still experimenting with finding the right approach ...

[modelka]

any updates on this topic? probably someone wrote tutorial about custom components creation or something?