You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Graham Smith <gr...@crazysquirrel.com> on 2005/08/18 16:13:06 UTC
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Testing Struts With JUnit
Posted by Luiz Godoy <oc...@yahoo.com>.
I´m trying to test the action below :
public class FamiliaDNCAction extends BasicAction {
public ActionForward unspecified(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request, HttpServletResponse response) throws BusinessException {
Set msgs = new HashSet();
return loadPage(actionMapping,actionForm,request,response);
}
public ActionForward loadPage(ActionMapping actionMapping, ActionForm actionForm, HttpServletRequest request, HttpServletResponse response) throws BusinessException {
HttpSession session=request.getSession();
CadastroFamiliaDNC cad = new CadastroFamiliaDNC();
FamiliaDNCForm form = (FamiliaDNCForm) actionForm;
List dados = cad.findByCodigoDependencia(form.getCodDependencia().intValue());
session.setAttribute("dadosdnc",dados);
return actionMapping.findForward("inicial");
}
}
The parameters for the action are
FamiliaDNC.do -- calls the class
ev --> the parameter for the method, when not set calls "unspecified" method
public class TestFamiliaDNCAction extends MockStrutsTestCase{
FamiliaDNCAction fdnca;
public TestFamiliaDNCAction(String nomeDoTeste) {
super(nomeDoTeste);
}
public void setUp() throws Exception {
super.setUp();
fdnca = new FamiliaDNCAction();
}
public void testLoadPage() {
addRequestParameter("codDependencia","1");
addRequestParameter("codTipoFamiliaInsumo","0");
addRequestParameter("ev","unspecified");
setRequestPathInfo("/corporativo/cadastro/cadFamiliaDNC");
actionPerform();
verifyForward("inicial");
verifyForwardPath("/corporativo/cadastro/corp_cad_familia_dnc.jsp");
verifyNoActionErrors();
}
I´m getting nullPointerException, when i try to test it. I´m not sure
witch parameters i add to the request for example in the action form i have:
<form name="form2" method="post" action="./cadFamiliaDNC.do">
<input type="hidden" name="codFamiliaDNC" value="">
<input type="hidden" name="codTipoFamiliaInsumo">
<input type="hidden" name="codDependencia">
.....
/form>
My question is, witch parameters do i put in the addRequestParameter("?","?"); ?
any clue ?
Thanks in advance
regards..
Luiz Octavio Godoy
Desenvolvimento de Sistemas
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
AW: Struts with XSLT
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Michael Jouravlev [mailto:jmikus@gmail.com]
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/18/05, Leon Rosenberg <st...@anotheria.net> wrote:
> > On 8/18/05, Graham Smith <gr...@crazysquirrel.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Graham Smith <gr...@crazysquirrel.com>.
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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Leon Rosenberg <st...@anotheria.net>.
> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Graham Smith <gr...@crazysquirrel.com>.
On Thursday 18 August 2005 20:32, Michael Jouravlev wrote:
> On 8/18/05, Graham Smith <gr...@crazysquirrel.com> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
AW: Struts with XSLT
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Michael Jouravlev [mailto:jmikus@gmail.com]
> Gesendet: Donnerstag, 18. August 2005 21:33
> An: Struts Users Mailing List
> Betreff: Re: Struts with XSLT
>
> On 8/18/05, Graham Smith <gr...@crazysquirrel.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Michael Jouravlev <jm...@gmail.com>.
On 8/18/05, Graham Smith <gr...@crazysquirrel.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/18/05, Graham Smith <gr...@crazysquirrel.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Peter Maas <pe...@noterik.nl>.
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 <gr...@crazysquirrel.com> wrote:
> > <snip />
> >
> > > * 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: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Graham Smith <gr...@crazysquirrel.com>.
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 <gr...@crazysquirrel.com> wrote:
> <snip />
>
> > * 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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by Don Brown <do...@gmail.com>.
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 <gr...@crazysquirrel.com> wrote:
<snip />
> * 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts with XSLT
Posted by John Martyniak <jm...@ix.netcom.com>.
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:graham@crazysquirrel.com]
> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Struts with XSLT
Posted by Mark Benussi <ma...@hotmail.com>.
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:graham@crazysquirrel.com]
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org