Re: Struts with XSLT
On 8/18/05, Eduardo Ribeiro da Silva <[EMAIL PROTECTED]> wrote: > Anybody knows how I can generate JSP with struts tags with XSLT and pass JSP > to > JSPProcessor, for compile them? Because I have tags that client browse simple > don't known. The strategy you are asking for is essentially: Application Code --> Generated JSP --> Compied JSP --> Dynamic Output And it is not really practical, given the way that JSP works. Itt would force you to create, compile, execute, and throw away an individual JSP page for every request. Even if everything else was instantaneous, the multi-second compile time for every JSP would be deadly to response time. Instead, the solutions being discussed in this thread are more along the lines of: JSP --> Generated XML --> Post-processing XSLT transformation(s) --> Dynamic Output Where the XSLT transformations might be done on the server, or might be done on the client. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
We have been using stxx for a while now, mostly for output transformations only and it work perfectly. I would recommend you to consider it, and I have no stock in stxx ;-) ! Apart from this, we quite often use inline XSL transformations provided by JSTL nowadays not as flexible, but certainly useful in 'hybrid' designs. Complex form stuff, and pages which need to be update oftern are mostly taken care of by jsp2.0 pages seems that our designers prefer jsp2.0 over the (for them) more complex XSLT. regards, Peter On Thu, 2005-08-18 at 16:31 +0100, Graham Smith wrote: > On Thursday 18 August 2005 16:02, Don Brown wrote: > > Hmm...smell of death for stxx might be a bit harsh :) > > Yeah ok, it was a bit harsh - sorry. I'll take another look. It's sometimes > hard to know when a project is on it's last legs though. A message from one > of the core developers within an hour is a pretty good assurance that it's > alive and kicking though :o) > > > While it true I > > need to get a release out that better supports 1.2, I've been using it > > in production for over a year without problems, and would recommend > > you take another look. You, of course, are welcome to get involved, > > submit patches, even join the project. > > I have been looking for a project to work on in my spare time (just a mo > while > I pick myself up off the floor from laughing at the idea of having spare > time). If I decide to stick with XSLT I'll probably contribute. > > > > > Regarding Struts and XSLT, I've had a good experience ditching JSP. > > XSLT is powerful and fun even once you get the hang of it. Now to > > your questions... > > > > On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > > > > > > > * Should I just stop fighting city hall and abandon XSLT in favour of > > > JSP? * Perhaps it's still a little early to say exactly how Struts 2.x > > > will turn out but will the idea of view technology independence be > > > maintained? > > > > Of course there isn't a Struts 2.0, yet anyways, but Struts Shale is > > already exploring an alternate view, HTML templates, for JSF and JSF > > itself is designed to be view independent, however, I haven't heard of > > any view handlers that use XSLT yet. > > I certainly couldn't call myself a JSF expert but I have, I believe, had > enough experience of it to realise that the intended goal writing one page > and using alternative renders for different devices doesn't really work. > While it's great that you can, in theory, install other renders for the JSF > tags it rapidly becomes almost impossible to maintain. > > I can't believe, for instance, that it would be possible to develop a page > that would look good in both a standard browser and a mobile phone. This is > at the heart of my interest in XSLT. It removes the whole plug-in render mess > that JSF seems to have got itself into. On the flip side the reason I am > interested in using JSPs is that I only need to develop for fully featured > browsers. > > Thanks for the feedback, > > Graham > > > Another project we are working > > on in the sandbox, Struts Ti, already has support for XSLT. > > > > Hope that helps, > > > > Don > > > > > * If Struts 2.x doesn't (essentiall) force us to use something akin to > > > JSF will XSLT still be a viable option? > > > > > > Thanks for reading this far. I really look forward to hearing your views. > > > > > > Graham > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts with XSLT
Hi All, Seems a bit of the "silver bullet" scenario is going in the discussion of XSLT versus Struts approach, someone has correctly said "there's no silver bullet". You are required to use your judgement based on your experience on which tool/technique to use for what situation for optimal results. Again I don't claim to know all but here' my 2 cents on some of these off the top of my head:- XML/XSLT Pros i. Multiple rendering formats for multiple channels/devices. HTML/WML/... Cons i. Usually very slow for complex page with lot of transformations Struts Pros - a. Cleaning up very complex navigations into more manageable and maintainable structure. Cons a. It's in bed with JSP rendering, and lot of the add-ons can't be utilized generically such as in the case of XMS/XSLT Again technologies tend to evolve over time, just like Servlets was the "thing to do" when all you had was CGI, and Struts improvised on Servlets to make the hard wiring and navigation of the controller servlet into more managable XML configuration. And now there's JSF/Shales/Spring Framework and God knows what else... so take your pick and mix and match for best results! There no silver bullet is what I'll still say... with time everything changes. Regards, Dharmendra ps: have a good day! -Original Message- From: Leon Rosenberg [mailto:[EMAIL PROTECTED] Sent: Thursday, August 18, 2005 4:28 PM To: 'Struts Users Mailing List' Subject: AW: Struts with XSLT > -Ursprüngliche Nachricht- > Von: Michael Jouravlev [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 18. August 2005 22:11 > An: Struts Users Mailing List > Betreff: Re: Struts with XSLT > Ever heard of translets? But even if you call XSLT processor > for every request, I D-O-N'T C-A-R-E. This is not a software > problem, this is a hardware problem. And even expensive > hardware in the end of the day comes cheaper than money spent > for software workarounds. Your experience with zillions of > concurrent customers may tell you different things, I try to > respect that ;) Well, there are actually some hardware requirements, like max. amount of RAM you can use effectively on linux and so on. But, by the way, who said, the software development with XSLT/XML is faster then with JSP/JAVA-Objects? I highly doubt it :-) > > > > Keep it if it works. Don't forget that modern browsers can accept > > > XML and have built-in XSLT processor. So, you can send your > > > serialized bean data as XML with linked XSLT stylesheet > with linked > > > CSS stylesheet. > > > > Now this is an urban legend :-) Each browser support it > it's own way. > > Not to mention each version of the redmond browser supports ist own > > extensions. None of them are compatible. > > Umm, MSXML or whatever it was called, has an old XSLT implementation. > MSIE 6.0 XSLT processor is much better. And it is around for > 5 years, so customers with MSIE less than version 6 should be > simply not supported. Heck, they probably already have bought > a new car since they installed MSIE 5. Now it is time to > change oil in their computer too. I'm not even sure, that 6.0 sp1 and 6.0 sp2 have the same xslt processor. My experience with microsoft tells me, that 7.0 will differ. Not to mention mozilla and opera. And what about the coming google browser? > > > > > * Perhaps it's still a little early to say exactly how > > > Struts 2.x will > > > > turn out but will the idea of view technology independence > > > be maintained? > > > > * If Struts 2.x doesn't (essentiall) force us to use > > > something akin to > > > > JSF will XSLT still be a viable option? > > > > > > You can do it in Struts 1.x too. Instead of forwarding to > JSP page > > > just stick XML (or XML/XSLT already processed into HTML) into > > > response object and return null from an Action class. > > > Apparently, you would use ActionForm for input only with request > > > scope, and store your app data somewhere in the session or in > > > database. > > > > Actually it's better to write out the dom object (if you > have one, but > > you should, if you seriously want xslt/xml). > > I would also look into rendering with SAX, it could > probably give you > > 40-50% more performance then dom rendering. > > Did not quite get that. If you want to work directly with > DOM, then you probably need to return XML, that is what Ajax > components usually
RE: Struts with XSLT
Anybody knows how I can generate JSP with struts tags with XSLT and pass JSP to
JSPProcessor, for compile them? Because I have tags that client browse simple
don't known.
-Original Message-
From: John Martyniak [mailto:[EMAIL PROTECTED]
Sent: Thu 8/18/2005 7:08 AM
To: Struts Users Mailing List
Cc:
Subject: Re: Struts with XSLT
I have also successfully used Struts and XSLT, Haven't had an issue.
I currently use JSP to generate the dynamic top component, and then
include the XSLT generated HTML in the main content area.
I think that it is easier to manipulate XML with XSLT then it is to
do it with JSP/Tags.
-John
On Aug 18, 2005, at 12:36 PM, Mark Benussi wrote:
> I used XSLT for all my applications to generate content as html
> files which
> Struts includes in a page template using tiles.
>
> It also allows me to search the pages as pure html content.
>
> If you are putting logic in your page you could... don't shudder,
> use XSLT
> to generate JSP's.
>
> -Original Message-
> From: Graham Smith [mailto:[EMAIL PROTECTED]
> Sent: 18 August 2005 15:13
> To: user@struts.apache.org
> Subject: Struts with XSLT
>
> Hi folks,
>
> This isn't your usual "How do I do X?" type question so get ready.
> Hopefully
>
> it will fuel a good discussion. I'm fairly new to struts but have a
> solid
> grasp of Model 2 design ideas. The problem, I suppose, is that I am
> a lone
> developer (for my own company) which makes it hard to get the
> balanced view
> of the technology arena that is aquired through working with other
> developers. Therefore I have a couple of high level architecture
> questions
> that I am interested to hear your views on.
>
> The current application that I am working on uses XSLT to generate web
> pages.
> As you wold expect a bunch of beans (and some other objects) get
> converted
> into XML, run against a stylesheet and out pops a page. This is
> fine and the
>
> application uses a good dose of Model 2 goodness so it's easy to
> manage and
> extend. Unfortunately, it has been developed with it's own MVC
> framework. I
> would like to convert it to use Struts but I don't want to throw
> away the
> flexibility given by using XSLT.
>
> Whoa. Before you all shout "But Struts can use any technology for
> the view
> look at stxx" I have had a look at it and stxx has the smell of
> death around
>
> it. As far as I can tell it has been abandoned and doesn't support
> Struts
> 1.2.x (the front page hasn't been updated in well over a year).
> Further more
>
> it is fairly obvious that Struts was designed with JSP in mind and
> while it
> may work with XSLT my experience of other technologies is that this
> type of
> usage with not be easy or pleasant.
>
> You are probably wondering by now why I even want to use XSLT
> rather than
> JSP.
> The reason is simple. XSLT provides a huge amount of flexibility
> and the
> cleanest separation of the view that I have found. I admit that it
> is a
> little more work to create a stylesheet rather than a JSP but I
> feel that is
>
> worth it. I'm not 100% dead set on using XSLT. I have learnt that
> it is
> generally not a good idea to go against the grain and if the
> arguments are
> compelling enough I will switch to JSP. The problem I have with JSP
> is that
> with every release it feels like it gets closer to XSLT. A site I
> recently
> developed using JSF + JSP 2.0 (jspx) felt like the pages were
> nothing more
> than dumbed down stylesheets.
>
> My other concern is that Struts 2.x seems to be heading towards total
> integration with JSF. While I love the simplicity of JSF and the
> speed with
> which one can create a web application it is unsuitable for use on an
> ecommerce site where the users a
AW: Struts with XSLT
> -Ursprüngliche Nachricht- > Von: Michael Jouravlev [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 18. August 2005 22:11 > An: Struts Users Mailing List > Betreff: Re: Struts with XSLT > Ever heard of translets? But even if you call XSLT processor > for every request, I D-O-N'T C-A-R-E. This is not a software > problem, this is a hardware problem. And even expensive > hardware in the end of the day comes cheaper than money spent > for software workarounds. Your experience with zillions of > concurrent customers may tell you different things, I try to > respect that ;) Well, there are actually some hardware requirements, like max. amount of RAM you can use effectively on linux and so on. But, by the way, who said, the software development with XSLT/XML is faster then with JSP/JAVA-Objects? I highly doubt it :-) > > > > Keep it if it works. Don't forget that modern browsers can accept > > > XML and have built-in XSLT processor. So, you can send your > > > serialized bean data as XML with linked XSLT stylesheet > with linked > > > CSS stylesheet. > > > > Now this is an urban legend :-) Each browser support it > it's own way. > > Not to mention each version of the redmond browser supports ist own > > extensions. None of them are compatible. > > Umm, MSXML or whatever it was called, has an old XSLT implementation. > MSIE 6.0 XSLT processor is much better. And it is around for > 5 years, so customers with MSIE less than version 6 should be > simply not supported. Heck, they probably already have bought > a new car since they installed MSIE 5. Now it is time to > change oil in their computer too. I'm not even sure, that 6.0 sp1 and 6.0 sp2 have the same xslt processor. My experience with microsoft tells me, that 7.0 will differ. Not to mention mozilla and opera. And what about the coming google browser? > > > > > * Perhaps it's still a little early to say exactly how > > > Struts 2.x will > > > > turn out but will the idea of view technology independence > > > be maintained? > > > > * If Struts 2.x doesn't (essentiall) force us to use > > > something akin to > > > > JSF will XSLT still be a viable option? > > > > > > You can do it in Struts 1.x too. Instead of forwarding to > JSP page > > > just stick XML (or XML/XSLT already processed into HTML) into > > > response object and return null from an Action class. > > > Apparently, you would use ActionForm for input only with request > > > scope, and store your app data somewhere in the session or in > > > database. > > > > Actually it's better to write out the dom object (if you > have one, but > > you should, if you seriously want xslt/xml). > > I would also look into rendering with SAX, it could > probably give you > > 40-50% more performance then dom rendering. > > Did not quite get that. If you want to work directly with > DOM, then you probably need to return XML, that is what Ajax > components usually do. If you return server-side-processed > HTML, then what DOM are you talking about? Well yes, browser > will create DOM based on HTML received, but you do not alter > DOM *directly* from server. > > Oh, you did not mean browser DOM? You meant to return XML > containg app data from server-side DOM? Then how does that > correlate with your dismissal of client-side XSLT processing? I must have misunderstand what i read, mea culpa :-) But funny things, with resin, a jsp which is rendering xml is faster then xml written out by servlet, which is faster then xml written out by the action (The JSPWriter in resin is highly optimized). What i ment with DOM, was not "writing xml" somehow, but leting your business logic return dom-objects instead of "whatever-we-might-call-it" normal java objects. On the other hand, it would mean transmitting overhead on the net between webserver and business logic. But if you use an XML DB on the other hand... Ok, let's say, you have to test it out :-) > Also, try StAX. I have not run any perfomance tests myself, > but they say it is faster than SAX. At least, not slower. And > is easier to use. > Get one from Sun's JSWDP 1.6, don't use JSWDP 1.5, it > contains a serious parsing bug. Had a problem and it took a > while to realise that it had been in fact not my fault this time ;) Notched, thanx. > > Michael. > Leon > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
On 8/18/05, Leon Rosenberg <[EMAIL PROTECTED]> wrote: > > On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > > > * Should I just stop fighting city hall and abandon XSLT in > > favour of JSP? > > Yes :-) Really. We did it a year ago, and gained A LOT of performance. Not > to mention that XSLT > is much less powerful then jsp (custom tags, etc). At least as long, as you > are using an existing renderer. Examples? Custom tags, you say? Parameterised templates are at least no worse. Also, XSLT can be used with any host system, be it Java or .NET. Portability, is what this is called? ;) > > No. XML/XSLT is more flexible than JSP and has been supported > > bunch of other markup tecnhologies like XML, XHTML and XPath > > for a long time. > > And are very much slower to. Ever heard of translets? But even if you call XSLT processor for every request, I D-O-N'T C-A-R-E. This is not a software problem, this is a hardware problem. And even expensive hardware in the end of the day comes cheaper than money spent for software workarounds. Your experience with zillions of concurrent customers may tell you different things, I try to respect that ;) > > Keep it if it works. Don't forget that modern browsers can > > accept XML and have built-in XSLT processor. So, you can send > > your serialized bean data as XML with linked XSLT stylesheet > > with linked CSS stylesheet. > > Now this is an urban legend :-) Each browser support it it's own way. Not to > mention each version of the redmond browser supports ist > own extensions. None of them are compatible. Umm, MSXML or whatever it was called, has an old XSLT implementation. MSIE 6.0 XSLT processor is much better. And it is around for 5 years, so customers with MSIE less than version 6 should be simply not supported. Heck, they probably already have bought a new car since they installed MSIE 5. Now it is time to change oil in their computer too. > > > * Perhaps it's still a little early to say exactly how > > Struts 2.x will > > > turn out but will the idea of view technology independence > > be maintained? > > > * If Struts 2.x doesn't (essentiall) force us to use > > something akin to > > > JSF will XSLT still be a viable option? > > > > You can do it in Struts 1.x too. Instead of forwarding to JSP > > page just stick XML (or XML/XSLT already processed into HTML) > > into response object and return null from an Action class. > > Apparently, you would use ActionForm for input only with > > request scope, and store your app data somewhere in the > > session or in database. > > Actually it's better to write out the dom object (if you have one, but you > should, if you seriously want xslt/xml). > I would also look into rendering with SAX, it could probably give you 40-50% > more performance then dom rendering. Did not quite get that. If you want to work directly with DOM, then you probably need to return XML, that is what Ajax components usually do. If you return server-side-processed HTML, then what DOM are you talking about? Well yes, browser will create DOM based on HTML received, but you do not alter DOM *directly* from server. Oh, you did not mean browser DOM? You meant to return XML containg app data from server-side DOM? Then how does that correlate with your dismissal of client-side XSLT processing? Also, try StAX. I have not run any perfomance tests myself, but they say it is faster than SAX. At least, not slower. And is easier to use. Get one from Sun's JSWDP 1.6, don't use JSWDP 1.5, it contains a serious parsing bug. Had a problem and it took a while to realise that it had been in fact not my fault this time ;) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
On Thursday 18 August 2005 20:52, Leon Rosenberg wrote: > > I'm glad to see there is some support for XSLT. Makes me feel > > like I haven't been barking up the wrong tree for the last > > few years. Sending the XML to the client is a nice idea in > > principal but has so many problems that IMHO it's not worth > > it. Transformation server side is cheap enough now that I > > don't worry about doing it. > > Aehm... Sorry, but this isn't quite true. Server side transformation is the > most expensive part and the biggest problem of > XSLT (and client transformation doesn't work properly, as you mentioned). > > We tested relatively complex html pages, rendered with xslt against jsp. > The simpliest transformation (3K page) lasted about 50 milliseconds, a JSP > needed max 5 ms on the same machine. Complex pages (a lot of iterations and > custom/struts tags) needed about 50-70 > ms, same page with XSLT took half a second. > > And then, with XSLT DOM transformation you need TONS of RAM. I don't think > you can serve max 200-250 users per machine with XSLT, whether with JSP you > can easily go into 600-700 hundreds on a cheap intel machine (3.4Ghz > prescott with 1024 cache, 2 gig ram for example). > I agree it is a lot more expensive than JSP but you get a lot of flexibility and it is very easy to create a "transformation farm". (Un)Fortunately I don't have to deal with those sorts of loads at the moment. Graham > Regards > Leon > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
> I'm glad to see there is some support for XSLT. Makes me feel > like I haven't been barking up the wrong tree for the last > few years. Sending the XML to the client is a nice idea in > principal but has so many problems that IMHO it's not worth > it. Transformation server side is cheap enough now that I > don't worry about doing it. Aehm... Sorry, but this isn't quite true. Server side transformation is the most expensive part and the biggest problem of XSLT (and client transformation doesn't work properly, as you mentioned). We tested relatively complex html pages, rendered with xslt against jsp. The simpliest transformation (3K page) lasted about 50 milliseconds, a JSP needed max 5 ms on the same machine. Complex pages (a lot of iterations and custom/struts tags) needed about 50-70 ms, same page with XSLT took half a second. And then, with XSLT DOM transformation you need TONS of RAM. I don't think you can serve max 200-250 users per machine with XSLT, whether with JSP you can easily go into 600-700 hundreds on a cheap intel machine (3.4Ghz prescott with 1024 cache, 2 gig ram for example). Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Struts with XSLT
> -Ursprüngliche Nachricht- > Von: Michael Jouravlev [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 18. August 2005 21:33 > An: Struts Users Mailing List > Betreff: Re: Struts with XSLT > > On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > > * Should I just stop fighting city hall and abandon XSLT in > favour of JSP? Yes :-) Really. We did it a year ago, and gained A LOT of performance. Not to mention that XSLT is much less powerful then jsp (custom tags, etc). At least as long, as you are using an existing renderer. > > No. XML/XSLT is more flexible than JSP and has been supported > bunch of other markup tecnhologies like XML, XHTML and XPath > for a long time. And are very much slower to. > Keep it if it works. Don't forget that modern browsers can > accept XML and have built-in XSLT processor. So, you can send > your serialized bean data as XML with linked XSLT stylesheet > with linked CSS stylesheet. Now this is an urban legend :-) Each browser support it it's own way. Not to mention each version of the redmond browser supports ist own extensions. None of them are compatible. > > > * Perhaps it's still a little early to say exactly how > Struts 2.x will > > turn out but will the idea of view technology independence > be maintained? > > * If Struts 2.x doesn't (essentiall) force us to use > something akin to > > JSF will XSLT still be a viable option? > > You can do it in Struts 1.x too. Instead of forwarding to JSP > page just stick XML (or XML/XSLT already processed into HTML) > into response object and return null from an Action class. > Apparently, you would use ActionForm for input only with > request scope, and store your app data somewhere in the > session or in database. Actually it's better to write out the dom object (if you have one, but you should, if you seriously want xslt/xml). I would also look into rendering with SAX, it could probably give you 40-50% more performance then dom rendering. Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
On Thursday 18 August 2005 20:32, Michael Jouravlev wrote: > On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > > * Should I just stop fighting city hall and abandon XSLT in favour of > > JSP? > > No. XML/XSLT is more flexible than JSP and has been supported bunch of > other markup tecnhologies like XML, XHTML and XPath for a long time. > Keep it if it works. Don't forget that modern browsers can accept XML > and have built-in XSLT processor. So, you can send your serialized > bean data as XML with linked XSLT stylesheet with linked CSS > stylesheet. I'm glad to see there is some support for XSLT. Makes me feel like I haven't been barking up the wrong tree for the last few years. Sending the XML to the client is a nice idea in principal but has so many problems that IMHO it's not worth it. Transformation server side is cheap enough now that I don't worry about doing it. > > > * Perhaps it's still a little early to say exactly how Struts 2.x will > > turn out but will the idea of view technology independence be maintained? > > * If Struts 2.x doesn't (essentiall) force us to use something akin to > > JSF will XSLT still be a viable option? > > You can do it in Struts 1.x too. Instead of forwarding to JSP page > just stick XML (or XML/XSLT already processed into HTML) into response > object and return null from an Action class. Apparently, you would use > ActionForm for input only with request scope, and store your app data > somewhere in the session or in database. That's an interesting idea. I have a look into that. Thanks Graham > > Michael. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > * Should I just stop fighting city hall and abandon XSLT in favour of JSP? No. XML/XSLT is more flexible than JSP and has been supported bunch of other markup tecnhologies like XML, XHTML and XPath for a long time. Keep it if it works. Don't forget that modern browsers can accept XML and have built-in XSLT processor. So, you can send your serialized bean data as XML with linked XSLT stylesheet with linked CSS stylesheet. > * Perhaps it's still a little early to say exactly how Struts 2.x will turn > out but will the idea of view technology independence be maintained? > * If Struts 2.x doesn't (essentiall) force us to use something akin to JSF > will XSLT still be a viable option? You can do it in Struts 1.x too. Instead of forwarding to JSP page just stick XML (or XML/XSLT already processed into HTML) into response object and return null from an Action class. Apparently, you would use ActionForm for input only with request scope, and store your app data somewhere in the session or in database. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
I have also successfully used Struts and XSLT, Haven't had an issue. I currently use JSP to generate the dynamic top component, and then include the XSLT generated HTML in the main content area. I think that it is easier to manipulate XML with XSLT then it is to do it with JSP/Tags. -John On Aug 18, 2005, at 12:36 PM, Mark Benussi wrote: I used XSLT for all my applications to generate content as html files which Struts includes in a page template using tiles. It also allows me to search the pages as pure html content. If you are putting logic in your page you could... don't shudder, use XSLT to generate JSP's. -Original Message- From: Graham Smith [mailto:[EMAIL PROTECTED] Sent: 18 August 2005 15:13 To: user@struts.apache.org Subject: Struts with XSLT Hi folks, This isn't your usual "How do I do X?" type question so get ready. Hopefully it will fuel a good discussion. I'm fairly new to struts but have a solid grasp of Model 2 design ideas. The problem, I suppose, is that I am a lone developer (for my own company) which makes it hard to get the balanced view of the technology arena that is aquired through working with other developers. Therefore I have a couple of high level architecture questions that I am interested to hear your views on. The current application that I am working on uses XSLT to generate web pages. As you wold expect a bunch of beans (and some other objects) get converted into XML, run against a stylesheet and out pops a page. This is fine and the application uses a good dose of Model 2 goodness so it's easy to manage and extend. Unfortunately, it has been developed with it's own MVC framework. I would like to convert it to use Struts but I don't want to throw away the flexibility given by using XSLT. Whoa. Before you all shout "But Struts can use any technology for the view look at stxx" I have had a look at it and stxx has the smell of death around it. As far as I can tell it has been abandoned and doesn't support Struts 1.2.x (the front page hasn't been updated in well over a year). Further more it is fairly obvious that Struts was designed with JSP in mind and while it may work with XSLT my experience of other technologies is that this type of usage with not be easy or pleasant. You are probably wondering by now why I even want to use XSLT rather than JSP. The reason is simple. XSLT provides a huge amount of flexibility and the cleanest separation of the view that I have found. I admit that it is a little more work to create a stylesheet rather than a JSP but I feel that is worth it. I'm not 100% dead set on using XSLT. I have learnt that it is generally not a good idea to go against the grain and if the arguments are compelling enough I will switch to JSP. The problem I have with JSP is that with every release it feels like it gets closer to XSLT. A site I recently developed using JSF + JSP 2.0 (jspx) felt like the pages were nothing more than dumbed down stylesheets. My other concern is that Struts 2.x seems to be heading towards total integration with JSF. While I love the simplicity of JSF and the speed with which one can create a web application it is unsuitable for use on an ecommerce site where the users are expected to be able to bookmark pages (using a refresh is a poor hack IMHO) and, more importantly, robots can't navigate JSF sites. A combination of technologies could be used but that then multiplies the cost of development and maintenance. Finally then the questions. * Should I just stop fighting city hall and abandon XSLT in favour of JSP? * Perhaps it's still a little early to say exactly how Struts 2.x will turn out but will the idea of view technology independence be maintained? * If Struts 2.x doesn't (essentiall) force us to use something akin to JSF will XSLT still be a viable option? Thanks for reading this far. I really look forward to hearing your views. Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts with XSLT
I used XSLT for all my applications to generate content as html files which Struts includes in a page template using tiles. It also allows me to search the pages as pure html content. If you are putting logic in your page you could... don't shudder, use XSLT to generate JSP's. -Original Message- From: Graham Smith [mailto:[EMAIL PROTECTED] Sent: 18 August 2005 15:13 To: user@struts.apache.org Subject: Struts with XSLT Hi folks, This isn't your usual "How do I do X?" type question so get ready. Hopefully it will fuel a good discussion. I'm fairly new to struts but have a solid grasp of Model 2 design ideas. The problem, I suppose, is that I am a lone developer (for my own company) which makes it hard to get the balanced view of the technology arena that is aquired through working with other developers. Therefore I have a couple of high level architecture questions that I am interested to hear your views on. The current application that I am working on uses XSLT to generate web pages. As you wold expect a bunch of beans (and some other objects) get converted into XML, run against a stylesheet and out pops a page. This is fine and the application uses a good dose of Model 2 goodness so it's easy to manage and extend. Unfortunately, it has been developed with it's own MVC framework. I would like to convert it to use Struts but I don't want to throw away the flexibility given by using XSLT. Whoa. Before you all shout "But Struts can use any technology for the view look at stxx" I have had a look at it and stxx has the smell of death around it. As far as I can tell it has been abandoned and doesn't support Struts 1.2.x (the front page hasn't been updated in well over a year). Further more it is fairly obvious that Struts was designed with JSP in mind and while it may work with XSLT my experience of other technologies is that this type of usage with not be easy or pleasant. You are probably wondering by now why I even want to use XSLT rather than JSP. The reason is simple. XSLT provides a huge amount of flexibility and the cleanest separation of the view that I have found. I admit that it is a little more work to create a stylesheet rather than a JSP but I feel that is worth it. I'm not 100% dead set on using XSLT. I have learnt that it is generally not a good idea to go against the grain and if the arguments are compelling enough I will switch to JSP. The problem I have with JSP is that with every release it feels like it gets closer to XSLT. A site I recently developed using JSF + JSP 2.0 (jspx) felt like the pages were nothing more than dumbed down stylesheets. My other concern is that Struts 2.x seems to be heading towards total integration with JSF. While I love the simplicity of JSF and the speed with which one can create a web application it is unsuitable for use on an ecommerce site where the users are expected to be able to bookmark pages (using a refresh is a poor hack IMHO) and, more importantly, robots can't navigate JSF sites. A combination of technologies could be used but that then multiplies the cost of development and maintenance. Finally then the questions. * Should I just stop fighting city hall and abandon XSLT in favour of JSP? * Perhaps it's still a little early to say exactly how Struts 2.x will turn out but will the idea of view technology independence be maintained? * If Struts 2.x doesn't (essentiall) force us to use something akin to JSF will XSLT still be a viable option? Thanks for reading this far. I really look forward to hearing your views. Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > * Should I just stop fighting city hall and abandon XSLT in favour of JSP? Two thoughts strike me as I read your discussion, and the reasoning for which you like XSLT: * You seem to be concluding that XSLT and JSP are mutually exclusive. Especially with JSP 2.0, this isn't really true ... any well formed XML document is also a valid JSP2 page (in the XML syntax). Why not build your XML document templates as JSPX pages, use the Struts or JSF tags to pull in the dynamic data, and post-process with XSLT in a filter? * If you really like XSLT, you should probably look at using a framework like Cocoon, where transformation pipelines *are* the mainstream technology. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
On Thursday 18 August 2005 16:02, Don Brown wrote: > Hmm...smell of death for stxx might be a bit harsh :) Yeah ok, it was a bit harsh - sorry. I'll take another look. It's sometimes hard to know when a project is on it's last legs though. A message from one of the core developers within an hour is a pretty good assurance that it's alive and kicking though :o) > While it true I > need to get a release out that better supports 1.2, I've been using it > in production for over a year without problems, and would recommend > you take another look. You, of course, are welcome to get involved, > submit patches, even join the project. I have been looking for a project to work on in my spare time (just a mo while I pick myself up off the floor from laughing at the idea of having spare time). If I decide to stick with XSLT I'll probably contribute. > > Regarding Struts and XSLT, I've had a good experience ditching JSP. > XSLT is powerful and fun even once you get the hang of it. Now to > your questions... > > On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > > > > * Should I just stop fighting city hall and abandon XSLT in favour of > > JSP? * Perhaps it's still a little early to say exactly how Struts 2.x > > will turn out but will the idea of view technology independence be > > maintained? > > Of course there isn't a Struts 2.0, yet anyways, but Struts Shale is > already exploring an alternate view, HTML templates, for JSF and JSF > itself is designed to be view independent, however, I haven't heard of > any view handlers that use XSLT yet. I certainly couldn't call myself a JSF expert but I have, I believe, had enough experience of it to realise that the intended goal writing one page and using alternative renders for different devices doesn't really work. While it's great that you can, in theory, install other renders for the JSF tags it rapidly becomes almost impossible to maintain. I can't believe, for instance, that it would be possible to develop a page that would look good in both a standard browser and a mobile phone. This is at the heart of my interest in XSLT. It removes the whole plug-in render mess that JSF seems to have got itself into. On the flip side the reason I am interested in using JSPs is that I only need to develop for fully featured browsers. Thanks for the feedback, Graham > Another project we are working > on in the sandbox, Struts Ti, already has support for XSLT. > > Hope that helps, > > Don > > > * If Struts 2.x doesn't (essentiall) force us to use something akin to > > JSF will XSLT still be a viable option? > > > > Thanks for reading this far. I really look forward to hearing your views. > > > > Graham > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts with XSLT
Hmm...smell of death for stxx might be a bit harsh :) While it true I need to get a release out that better supports 1.2, I've been using it in production for over a year without problems, and would recommend you take another look. You, of course, are welcome to get involved, submit patches, even join the project. Regarding Struts and XSLT, I've had a good experience ditching JSP. XSLT is powerful and fun even once you get the hang of it. Now to your questions... On 8/18/05, Graham Smith <[EMAIL PROTECTED]> wrote: > * Should I just stop fighting city hall and abandon XSLT in favour of JSP? > * Perhaps it's still a little early to say exactly how Struts 2.x will turn > out but will the idea of view technology independence be maintained? Of course there isn't a Struts 2.0, yet anyways, but Struts Shale is already exploring an alternate view, HTML templates, for JSF and JSF itself is designed to be view independent, however, I haven't heard of any view handlers that use XSLT yet. Another project we are working on in the sandbox, Struts Ti, already has support for XSLT. Hope that helps, Don > * If Struts 2.x doesn't (essentiall) force us to use something akin to JSF > will XSLT still be a viable option? > > Thanks for reading this far. I really look forward to hearing your views. > > Graham > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts with XSLT
Hi folks, This isn't your usual "How do I do X?" type question so get ready. Hopefully it will fuel a good discussion. I'm fairly new to struts but have a solid grasp of Model 2 design ideas. The problem, I suppose, is that I am a lone developer (for my own company) which makes it hard to get the balanced view of the technology arena that is aquired through working with other developers. Therefore I have a couple of high level architecture questions that I am interested to hear your views on. The current application that I am working on uses XSLT to generate web pages. As you wold expect a bunch of beans (and some other objects) get converted into XML, run against a stylesheet and out pops a page. This is fine and the application uses a good dose of Model 2 goodness so it's easy to manage and extend. Unfortunately, it has been developed with it's own MVC framework. I would like to convert it to use Struts but I don't want to throw away the flexibility given by using XSLT. Whoa. Before you all shout "But Struts can use any technology for the view look at stxx" I have had a look at it and stxx has the smell of death around it. As far as I can tell it has been abandoned and doesn't support Struts 1.2.x (the front page hasn't been updated in well over a year). Further more it is fairly obvious that Struts was designed with JSP in mind and while it may work with XSLT my experience of other technologies is that this type of usage with not be easy or pleasant. You are probably wondering by now why I even want to use XSLT rather than JSP. The reason is simple. XSLT provides a huge amount of flexibility and the cleanest separation of the view that I have found. I admit that it is a little more work to create a stylesheet rather than a JSP but I feel that is worth it. I'm not 100% dead set on using XSLT. I have learnt that it is generally not a good idea to go against the grain and if the arguments are compelling enough I will switch to JSP. The problem I have with JSP is that with every release it feels like it gets closer to XSLT. A site I recently developed using JSF + JSP 2.0 (jspx) felt like the pages were nothing more than dumbed down stylesheets. My other concern is that Struts 2.x seems to be heading towards total integration with JSF. While I love the simplicity of JSF and the speed with which one can create a web application it is unsuitable for use on an ecommerce site where the users are expected to be able to bookmark pages (using a refresh is a poor hack IMHO) and, more importantly, robots can't navigate JSF sites. A combination of technologies could be used but that then multiplies the cost of development and maintenance. Finally then the questions. * Should I just stop fighting city hall and abandon XSLT in favour of JSP? * Perhaps it's still a little early to say exactly how Struts 2.x will turn out but will the idea of view technology independence be maintained? * If Struts 2.x doesn't (essentiall) force us to use something akin to JSF will XSLT still be a viable option? Thanks for reading this far. I really look forward to hearing your views. Graham - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts with XSLT
It seems that it is rather easy to use XSLT with Struts. Two plug-in are available StrutsCX and stxx I will wish to have returns on their use: - which is the easiest tool for a XSLT beginner ? - is it possible to use simultaneously JSP and XSLT with the two plug-in ? Thanks a lot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
