12-20-2003, 04:10 AM
I need to turn what was pure-HTML configuration (a <ul> menu nested in a <li> navbar item) into JS-generated configuration (something which represents the same structure but in a global JS file).
My initial attempt was to compile the <ul> as a string:
udm.menuCode['about'] = ''
+ '<li><a href="/products/">Products</a></li>'
+ '<li><a href="/services/">Services</a></li>'
And then at runtime, write it into an <li> 'hook':
//look for menu defintion arrays
for(i in udm.menuCode)
//find a main list item with the same ID as array index
//if it exists
//write HTML into node hook
But I don't like it because:
1 - it's a hack, and it only works in the HTML DOM; and
2 - that kind of serialisation is difficult for less experienced coders, I think - a set of addItem() addMenu() and addLink() functions would be better, but also much more code and more tedious to implement.
So I'm just fishing for inspiration basically. Any ideas?
12-20-2003, 05:20 AM
What is udm? If it's an id, use document.getElementById()
for loops take the form of for(i=integer;i<integer;i++) (or i+=integer). Unless this is VBscript or something.
And when using typeof(), the thing to be tested goes in the parenthesis.
12-20-2003, 05:28 AM
udm is an object; and the code is fine - typeof is an operator, not a method.
Thanks though, but that's not the question. The question is more conceptual - I'm looking for a better overall approach rather than the nitty gritty.
12-20-2003, 01:19 PM
Maybe it is early morning and my coffeemaker is still brewing.... but I do not get what you are trying to do, bcake. Can you explain how this is going to be used?
12-20-2003, 01:55 PM
I've got a list-based menu system, but the early feedback I'm getting, as well my own intuition, tells me that for some people it's not gonna be acceptible for the entire <ul> to be visible to legacy browsers, with all its nested levels.
There's also an accessibility case for saying a navigation bar should only show the main items unless the method for dynamically hiding/showing their subitems is available - it's more effort to tab through, and not so at-a-glance easy to comprehend. With a very complex list structure it can be quite intimidating, particularly if it's right at the top.
It's debatable, but either way, I want the menu API to give you the choice. So menus can be static, or they can be script-generated.
What I have to do then, is find a relatively-painless way of converting a script designed to transform a pure HTML structure, into something that can work from JS config.
With me? Hopefully now my first example will make sense - I've turned the nested lists into serialised HTML which I'm writing into the navbar <li>s at load time.
You can see what a hack it is, but I'm thinking ... to create all the menus properly in the DOM ... it would be a lot more code, and take longer to process ... too long to do it at loadtime, so it would have to be on-demand ... but it can't be on demand because the script is fundamentally not structured that way - it's all done with event bubbling and node relationships - the whole tree has to exist at initialisation.
What I have now is not that bad, but it's not that good either. Like I say .. I'm fishing for inspiration :) I can live with the innerHTML hack - because people who want XML DOM support can use the static config, and anyway there isn't much choice that I can see. But that method of storing the menu data is way too fiddly.
So basically, what's a good way of programatically creating lists, in the least code, from the simplest config structure?
12-20-2003, 03:54 PM
For legacy browsers and those with JS disabled you do not want the comlete list of menu items to be displayed (what happens when CSS is disabled, I assume you script relies on it?). So the simplest way I can think of would be:
document.write('<ul><li>Item 1.1</li><li>Item 1.2</li></ul>');
12-20-2003, 05:11 PM
Yeah unfortunately that would break the keyboard navigation - the relationship of one link to the next must be parentNode.nextSibling.firstChild, which it wouldn't be if there was a <script/> in the way.
In any case that's no easier to implement than what I already have.
Maybe what I already have is the best approach after all :rolleyes: :cool:
As to what happens when CSS is disabled .. well .. if CSS and JS are both unavailable, fine, but if JS is on and CSS is off ... well it's royally screwed :eek: But who would do that?