Hi guys,
First, yes, I am very "with you", and have been keeping up to date on
the mailing list posts. Having just read through the last 3 days'
posts, this is how I see your current architecture for the admin config
and web-based mail tool:
Mail Server sitting potentially across geographic space from the web
tier, which uses RMI to retrieve an XML config file to parse with
proprietary code, populate a JSP page, and display to the user (assuming
proper login credentials).
I don't mean to be a broken record, but why parse the config XML into
Java objects, then fill in the form with that? This architecture
accomplishes the same thing but leaves out the manual XML parsing and
form creation:
Mail Server sitting across geographic space from web tier, which gets
the config XML file over RMI, and passes it straight to an XSLT that
operates on the config file itself (but _only_ for displaying its data,
all updates to it happen elsewhere "the config file must not be directly
written [fk]"). The XSLT creates HTML (or WML/HDML for administration
from cellphones and PDA's, this is a fairly trivial addition*), with a
form that posts back to the same servlet, which sends the data back over
RMI to be put into the config file by the server itself.
* I am NOT referring to having a web mail client available to these
devices, I am specifically referring to administration, though in the
long run we leave that option open by doing this.
A few notes on the feedback from my initial post:
1. We are absolutely not creating Amazon.com or something like that
here, but at the same time, we are providing a tool that (hopefully)
people will continue to use for some time. With such technologies as
XSP (http://xml.coverpages.org/WD-xsp-19990611.html, note this article
is 2 1/2 years old) being developed, JSP is losing ground to
standards-compliant means of accomplishing the same thing.
2. This model does use servlets, it just does not rely on proprietary
means for creating the HTML to show the user. The following psuedo-doGet
illustrates my point (uses javax.xml.transform classes, available with
Apache Xalan... http://xml.apache.org):
public void doGet(request, response) throws
theUsualExceptionsAServletDoGetWould {
response.setContentType("text/html; charset=UTF-8");
PrintWriter out = response.getWriter();
try {
XMLConfigFile config = RMILayer.giveMeTheConfigFile(); //
assuming it extends File, not even possible but simple for example...
// this is the XSLT stuff
TransformerFactory tf = TransformerFactory.newInstance();
Transformer t = tf.newTransformer(New
StreamSource(URL_OF_XSLT_FILE));
t.transform(new StreamSource(new FileInputStream(config)), new
StreamResult(out));
} catch(Exception e) {
out.print("<html><body><p>Servlet Blew Up.</p></body></html>");
}
}
That way, nobody ever needs to see this code when they download the
binary version.
If there is a strong backing still to use JSP, then I concede, but I
really believe there is a value-add in using an XML-based technology to
display XML-based information. Any feedback is appreciated, unless
you're pointing out the impossibility of sending a java.io.File across
RMI ;-) .
Anyway, now that I've spammed you all with my opinions, give me yours
and let's solidify exactly what who is doing. I am comfortable writing
JSP's if that is what we end up agreeing on, but let me know either way.
Talk to you all soon,
Ben.
|
