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]
