Oh struts, definately. I use struts like a toolkit. I hand a web page to our graphic artist with all the <html:text.../> and <bean:write.../> and <bean:message.../> in it. It can put them wherever he needs them with ease, just like an html tag. All the session/request information and logic is hidden through html 'like' (struts) tags (and our own custom tags). We use the jakarta XSL taglibs when the data is pulled from the database in XML format. I still wrapper the XML in a Java object so if we need to break it up and do business logic on it the interface can stay the same. Then when it gets to the JSP he just uses the jakarta XSL tag lib and transforms it where necessary. I just look at this argument as kind of academic. I say, use whatever your most familiar with but use it cleanly (JSPs use tags, javascript use a .js tag instead of inline javascript, etc). View, in my opinion, are not to be looked at as the reusable components of your system. Those should be your JSP tags (yay struts and jakarta tag libs!) and/or XSL documents. This is VERY pertinent to what we do as we make digital receipts that come from the retailer in XML format. You can imagine we DON'T want to have to write JSP code to transform every one of these for every new retail customer we get. We use XSLT on that. But that is because the data is comming as XML already and we're familiar with XSLT. The data we pull from the database we use JSP/struts/internal tags and value/form objects to populate the screens. Our graphic artist is great with XSLT so that is his preference and as a developer it is easy enough to change a Java bean to XML for him.
Here is a design I came up with (I'm the J2EE architect) for the system that addresses both these issues. All your value objects have a toXML() method. They also follow the bean format for all the data. The XML transformations are handled by Helper classes for serialization purposes. You can just call User.toXML() and get the XSL sheet for that XML if you want to use XML or you can use <bean:write name="user" property="firstName"/> if the data is not in XML but stored in the Java object's fields. Either way the interface is the same. This means that if we go to a new customer we don't have to change a lot of code except at the view layer. We use EJBs and override them as needed for new customers but deploy them to the same JNDI name (as long as the state flow is the same). Works like a champ so far. We're in development but it is nice. Mike ----- Original Message ----- From: "Donald Ball" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 6:06 PM Subject: Re: Additional <logic:iterate> helper tags wanted > On 9/11/2002 at 2:02 PM Michael Lee wrote: > > >Basically how we got the data dictated the view. I've found XSLT to be > >'wordy'. I think its just as easy to write another damned JSP and parse > the > >Java Objects up there as it is to create another XSL page and use the same > >JSP. > >I consider views to be relatively non-reusable so time to market is my big > >concern. > > Makes sense given your constraints. So when you throw together these JSP's, > do you use struts/JSTL taglibs or do you let yourself write scriptlets? > > - donald > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
