Hi,
If you just want to parse an XML file and get a DOM object, you use almost any XML
parser. In my case, what I did is that I wrote a small adapter class that has a
list of possible xml parsers, detects the xml parser that I have installed in the
classpath and uses the first one in the list that is installed. You just have to
write an "adapter" class for the specifics of every parser (about 2, 3 parser
specific lines usually) and then use the standard org.xml classes to use the actual
parser. This allows you to use any parser that conforms to the org.xml standard
(almost all) now and in the future, just by writing a small adapter class for the
new parser and modifying this list (I have it hardcoded now, but it would be soooo
easy to get it from a properties file :)). I now allow people to use either Xerces
from the XML Apache project, or the parser from the Java Project X, from Sun. I
might add TinyXML to the list, thanks for the pointer Donald :).
I hope this helps,
Dan
"Donald E. Vandenbeld" escribi�:
> I use an open source product called TinyXML
> (http://www.gibaradunn.srac.org/tiny/) to parse the configuration file.
> It's a pretty simple, non-validating XML parser. I found their example
> really easy to follow and wound up accidently building the parser while
> playing around over a lunchbreak. The website I'm working on will
> eventually need to deliver XML files (translated through XSL) so I'll
> eventually switch to Cacoon or something similar.
>
> I preload it into a hashtable of actions in the main servlet's init() method
> (because the configuration data is so heavily used). The hashtable of
> actions contain action objects which in turn have a hashtable of intents
> (containing intent objects). Code readability and ease of maintenance is
> why I decided on this method. I don't imagine hashtables to be a terribly
> efficient performance wise, but I find it really helps keeps things straight
> when coding.
>
> Donald
>
> > Interesting. My only question, due to performance...why not use "int"
> value
> > returns instead of Strings. Mainly because I am quite sure evaulating an
> int
> > value is much faster than doing a string comparison. I realize Strings are
> > nice, easy to understand, but in terms of performance I would imagine
> using
> > int values would be much faster for lookup in the DOM.
> >
> > Incidentally, how are you reading in your XML file, and into what type of
> > object? I have heard alot about how some of the free XML parsers turn XML
> > files into a DOM object. Is that part of the XML package? Or is it an
> object
> > you create? I would love to get more info on this process as I want to
> > implement this soon.
> >
> >
> >
> > >-----Original Message-----
> > >From: A mailing list about Java Server Pages specification and reference
> > >[mailto:[EMAIL PROTECTED]]On Behalf Of Donald E. Vandenbeld
> > >Sent: Tuesday, April 11, 2000 1:48 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: More on Model 2/little confused
> > >
> > >
> > >I'm doing it something like this:
> > >
> > >First off, I'm using an xml file to store my configuration. This
> > >works best
> > >for me but a simpler configuration could easily use a properties file.
> > >
> > >The first part of the config file defines resource types (by resource I
> > >basically mean 'pages' within the site that may be accessed). I define
> the
> > >following:
> > >
> > > <resource id="static">
> > > <path>/</path>
> > > <extension>.html</extension>
> > > </resource>
> > >
> > > <resource id="dynamic">
> > > <path>/</path>
> > > <extension>.jsp</extension>
> > > </resource>
> > >
> > > <resource id="program">
> > > <path>/servlet/</path>
> > > </resource>
> > >
> > >I then create a series of stimulus defintions. These define what action
> to
> > >take given a certain stimulus. The stimulus is simply a parameter called
> > >'action' that gets defined in every form in the site. Here is a simple
> > >stimulus definition:
> > >
> > ><stimulus id="Login">
> > > <action type="dynamic">login</action>
> > ></stimulus>
> > >
> > >So, if the current 'action' request parameter is equal to "Login", the
> > >controller servlet should redirect to the 'login' page. Because of my
> use
> > >of resource types, this gets translated into: /login.jsp (this make it
> > >really easy to install the site in different directories on different
> > >servers). Here is a more complex stimulus definition:
> > >
> > ><stimulus id="ValidateInitialLogin">
> > > <action type="program">AuthenticateServlet</action>
> > > <intent>
> > > <default>CheckAnnouncement</default>
> > > <condition result="user">CheckAnnouncement</condition>
> > > <condition result="instructor">CheckInstructorAnnouncement</condition>
> > > <condition result="staff">CheckStaffAnnouncement</condition>
> > > <condition result="admin">CheckAdminErrors</condition>
> > > <condition result="error">Login</condition>
> > > </intent>
> > ></stimulus>
> > >
> > >If the current action is 'ValidateInitialLogin', the controller servlet
> > >should redirect to the AuthenticateServlet. Where my
> > >implementation differs
> > >a bit is that I can specify different actions to take depending on the
> > >results of the AuthenticateServlet. For instance, if this latter servlet
> > >gets an error, it should set the action variable to 'Login'. If the
> > >AuthenticateServlet runs and finds that the user belongs to a
> > >class of users
> > >called 'instructor', the servlet should get the action variable to
> > >'CheckInstructorAnnouncement'. The default tag is maybe a little
> > >missleading - it is really supposed to indicate the default condition.
> > >
> > >This system works pretty nicely. These 'action servlets' simply create
> > >beans that do all the real work (connecting to databases, performing
> > >queries, etc) and then set a (string) result code. A few lines of code
> at
> > >the end of each of these action servlets redirects to the
> > >appropriate jsp or
> > >servlet depending on the result code. I'd be interested in hearing about
> > >how others implemented this idea (or critiques of the way I did it).
> > >
> > >Donald
> > >
>
> ===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
