[Cosmo-dev] UI layout and rendering doc

[Matthew Eernisse]

Jeremy,

I've had a chance now to sit down and look at the files you sent with 
the changes to ContentBox and your resizer viewports. Comments inline 
below ...

Jeremy Epstein wrote:
> the first is integrated n to the contentbox resize routines to eliminate 
> circular rendering dpendencies-- there is a hash that tracks renders-- 
> until the hash is cleared, once an item is rendered it can't be rendered 
> again. for integration, this will require you to add a line to the 
> topmost render method or whateer invokes to clear the hash. 

This is excellent. As the hierarchy gets more complicated, the 
independence of the various UI widgets will increase the possibility of 
that kind of circular rendering problem.

A couple of questions:

1. Is there a specific reason to use a startRender that doesn't know if 
rendering occurred successfully -- or would it make more sense to use a 
completedRender method called immediately after renderSelf?

2. The check for previous rendering happens in the loop that processes 
the children of a ContentBox, so it looks like it would still be 
possible (albeit unlikely) to have a situation where a top-level UI 
widget renders over and and over.

I was imagining something that looks like this:

cosmo.ui.ContentBox.prototype.render = function (h,w,l,t) {
     if (cosmo.ui.ContentRenderWrangler.hasRendered(ch.id)) {
         return false;
     }
     if (typeof this.renderSelf == 'function') {
         this.renderSelf();
     };
     cosmo.ui.ContentRenderWrangler.completedRender(this.id);
     var ch = this.children;
     for (var i = 0; i < ch.length; i++) {
         ch[i].render(h,w,l,t);
     }
};

3. There's already a hasBeenRendered property used to indicate that the 
UI widget has rendered at least once (usually for making sure things 
like appending the DOM structure to the document only happens once). If 
we implement the ContentRenderWrangler, I think there might be some 
confusion from naming. ("What's the difference between hasRendered and 
hasBeenRendered?")

I'm not married to the name hasBeenRendered. It almost represents a 
rendering initialization phase -- although we'd probably not want to use 
'init' because a UI widget can be set up and initialized without ever 
actually being rendered. I guess we could get a little verbose and call 
it hasBeenRenderedOnce or hasBeenRenderedTheFirstTime or something. 
Thoughts?

> the second item in contentbox is another contentbox, (you could think of 
> it ias a subclass if you are so inclined)

Is there some specific reason to take the mixin approach with 
ViewportContentBox rather than simply having its prototype inherit 
directly from the ContentBox?

> that includs a wrapper for viewports. note that the viewport resize 
> parents are different then the strict DOM hierarchy as they will almost 
> always resize absolutely based on the first absolutely or relatively 
> positioned parents coordinate space. this is important-- an objects 
> logical dom parent may not be absolutely positioned, but a viewport's 
> render parent must implement the viewport render method (which requires 
> the render command to pass two arguments: width and height)

At least in the Cosmo UI code, I'm pretty sure that every element in the 
DOM hierarchy for the Cosmo layout is either absolute or relatively 
positioned -- if it's not, it's a bug.

Final thoughts -- one of the things I had in mind when I mentioned the 
idea of unifying the ContentBox model with the viewports was a way for a 
developer to create a ViewportContentBox and use the simple 
sizing/positioning methods (setWidth, setHeight, et al) to set up the 
min/max values for the content box.

I don't know if this is even possible to do given the conceptual 
differences between the two, but I can imagine some easy-to-use calls 
like this:

// 200px wide, full-window height, right-aligned
// You wouldn't want to use '100%' for height
// because it would look like you're setting CSS props
someViewportWidget.setSize(200, 'full');
someViewportWidget.setPosition('right', 'top');

// full-window width, 200px height, bottom-aligned
someViewportWidget.setSize('full', 200);
someViewportWidget.setPosition('left', 'bottom');

It would make it dead simple to set up and use resizer viewports without 
having to try to fit the different min/max params in your head. It might 
not even be all that difficult to come up with the set of rules needed 
to translate from one to the other.

I'll be looking forward to hearing your thoughts on all this.

Thanks again very much for your work. I'm really excited to see this 
kind of innovation going into the UI code.


Matthew