Hi,
As we have also rolled our own solution, I'll just add my two cents.
As Tim, we found that the existing frameworks didn't fit quite well into
what we wanted to do, (that was even before Struts was created) and as
we wanted to integrate other features...
Following the Model 2-controller servlet approach, we have a centralised
servlet, driven by an XML file, that specifies XML/XSLT sources for any
given path. However, most of the times we are not generating XML in
Java, but directly from PLSQL. We think that EJB is too much/too painful
to develop for most of our applications so we developed a small library
that allows us to generate the XML content directly from PLSQL. If you
need to handle session values and the like, you can also use JSPs to
generate part of the XML and integrate it with PLSQL generated XML. We
also provide ways to modify the defined sources (XML or XSLT) on a
per-request basis so it is quite flexible. We also use precompiled
style-sheets, which, last time I checked, boosted our performance
sometimes by a factor of three! Last detail I added to our XSLT cache is
that precompiled stylesheets are stored through Soft References, thus
preventing the cache from eating all the memory and providing a
"controlled degradation of service" (not sure if that is the english
translation ;))
We included also:
.- a logging system, which we hope to be able to remove as soon as 1.4
provides something similar
.- a flexible security system, which much more flexible that the one the
JSDK spec. provides
.- internationalisation, which allows us to change the config values
depending on the language value
.- browserization which also allows us to change the config values
depending on the browser Agent and Accept strings.
.- Our own connection pools, which we are thinking about replacing with
another library...
All in all... a .jar file of about 294KB
The key point, IMHO, is to stick to standards as much as you can, and
to allow different parts to be replaced when time comes. For example, we
used to have a module that made the XSLT processing independent of the
XSLT processor, now that JAXP 1.1 has done so, we removed the module and
substituted it with JAXP. The better the standards, the easier to
mantain our library.
On the "how to handle such a project" side, we also follow the model of
providing the designers with a set of static XML files so they can start
playing with them while other people implement the logic. When logic is
ready, you substitute XML_SOURCE="/.../static.xml" with
XML_SOURCE="plsql://.../package.procName" and almost voilą ;). "Almost"
because you still have to check that parameters are passed and things
like that.
We are pretty happy with it, as it allows us to concentrate on the real
application (presentation->XSLT, logic->PLSQL/BDD) and we don't have to
spend that much time developing Beans, interfaces... If we needed to, we
would be able to use EJB, but for us it's been not worthy (so far).
Just my 2ec,
D.
PD: We have had 5-6 applications with this system running production for
a almost 1 year and half. We don't have big ones, but we have lots of
them ;).
Tim Endres wrote:
>
> We rolled our own servlet for this. I found none of the existing frameworks
> to properly address what we needed. It is not a complicated thing to write.
> An XML config file specifies the commands that get executed for any given
> pathinfo. The command is tied to an XSL stylesheet, which processes the XML
> that the command generates.
>
> Precompiled stylesheets are effectively XSL stylesheets that have already
> been parsed from the XML text into the DOM Node tree that is used by the
> XSLT processor. These "compiled" stylesheets are then Serialized out, and
> then Serialized back in, such that our code can then skip the cost of
> parsing the XSL's XML file, in exchange for the cost of serialization.
>
> tim.
>
> > Tim,
> > that sounds v.interesting. Forgive my ignorance but what toolkit are you
> > using and what do you mean by "precompile the XSL pages"?
> >
> > Thanks,
> > Trevor
> >
> > On Thu, 26 Apr 2001, Tim Endres wrote:
> >
> > > We do exactly what you propose. A servlet drives lightweight commands. The
> > > commands get XML trees containing the HttpServletRequest information, and
> > > fill in a subtree with the XML results. This tree is fed into XSLT and the
> > > resulting HTML is sent down the wire. I prefer it over JSP by miles. We
> > > precompile the XSL pages, so we get really good performance. And the
> > > separation of content/presentation could not be better.
> > >
> > > tim.
> > >
> > <SNIP>
