durusmail: quixote-users: Quixote best practices?
Quixote best practices?
2003-11-07
2003-11-07
2003-11-07
2003-11-11
2003-11-11
2003-11-11
2003-11-12
2003-11-11
2003-11-12
2003-11-13
2003-11-07
Quixote best practices -> HTML menu
2003-11-07
2003-11-07
2003-11-07
Quixote best practices?
Orr, Steve
2003-11-07
I'm looking for dynamic menuing capability implemented purely in HTML.
Is there anything "out there" for me to use? Seems like there SHOULD be.

Currently my web app is dynamically generating a hierarchical tree menu
or Exporer-folder-like object implemented in javascript. But it's
behavior is not consistent amongst browsers so I want to get rid of the
javascript and do pure HTML. My tree menu object is database driven and
can have any number of folders within folders so the data is recursive.
(The database query uses Oracle's "connect by prior" syntax.) Further
more, users have a form against the menu metadata so they can customize
their own menus and add their own SQL scripts to the app, etc.

I need a way to dynamically generate a hierarchical data driven menu in
HTML. Isn't there anything like this? Please, oh PLEASE!  :-)


D. B. Dweeb



-----Original Message-----
From: Jim Dukarm [mailto:jim@deltaxresearch.com]
Sent: Friday, November 07, 2003 1:03 PM
To: quixote-users@mems-exchange.org
Subject: Re: [Quixote-users] Quixote best practices?


On Fri, Nov 07, 2003 at 08:40:09AM -0600, Skip Montanaro wrote:
>>     * Package nesting - Do people tend to nest packages or use other
objects
>>       (classes, for example) to effect nesting?  Or do you normally
keep
>>       your URL space pretty flat so nesting is not an issue?

----- and Martin Maney wrote: ---------------
> I've used classes in a couple of places, ... and classes would
> probably be a natural way to  package the functionality for use by the

> traversal layer, but that's only a thought experiment so far.
> :-)

My Quixote app is built on top of a relational database with equipment
information and a lot of different kinds of test data and analysis
results for each piece of equipment. After some initial fiddling around,
I settled on a class-based approach:

EquipmentFolder - display a list of equipment, which can be sorted
  and filtered in various ways. Create a new equipment item on demand.
EquipmentDetail - display or delete an equipment record. EquipmentForm -
edit a new or existing equipment record.

There are analogous classes for all the other major objects,
representing the various kinds of test results, analysis criteria, etc.

URL's look like this:
\toa\equipment\
\toa\equipment\new
\toa\equipment\321\    [Displays contents of a single record]
\toa\equipment\321\edit
\toa\equipment\321\oiltests\new

...and so on.

I have practically eliminated package-based traversal from the app.
There are a few admin functions that are still handled by modules in a
package, but I will probably wrap those in classes too.

Jim Dukarm
DELTA-X RESEARCH
Victoria BC Canada


_______________________________________________
Quixote-users mailing list
Quixote-users@mems-exchange.org
http://mail.mems-exchange.org/mailman/listinfo/quixote-users


reply