I have messed with both Cocoon using XML / XSLT extensively to render views to varying devices and also use the Struts Tiles framework to do the same. I found Cocoon very powerful for static XML documents but as soon as I started trying to hook dynamic content in (forms, JSP's, Servlets, Struts), and NOT through XSP, I was hitting walls daily. However, in Struts I was able to write a custom Tiles FactorySet which looked at the incoming UserAgent and then applied certain rules against that to select the factory. Once that was selected you could write a factory file to have custom JSP's render as the output to actions. I don't explain it all that well but it is actually rather nice. I suggest using this mechanism if you are using Struts and want custom views for each device type. We actually use this user agent mapping factory in every website we develop in our lab.
Sean P.S. I am working on getting this submitted back to Jakarta or at least Open Source it ... getting the company to do it isn't all that easy. Matt Raible wrote: > > Hmmm, > > I read everyone's posts, and they are somewhat inspiring. I'd like to > see > examples of using Xalan to get my struts message bundle, or other messag > bundles. I'm sure I could spend an hour and figure this out, but if > anyone has > ready examples, links, send them my way! > > XForms - I'm excited about these, but I think it'll be awhile before the > browser's support them. > > #3 is probably from my own experience. I spent a week trying to > develop a > XML/XSL framework using JSPs to emit XML, XSL and the JSTL to do the > transformation. My JSPs became very small and nice, but it seemed I was > spending a lot of time writing the XSL and trying to get it to work > properly. > I've had a lot of experience with writing HTML and JSPs, and so I > bagged the > whole idea and recommended we just use JSP/HTML with Tiles and CSS. I > know > that my client will get more value from my time with this approach. > > The reason my client wanted to use XML/XSL was to easily adapt the UI > for other > devices. I think this is a great reason, but it almost seems simpler > to me to > separate my HTML client from my WAP client and develop entirely new > JSPs for > the WAP client. > > Of course, working with a limited budget and a small development team > (1) - > there's not much time for learning curve. > > Matt > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
