Andrew,
I liked this article, I believe the whole approach should work for
converting XML to javabeans.
I've been thinking of the overall approach you suggest for such a Web
application.
Under the approach, I even think that by using ActionServlet or
Action/Command classes to stream data in XML format to the back-end we can
resolve server-side input validation in a nice way by attaching XML schema
to XML output . i.e. your action mapping in servlet configuration file would
include also schema file which in turn would validate the input S
Something along the lines:
<!-- Here goes mapping area, add pages and action mappings when needed -->
<url-mapping>
<request-url>actionName</request-url>
<class-name>Action/CommandClassName</class-name>
<target-url>/jsp/yourpackage/yourTargetJSP.jsp</target-url>
<!-- added now for XML stream (built from the form present on source JSP)
validation -->
<inputValidationSchema>yourValidation.xsd</inputValidationSchema>
</url-mapping>
Your action servlet helper/utility classes read the input form, stream it
into XML, attach validation class, set up error handler and transfer the
data to the backend.
If error occurs, your error handler class should output proper page back.
Thus we are taking server-side data validation to (IMHO) more proper place,
i.e. your custom schema datatypes. This makes it more maintainable and
easier to create.
It is my perception that under this approach on a trip from your Web server
to the backend session bean you do not need to create Javabean at all. This
is also the best place to do it under the present architecture because you
do not want to do validation on back-end EJB (network trips, security
context switch overheads, etc) where you have the logic, and you do not want
to replicate part of business logic then in EJB.
If your session bean on the backend outputs XML, maybe we can just use XSL
to achieve the desired output, instead of converting XML to beans using the
approach suggested in this article and then JSP querying that bean to build
HTML.
The question in my mind is that if this is the approach you had in mind,
does it obliterate JSPs and JavaBeans on the way? They somehow do not add
any functionality with that approach unless I miss something.
If I am correct, this architecture would reside around ActionServlet and
helper classes building/validating XML stream and input data, session beans
decoding XML into action attributes and then encoding it back on the trip
back, and related entity beans. It will also have XML schema for validation
on the trip from presentation/application layer (servlet) to services/domain
layer (EJBs) and XSL on the way back.
If I do not miss anything, this is drastically different from
JSP/ActionServlet/business classes/JDBC architecture several of us are
trying to use (with very helpful guidance of few others here on this list).
No worse, no better, just different thing which would perform better in some
applications requiring fault-tolerance, failover and heavy transactions, and
worse for some other purposes (mostly data retrieval, or non-database
business logic, etc).
Please advise if that I understood your architecture correctly.
Regards,
Vadim Shun
NEW Corp
Dulles, VA
-----Original Message-----
From: Andrew S Tomlinson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 25, 2000 12:30 PM
Subject: Re: Thin beans in model 2 - revisited
Vadim,
FYI there's an interesting article on JavaBeans that can render themselves
as XML at
http://developer.java.sun.com/developer/technicalArticles/Beans/XMLJavaBeans
3/
There's also the implication that the Bean can override the default
serialization
methods for this purpose.
Regards
@
===========================================================================
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
