menu widget add method arguments

menu widget add method arguments


I wanted to start a new thread on this since the last one got a little
buried.
The add method in the menu widget is currently implemented like this:
add: function(markup, location){...
'Location' accepts a path string for an exact location in the menu
system, like this: '2/3/1' and it always inserts the markup to that
exact location. This is nice for a couple reasons:
• it's concise
• no need to define the type of insert, it's always a direct
insertion.
It falls short for a few reasons though too :
• it requires knowlege of an absolute path location for insertion,
which is unlikely in a dynamic menu system
• it doesn't look like jQuery
• it isn't a good format for sharing across the other methods, such as
browse and choose, because those need to speak to actual menu items
instead of theoretical insertion points.
We think that a better way to handle this would be to add a third
argument for insertType, so the function would look like this:
add: function(markup, location, insertType){...
In this variation, 'location' would default to the parent menu, and
accept a jQuery selector to a particular menu item, like this: '>
ul.myList' (maybe the '>' is always assumed, and the selector argument
acts as a .find() within the menu parent).
The 'insertType' argument would default to 'append', with possible
values of 'after', 'before', and 'replace'.
While this does mean an additional argument, it is much better suited
to realistic applications, where the path to a particular menu item is
rarely fixed.
If we are restricted to using absolute paths, it's likely that a
developer would have to find an element through a selector first and
figure out its path before passing that into the location argument.
Using a selector syntax means 'location' will accept the same syntax
for other methods too, such as browse and choose, which is nice for
consistency.
We may be misunderstanding some portion of your path system's
capabilities, and if so, we'd love to hear how it would accommodate
these scenarios mentioned above.
Do others agree/disagree with this change?
Thanks
Scott