Hi Mike,
Mike Van Riper wrote:
>
> Daniel,
>
> At my company, we are working on a similar process to yours. Our
> non-programmers will be creating simple XML documents. We then run a
> design-time build process to transform the XML documents into JSP pages. We
> are building common transformations for things like business object
> listings. The same XML DTD for a business object listing can be used to
> define the layout for the listings of different business objects in separate
> XML document instances. The beauty of this approach is that we get a
> consistent look to all our listings and can change the look at anytime for
> all listings by changing the XSL transformations that produce the JSP files
> from the XML document instances.
Yeah! We follow a similar approach but with dynamic transformations. It
its very appropriate when you need different look and feels depending on
some circumstances (for example, in web hosting business).
> Another good aspect of this approach is that we don't have a runtime
> performance hit doing an XSL transformation. Of course, there are still
> things that have to be decided dynamically at runtime. For that information,
> we encapsulate the Java logic in beans.
Eummm? I might have not got it right. You are performing the
transformations at desing time and then adding dynamic info with Java
Beans? How? Do you generate JSP pages from XML, instead of generating
HTML? We don't generate the output formats (XSLT sheet) at runtime, we
just apply it to the dynamically generated XML. Even though it would be
possible too, but fortunately we don't need such a complex
transformation process.
> The obvious disadvantage of our
> approach versus yours is that we can't do the "on the fly" generation of
> different output formats. However, we can still support different output
> formats by generating the multiple formats in our design-time build process.
> I will let you know in a few months how it pans out because we are just now
> going from investigation phase into design/development of this approach in a
> big way.
We hope to have the first application ready in 2 weeks. But we are
generating the XML directly from PLSQL which speeds up enormously the
database access coding. Good luck with your approach.
Regards,
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
>
> FYI,
>
> Mike Van Riper
> [EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, May 08, 2000 12:06 AM
> > To: [EMAIL PROTECTED]
> > Subject: Model 3 Architecture
> >
> >
> > Hi,
> >
> > Some people asked my about this "Model 3" I talked about in my last
> > posting about "model 2 servlet mapping question" so I thought I should
> > explain what I meant, not to confuse people. First, before
> > people starts
> > asking about specifications and documentation, it's by no means an
> > official name and AFAIK it hasn't been mentioned anywhere.
> > It's just an
> > idea several people in this list seem to be using and I just have to
> > give it a short name so... my apologies if this drrove someone to
> > confusion. Explanation follows:
> >
> > After playing a while with model 2, I have to admit it's far
> > for perfect
> > and one of the places where it doesn't convince me is in the
> > part where
> > web designers (non programmers) have to deal with JSP code to generate
> > the UI. Sure that taglibs will help and sure that tools will
> > come up to
> > help drag&drop development but it still doesn't convince me so I
> > thought, as many others, of using XML&XSL as an extra layer(hence the
> > name Model 3) between the generation of the data and the
> > construction of
> > the UI. The architecture goes like that:
> > .- Controller servlet gets a request and determines the appropriate
> > Action to be executed.
> > .- The Action performs the business logic using the data
> > sources (Files,
> > DB) and forwards control to the appropriate JSP to "format"
> > the result.
> > .- The JSP page formats the result in XML, which is more easily
> > understood by designers, can be used as documentation, and for which
> > fake document sets are easily generated. The JSP can also
> > determine "on
> > the fly" which XSLT sheet will be used to generate the UI.
> > .- The XSLT sheet transforms the XML into HTML, WML, PDF and result is
> > sent to the client.
> >
> > Advantages:
> > .- Programming part and design are completely separated. You
> > just agree,
> > at the beginning if possible, the format of the XML documents and then
> > the programmer have to care on how to generate them
> > dynamically and the
> > designers on how to generate the UI from them.
> > .- IMHO, there will be more tools to handle XML&XSL -> HTML than
> > drag&drop JSP to HTML. XML, XSL are already standards,
> > taglibs are not,
> > and it will be easier to train, or find somebody trained, in these
> > technologies than in using taglibs with some mixed Java.
> > .- Your desing is more technology independent, you might decide to
> > change to WebMacro to generate the XML and you wouldn't have
> > to bother
> > your designers with a new syntax. For example, in our first
> > application
> > we are going to mix XML generated from JSPs with XML
> > generated directly
> > with PL/SQL.
> > .- There are some others because of using XML, XSL but I'm focusing on
> > the XML&XSL vs JSP.
> >
> > Disadvantages
> > .- Performance: We have yet to test it but adding an extra
> > layer always
> > means more computations. We are trying to avoid that using direct
> > generation of XML from PL/SQL when possible but we know we'll have to
> > pay for this extra layer. We hope improvements in the parsers
> > and smart
> > caching of XSLTProcessors will help in this regard.
> > .- XSL,XSL are not widely known by designers. But we hope that's a
> > matter of time before tools and relatively widespread knowledge of the
> > technology are there. And you would have to teach your designers your
> > taglib&Java-mix syntax anyway so...
> >
> > We are developing our first application using these approach
> > and that's
> > what we've learnt so far. I know it can be an overkill for some apps.
> > but it might be very adequate for others. Anybody that's using it has
> > gathered more info? Comments anyone? Anybody can think of
> > another, more
> > appropirate name? ;)
> > Regards,
> > Dan
===========================================================================
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
