Currently creating the entire UI via DOM api, after talking to rs, I think it should all be done via document.loadOverlay()

(This is for the Console UI work.)

Actually, now that I read the documentation, this seems to be a non-starter: "Loading an overlay with the same URI twice is not currently supported, although it may work sometimes. There's a comment in nsXULDocument::LoadOverlay to that effect." https://developer.mozilla.org/en/DOM/document.loadOverlay Not only that, but the overlay would need to know the id of the dom node it is overlaying beforehand. The idea of the notificationbox i that is dynamically generated is the parent node of each HeadsUpDisplay. I think I will just concentrate on making a sane API for the dynamic DOM-API-created UI

(In reply to comment #2) this: > ...the overlay would need to know the id of the dom node it is > overlaying beforehand. The idea of the notificationbox i that is dynamically > generated is the parent node of each HeadsUpDisplay. should say: ...the overlay would need to know the id of the dom node it is overlaying beforehand. The id of the notificationbox is dynamically generated - which is the parent node of each HeadsUpDisplay. (i need coffee)

bummer

I suppose in the long run, all of this UI should be converted to XBL. I am currently using html:div elements for all of the logging nodes, which have the magical method .scrollIntoView(), which makes the console and JS Workspace very "consoley" without trying to hard. How would this be impacted by a move to XBL?

sicking would likely know whether this would work via xbl

Changing title from: "Convert UI creation from JS to document.loadOverlay " to: Create sane API and/or approach to console UI construction

Current approach is here: http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/file/6b9ff3dc7cd0/toolkit/components/console/hudservice/HeadsUpDisplay.jsm#l287 I am slowly breaking this up into more methods to isolate the widgets.

Keep in mind that the original question you approached me with was regarding creating commandsets via JS. I really don't know what the *right* or *best* solution for this is. I personally prefer having UI in XUL or XBL vs. creating everything dynamically via JS as I noted but others may not have this preference.

Perhaps someone could have a peek at how Songbird loads new UI using their "Feathers" feature. I seem to remember that they had to jump through a lot of hoops to have the ability to load and unload UI dynamically but it seems to work.

I think I have Rob Strong's preference for declarative commandsets and UI as well. Dynamically-created features are going to be a lot harder to tease out of the accompanying code. Resultant code should also be more understandable if it's well-separated. Philip: Interesting suggestion, but probably completely different from anything we're doing in the browser already. Do you have some convenient links to source handy before we go exploring?

> I think I have Rob Strong's preference for declarative commandsets and UI as > well. Dynamically-created features are going to be a lot harder to tease out of > the accompanying code. Resultant code should also be more understandable if > it's well-separated. Me three. Not to mention making it easier to review. > Philip: Interesting suggestion, but probably completely different from anything > we're doing in the browser already. Do you have some convenient links to source > handy before we go exploring? Sorry, nothing except the Songbird blog posts that showed up on planet.mozilla.org earlier on in the Songbird development timeline. Perhaps you can ping Mook (Mark Yen) on IRC. He's a back end guy but could probably put you in touch with the relevant Feathers person.

We can come up a plan in the next rev of the console or re-open this bug at that time.