[thelist] Java, XML and JSP. (LONG)

David.Cantrell at Gunter.AF.mil David.Cantrell at Gunter.AF.mil
Thu Oct 17 13:45:01 CDT 2002


>So with that XML file in place, when each JSP page is loaded, the location
of the file is found from the URL and passed to a >JavaBean.  Within the
JavaBean this location is compared to those locations within the XML and a
number of 2D arrays are
>passed back to the JSP page with all the navigational information it needs
for that particular section - The logic within
>the SAX parsing was a bit of a brain teaser, but works fine now.

Sounds like you've got a good plan which works for your site. One question
is, do you maintain only one central XML file for every section (aka
sub-site), and does the XML file model only global navigation between
sections, or does it also model navigation within those sections?

I use ASP/VBScript myself, and am working on re-architecting the site -- I
say that because the visual layout will remain almost completely identical,
but the underlying codebase is changing dramatically.

I'm basing my concepts on the FuseBox framework used in Cold Fusion, though
when I started working on this a while back there was no viable ASP version
of FuseBox. Though there appears to be one now, I am already far enough into
my own home-grown framework that I would rather stick with it since it was
created for my site specifically. It also essentially eliminates the biggest
problem I had in the old site, namely snarly includes and nested includes
which handled HTML and server-side code in the same file. No more of that,
everything is nicely separated now.

I use XML quite a bit, but in the old architecture it was used 99% of the
time to transform database results from MS ADO objects into XML so I could
pipe them through XSL for the display, eliminating that portion of display
code from the ASP code.

The new approach still uses XML heavily for database queries -- even more so
now that I've created a DatabaseObject class which will encapsulate ALL
database queries and return them only in XML format -- but it also uses XML
a bit more for configuration now as well. I have all site navigation
modelled in XML, though each section maintains it's own XML file for this,
rather than having a single central file. The site toolbar is an XML file,
and each section's left navigation bar is an XML file. Footer links are the
same as the site toolbar and drawn from the same file, just passed through a
different stylesheet for a different appearance at the bottom of the page.

The site toolbar looks like this:

<nodelist>
	<node name="Home" circuit="/ilspo/home/" action="homepage"
id="toolbar_link_home"/>
	<node name="Calendar" circuit="/ilspo/calendar/"
action="events.calendarview" id="toolbar_link_calendar"/>
	<node name="Program Documents" circuit="/ilspo/documents/"
id="toolbar_link_programdocs"/>
	<node name="Oracle Enterprise Buy" circuit="/ilspo/oracle"
action="homepage" id="toolbar_link_oracleenterprisebuy"/>
	<node name="About the SPO" circuit="/ilspo/about/"
id="toolbar_link_aboutspo"/>
	<node name="Contact Info" circuit="/ilspo/contact/"
id="toolbar_link_contactinfo"/>
</nodelist>

As in your e-mail, here's the annotation:

* Each node is a separate link
* @name is the displayed text of the link
* @circuit is the path to the section's control file -- as in your case,
every section will have a master default.asp file which will handle all link
interactions between files in that section, also similar to the FuseBox
method, hence the name "circuit" -- though I think I'll rename that to
"section" shortly
* @action is the action passed via the querystring to the default.asp file
in the referenced circuit
* @id is the DOM ID of the element when it is created by the XSL file, to
allow rollovers, etc via DHTML

So for example, given the node named "Home", the built link would look like
this:

	<a href="/ilspo/home/?action=homepage"
id="toolbar_link_home">Home</a>

You get the idea...

Using the <nodelist> and <node> approach is a legacy use from the current
site, I may change that to standardize it to be more like the left
navigation syntax. I had a weird idea a year or two ago that didn't pan out
like I expected, and so <nodelist> is not very helpful syntax now. But it
works as-is, so I've left it alone for now. ;)

Leftnav XML files look like this:

<leftnav>
	<section title="Upcoming Events">
		<link title="90-Day Calendar" action="events.calendarview"/>
		<link title="90-Day Listing" action="events.listview"/>
		<link title="Add New Event" action="events.addnew"/>
	</section>
	<section title="TDY/Leave">
		<link title="90-Day Calendar"
action="absences.calendarview"/>
		<link title="90-Day Listing" action="absences.listview"/>
		<link title="Add New TDY/Leave"
action="absences.addnew_form"/>
	</section>
	<section title="Editors">
		<link title="Log in" action="login"/>
	</section>
</leftnav>

Again, it works much the same as the <nodelist> syntax:

* section is a logical grouping of links in the left navigation bar
* section/@title is the title of the section, displayed above the links
* link/@title is the text displayed for the link
* link/@action is the action passed to this section's default.asp file, same
as the global toolbar.

A built link would look like this:

	<a href="./?action=events.calendarview">90-Day Calendar</a>

I don't have IDs for these because I haven't needed to add any DOM scripting
to them. Yet. <g> I probably should add IDs to them for future use though.
:)

I've also been pruning my VBScript classes greatly, only bringing over the
ones I absolutely need, and modifying them as necessary and documenting them
thoroughly. Someday I'm going to get around to finishing a VBScript class
documentation generator, but for now I'll stick with what I've got.

Later,
-dave



More information about the thelist mailing list