> -----Original Message-----
> From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 10, 2000 12:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Model 2 & 3 Architecture
>
>
> Hi,
>
> I'm not sure too whether what you call Model ++2 would
> qualify as a new
> model, as generating the JSP manually or from a XML file at
> design time
> doesn't introduce a new element in your model 2 arquitecture. I'd vote
> for Model 3(Model 2++) as a new one because it's not an
> extension of the
> JSP model. In our first application we are not using JSP at all(we get
> it from PL/SQL) and you might generate the XML directly from
> a servlet,
> a WebMacro template... but anyway, the name is not important
> as long as
> we all understand each other.
Agree completely. The names apart from my attempt at humor was just so that
I could refer to the different versions and people would know what I meant.
>
> Regarding Model ++2, I've been thinking about it to see if we
> could also
> use it (I don't enjoy adding layers for the sake of it :) ) and I've
> come across some doubts that some of you might help me understand.
>
> .- As disadvantages, I'd add that is JSP dependent and you
> don't really
> get a clean separation of business logic/UI or at least as clean as
> Model 3. If the Web Designer has to change something in the UI, he has
> to change the xslt sheet and then ask technical people to re-generate
> all the JSP pages affected by the change, doesn't he? You
> cannot change
> the JSP's direclty, otherwise you'd loose the changes when you
> re-generated the JSP's.
>
> Let's see if I get the whole process with a very small sample
>
> 1.- You give the XML file to the designer
> <Customer
> Name="John Doe">
> <Account ID="01" Balance="1230$">
> <Account ID="02" Balance="-50$">
> </Customer>
>
> 2.- The designer wants to produce the following output
> <table>
> <tr><td>Name:</td><td>John Doe</td></tr>
> <tr><td>Account 01</td><td>12030$</td></tr>
> <tr><td>Account 02</td><td bgcolor="red">-50$</td></tr>
> </table>
>
> 3.- So he produces this XSLT
> <xsl:template match="Customer">
> <table>
> <tr><td>Name:</td><td><xsl:value-of select="@Name"
> /></td></tr>
> <xsl:apply-templates select="Account" />
> </table>
> </xsl:template>
> <xsl:template match="Account">
> <tr>
> <td>Account <xsl:value-of select="@ID" /></td>
> <td>
> <xsl:if test="@Balance<0">
> <xsl:attribute
> name="bgcolor">red</xsl:attribute>
> </xsl:if>
> <xsl:value-of select="@Balance" />
> </td>
> </tr>
> </xsl:template>
>
> 4.- The JSP you would like to produce would be something like..
> <table>
> <jsp:useBean id="theCustomer" scope="request"
> class="Customer" />
> <tr><td>Name:</td><td><jsp:getProperty name="theCustomer"
> property="name" /></td></tr>
> <% for( Enumeration e = theCustomer.getAccounts();
> e.hasMoreElements;
> )
> {
> Account theAccount = (Account) e.nextElement();
> %>
> <tr>
> <td>Account <%= theAccount.getID() %></td>
> <td
> <%
> if(theAccount.getBalance()<0)
> {
> <%
> bgcolor="red"
> %>
> }
> %>
> ><%= theAccount.getBalance() %></td>
> </tr>
> </table>
>
> I don't see how you could get easily number 4 from 2 and 3. I
> get it for
> simple cases where you might substitute the real name of the
> customer in
> the XML file for <%= theCustomer.getName %> etc... but how about loops
> and conditions? Do technical people have to refine the generated JSPs?
> Or have I misunderstood the whole process?
Without trying to answer this in detail, the goal is to NOT have anyone
modifying the generated JSPs. Our application domain has a lot of consistent
presentations that then need to be replicated across multiple business
objects. We have a small team whose sole job is to maintain the
transformations. When alterations to the resulting HTML are required, this
team will determine how best to express the essence of the alterations
required in XML and then provide the XSL transformation logic to produce the
desired results.
Regarding loops/conditions, our transformations are producing JSP files. So,
we can put any Java code we want in them. This does make the job of creating
our transformations a very technical one. Transformation developers need to
understand HTML, CSS, XML, XSL, JSP and Java. Luckily, we have a small team
of people with skills in all of these technologies. (If you know anyone with
this skillset looking for a job at a pre-IPO internet startup in Silicon
Valley, please put them in contact with me. :-))
I can see the point about it being expensive to do a lot of customization of
individual pages with this approach. If that was my model with web designers
tweaking the HMTL output all the time, I wouldn't use this approach. In our
context, the expected process is one of a designer coming up with the
standard presentation format for a business object listing or whatever and
then encoding that in a transformation that gets used 10s or even 100s of
times. Even when this format has to change, it is better for us to make the
change once and reverse-engineer it back into our transformation rather than
modifying all the effected JSP files.
A key elemet of the process is that we have business object definitions in
XML that define the members of the business object and provide information
like data type, internal name for use when accessing it in the EJB layer,
external name for display in the web page, and other useful information.
Separate from the business object definitions, we have presentation
definitions also in XML. Presentation definitions specify the type of
presentation and contain references to the separate business object/member
definitions to include in the presentation. For example, a business object
listing presentation contains at a minimum the subset of all members of the
business object to include in the listing and the order to list them in each
entry of the list. The way that each member is displayed is determined by
the business object definition information.
If this approach is successful, we have a team of technical people
maintaining the transformations. We have designers giving us direction on
what the results of our standard reusable transformations (which use CSS
heavily so that the designers can tweak appearance by changing only the
separate CSS files). We have application builders that create a set of
relatively simple XML documents that we then transform based on the
designers specifications into our standard web presentation format for them.
>
> Thanks
> Dan
> -------------------------------------------
> Daniel Lopez Janariz ([EMAIL PROTECTED])
> Web Services
> Computer Center
> Balearic Islands University
> -------------------------------------------
>
> Mike Van Riper wrote:
> >
> > Lee,
> >
> > It sounds like what you are doing is quite similar to our
> approach (using
> > XSLT at design-time to generate JSP files). I agree with
> your assessment of
> > the two variants for applying XSLT to the JSP Model 2
> architecture. I'm not
> > sure it qualifies as a whole new model though.
> >
> > <Bad Joke>
> > How about:
> > JSP Model ++2 (for XSLT preprocessing input XML to
> produce the JSP)
> > versus
> > JSP Model 2++ (for XSLT postprocessing output XML from
> JSP execution)
> > </Bad Joke>
> >
> > - Mike Van Riper
> > [EMAIL PROTECTED]
> >
> > > -----Original Message-----
> > > From: Lee Elenbaas [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, May 09, 2000 2:31 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Model 2 & 3 Architecture
> > >
> > >
> > > What i have learned is from listening in this list.
> > > Model 2 is setting a single entrance servlet to all your
> > > JSPs. that servlet
> > > performs common tasks like ID user and secuity tests and then
> > > forwards the
> > > request to the appropriate JSP/servlet, that JSP/Servlet
> jenerates the
> > > HTML/content that the user sees
> > >
> > > Model 3 adds another layer of XML. There are two variations:
> > > JSP/Servlet generates XML, that XML gows through XSLT
> (usually in the
> > > server) to what the user sees.
> > > The other approach (and the one we are testing in our
> > > company) is XML that
> > > are trasformed through XSLT to JSP pages, those JSP pages
> generate the
> > > HTML/content that the user sees.
> > >
> > > Both variations added a level of seperation between the UI
> > > design and the
> > > java code.
> > > The 1st variation has the added advantage of being more
> > > client responsive.
> > > This means you can generate using the same JSP and XML
> different views
> > > according to the user platform: browser, WAP device...
> > > The 2nd variation has the advantage of removing the XSLT
> > > overhead from the
> > > runtime. (and to my opinion it can also provide what the
> 1st variation
> > > provides, but with more jenerated JSPs)
> > >
> > > lee
> > >
> > > Lee Elenbaas
> > > ViryaNet
> > > [EMAIL PROTECTED]
> > >
> > > -----Original Message-----
> > > From: A mailing list about Java Server Pages specification
> > > and reference
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Germ�n L�pez Castro
> > > Sent: Tuesday, May 09, 2000 11:09 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Model 2 & 3 Architecture
> > >
> > >
> > > Hi-u-all.
> > >
> > > I think I've got a black hole in my acknoledgement, but... could
> > > anyone explain me what architecture 2 & 3 are exactly and
> where can I
> > > get further information?
> > >
> > > Thanxalot.
>
> ==============================================================
> =============
> 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
- Mike Van Riper
[EMAIL PROTECTED]
===========================================================================
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
