You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Harish Krishnaswamy <wh...@yahoo.com> on 2003/04/07 02:40:30 UTC
JSP/taglibs vs. XMLC
Taglibs, the answer to separation of roles problem, seems like a variant of SAX solution in the
sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When JSP is nothing but XML
behind the scenes, why not use SAX/DOM to manipulate the viewers like XMLC does? That way you
force the logic out of web pages and there is clear separation of visual design and content
generation. Sounds like a no brainer to me, I don't understand why SUN would put more efforts into
JSP. Am I missing something?
-Harish
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
used with a tile
Posted by Nicolas De Loof <ni...@cgey.com>.
Hi,
in the index.jsp page of my app (welcome file) I would like to forward to a tile, using :
<logic:forward name="index" />
In struts-config.xml I have set this global forward :
<global-forwards>
<forward name="index" path="tiles:index"/>
</global-forwards>
In tiles-def.xml I have defined the tile "tile:index"
It doesn't work as server is looking for "/[app context]/tiles:index"
If I define a forward action "/index" that forwards to my tile, and change forward to <forward name="index"
path="/index.do"/>, it works.
Did I miss something ? Doesn't logic:forward tag support tiles ?
Nico.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Jack Zakarian <jz...@welchpartners.com>.
Hi Sasha,
It looks interesting but the license seems to restrict what you can do
with it. For example here is a portion of the license
You may not:
.use the programs for any commercial or production purposes, or use the
programs for any purpose except the development and prototyping of your
applications;
Jack
-----Original Message-----
From: Sasha Bilton [mailto:sasha.bilton@phase12.com]
Sent: Monday, April 07, 2003 12:34 PM
To: Struts Users Mailing List
Subject: Re: JSP/taglibs vs. XMLC
Brandon Goodin wrote:
> No matter what we do we are dealing with complexities. Whether it be
xmlc,
> velocity or jsp. Even xmlc requires that the designer has a
fundamental
> understanding of xml/html/xhtml/etc... If you know markup then you
could
> know if/then/else. Besides, I think we give designers to little credit
for
> their intelligence level.
If you need to rendering a lot of XML into a website or have a DB 2 XML
needs, have a look at o:xml (www.o-xml.org) we've used very successfully
for a couple of projects, that also used Struts.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: JSP/taglibs vs. XMLC
Posted by Sasha Bilton <sa...@phase12.com>.
Brandon Goodin wrote:
> No matter what we do we are dealing with complexities. Whether it be xmlc,
> velocity or jsp. Even xmlc requires that the designer has a fundamental
> understanding of xml/html/xhtml/etc... If you know markup then you could
> know if/then/else. Besides, I think we give designers to little credit for
> their intelligence level.
If you need to rendering a lot of XML into a website or have a DB 2 XML
needs, have a look at o:xml (www.o-xml.org) we've used very successfully
for a couple of projects, that also used Struts.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Andrew Hill <an...@gridnode.com>.
Yep. There is a fair bit of programmer overhead initially to using DOM -
even with XMLC (though if your using a framework designed for it like
Barracuda much of that would be done for you). Also even when using XMLC,
there will be more memory use to represent the DOM in memory than you would
get with JSP - which is essentially stream based. This is the sort of thing
one needs to consider when architecting the app. I wouldnt suggest you use
DOM for an amazon.com type site, but for a complex application where the
actual number of simultaneous users isnt vast but the UI requirements are
complex, it may well be a different matter..
The big problem most people who advocate DOM based approaches have with JSP
is that one is mixing the layout with the code to render the dynamic bits.
Since clients tend not to be able to look at a particular user interface for
more than about 5 minutes without deciding they want the layout and colour
scheme etc... to change completely that also means you have to reorganise
your rendering code everytime as its all in together in the same file. When
the html designers dont/wont know JSP this means that they will give you the
html and you have to spend forever converting it back into a JSP - mind you
its a similar deal with XMLC/DOM when the designers dont bother to preserve
the id attributes and such like when they bang together a new mockup...
The stage I was hoping to get to in my app was where users (or technical
support staff) could customise the screens for the app from within the app
(by uploading xhtml files) while its running (ie: user configurable forms).
Of course thats still a dream, but I suspect it will be a lot easier to
acheive using a DOM based approach. I suppose they could upload JSPs but
that gives them far more power than Im prepared to let them have given that
a JSP is code and not merely a layout...
-----Original Message-----
From: Brandon Goodin [mailto:mail@phase.ws]
Sent: Tuesday, 8 April 2003 00:06
To: Struts Users Mailing List
Subject: RE: JSP/taglibs vs. XMLC
That is nice on paper and with no view of the impact to the developer....
XMLC has a bit of a bite when it comes to preparing the data for the view
and writing the proper rendering classes for the proper view. To me that is
more work than I care to do in order to produce a view.
I like the more generic approach of working with POJOs in a page (PULL).
Again, that is why I would use velocity before I would use xmlc. The
development cycle is quicker with jsp and velocity and any person who
graduated "Intro to Algebra" could use either one (assuming you are using
jstl or pure taglibs in jsp).
No matter what we do we are dealing with complexities. Whether it be xmlc,
velocity or jsp. Even xmlc requires that the designer has a fundamental
understanding of xml/html/xhtml/etc... If you know markup then you could
know if/then/else. Besides, I think we give designers to little credit for
their intelligence level.
To be fair... following is a great article on xmlc and why jsp sucks ;-):
http://www.theserverside.com/resources/article.jsp?l=XMLCvsJSP
In the end I think jsp, velocity and xmlc are all great technologies. It's
all in the need. There is no silver bullet.
BTW
Anyways, that is my .02. I won't comment on this subject anymore.
Brandon Goodin
Phase Web and Multimedia
PO Box 85
Whitefish MT 59937
P (406) 862-2245
F (406) 862-0354
mail@phase.ws
http://www.phase.ws
-----Original Message-----
From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
Sent: Monday, April 07, 2003 9:10 AM
To: Struts Users Mailing List
Subject: RE: JSP/taglibs vs. XMLC
If performance is the concern, I think this where XMLC would take over
becuase you have the pages
pre-compiled like JSPs and it does not have the other drawbacks that JSPs
do. With XMLC you don't
have to deal with the model objects in the pages and so you don't need the
if/then/while
behaviour. All this for what - becuase it is not easy to find an intelligent
designer :)
-Harish
--- Brandon Goodin <ma...@phase.ws> wrote:
> Rendering DOMS? Sounds expensive on memory and processor cycles. How would
> that scale on a production site with moderate users in a shared hosting
> environment? What are the real +/- regarding dom rendering vs. jsp.
Constant
> page rendering with dom objects vs. compiled page rendering... being able
to
> transform a page with xslt vs. most site never need to use xslt.
>
> Personally, I am a jsp guy because it is right for what I am doing. If I
> needed the ability to tranform my pages I WOULD use xml. But, I think I
> would use velocity because it is faster, simpler and even more flexible
for
> page tweaking on a live site than dom rendering.
>
> JSP can be set up as xml compliant. So if you wanted to pass the jsp
results
> through a transformation... you could (Not that I would). Also, I think a
> model 2 architecture is possible. But, you still must deal with a way to
> represent the model objects in your page and render/iterate/condition the
> data in the view. So, removing if/then/while behavior is pretty difficult
to
> remove from your page unless what you are doing is very simplistic.
Finding
> intelligent designers is another option :-D
>
> Brandon Goodin
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, April 07, 2003 1:19 AM
> To: Struts Users Mailing List
> Subject: RE: JSP/taglibs vs. XMLC
>
>
> Cool, thanks for sharing Andrew!
>
>
> --- Andrew Hill <an...@gridnode.com> wrote:
> > Ive been validating in my actions as I find doing it in the actionForm
> > inconvienient.
> >
> > My app has metainfo on which fields are mandatory etc... however the
> actual
> > validation process is still the good old process of checking if whats in
> the
> > actionform is valid, and if not saving an an appropriate actionError for
> > that field.
> >
> > For rendering the error, my field rendering code will check to see if
the
> > field has an associated actionError, and if so will render the i18ned
text
> > for the error into an element in the dom with the id attribute
"bob_error"
> > (where the fieldname is "bob").
> >
> > -----Original Message-----
> > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > Sent: Monday, 7 April 2003 14:03
> > To: Struts User
> > Subject: RE: JSP/taglibs vs. XMLC
> >
> >
> > What did you do for validations? Can you share a little bit about that?
> > Thanks!
> >
> > -Harish
> >
> >
> > --- Andrew Hill <an...@gridnode.com> wrote:
> > > I dont think your missing anything. JSPs mingling of layout with the
> code
> > to
> > > render the dynamic bits is truly diabolical.
> > >
> > > I am using the DOM API for my view rendering and it is very powerful
and
> > > flexible. hehe try using the decorator pattern on an already prepared
> JSP
> > > page ;-)
> > >
> > > I didnt end up using XMLC (didnt like the way it makes you generate
> class
> > > files to build your doms) but just use Xerces and standard DOM stuff.
> > >
> > > My code for rendering things like field values is flexible enough to
> cope
> > > with different types of elements, so I can play around with the actual
> > > layout xhtml files without having to recompile. If im in the process
of
> > > trying to making something look nice, Ill often just go and play with
> the
> > > xhtml files directly in the tomcat webapp directly until the screen
> looks
> > > nice, and then copy the source back into my source directory.
> > >
> > > There is nothing to stop you using XMLC with struts. Instead of
> forwarding
> > > to a jsp you forward to something that will use the appropriate xmlc
> class
> > > to give you a dom, and run the code to write the appropriate values
> (such
> > as
> > > actionform properties) into the dom, before serializing the results to
> the
> > > output.
> > >
> > > -----Original Message-----
> > > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > > Sent: Monday, 7 April 2003 08:41
> > > To: Struts User
> > > Subject: JSP/taglibs vs. XMLC
> > >
> > >
> > > Taglibs, the answer to separation of roles problem, seems like a
variant
> > of
> > > SAX solution in the
> > > sense that Tag Handlers for JSP resemble the SAX Handlers for XML.
When
> > JSP
> > > is nothing but XML
> > > behind the scenes, why not use SAX/DOM to manipulate the viewers like
> XMLC
> > > does? That way you
> > > force the logic out of web pages and there is clear separation of
visual
> > > design and content
> > > generation. Sounds like a no brainer to me, I don't understand why SUN
> > would
> > > put more efforts into
> > > JSP. Am I missing something?
> > >
> > > -Harish
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - File online, calculators, forms, and more
> > > http://tax.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Brandon Goodin <ma...@phase.ws>.
That is nice on paper and with no view of the impact to the developer....
XMLC has a bit of a bite when it comes to preparing the data for the view
and writing the proper rendering classes for the proper view. To me that is
more work than I care to do in order to produce a view.
I like the more generic approach of working with POJOs in a page (PULL).
Again, that is why I would use velocity before I would use xmlc. The
development cycle is quicker with jsp and velocity and any person who
graduated "Intro to Algebra" could use either one (assuming you are using
jstl or pure taglibs in jsp).
No matter what we do we are dealing with complexities. Whether it be xmlc,
velocity or jsp. Even xmlc requires that the designer has a fundamental
understanding of xml/html/xhtml/etc... If you know markup then you could
know if/then/else. Besides, I think we give designers to little credit for
their intelligence level.
To be fair... following is a great article on xmlc and why jsp sucks ;-):
http://www.theserverside.com/resources/article.jsp?l=XMLCvsJSP
In the end I think jsp, velocity and xmlc are all great technologies. It's
all in the need. There is no silver bullet.
BTW
Anyways, that is my .02. I won't comment on this subject anymore.
Brandon Goodin
Phase Web and Multimedia
PO Box 85
Whitefish MT 59937
P (406) 862-2245
F (406) 862-0354
mail@phase.ws
http://www.phase.ws
-----Original Message-----
From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
Sent: Monday, April 07, 2003 9:10 AM
To: Struts Users Mailing List
Subject: RE: JSP/taglibs vs. XMLC
If performance is the concern, I think this where XMLC would take over
becuase you have the pages
pre-compiled like JSPs and it does not have the other drawbacks that JSPs
do. With XMLC you don't
have to deal with the model objects in the pages and so you don't need the
if/then/while
behaviour. All this for what - becuase it is not easy to find an intelligent
designer :)
-Harish
--- Brandon Goodin <ma...@phase.ws> wrote:
> Rendering DOMS? Sounds expensive on memory and processor cycles. How would
> that scale on a production site with moderate users in a shared hosting
> environment? What are the real +/- regarding dom rendering vs. jsp.
Constant
> page rendering with dom objects vs. compiled page rendering... being able
to
> transform a page with xslt vs. most site never need to use xslt.
>
> Personally, I am a jsp guy because it is right for what I am doing. If I
> needed the ability to tranform my pages I WOULD use xml. But, I think I
> would use velocity because it is faster, simpler and even more flexible
for
> page tweaking on a live site than dom rendering.
>
> JSP can be set up as xml compliant. So if you wanted to pass the jsp
results
> through a transformation... you could (Not that I would). Also, I think a
> model 2 architecture is possible. But, you still must deal with a way to
> represent the model objects in your page and render/iterate/condition the
> data in the view. So, removing if/then/while behavior is pretty difficult
to
> remove from your page unless what you are doing is very simplistic.
Finding
> intelligent designers is another option :-D
>
> Brandon Goodin
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, April 07, 2003 1:19 AM
> To: Struts Users Mailing List
> Subject: RE: JSP/taglibs vs. XMLC
>
>
> Cool, thanks for sharing Andrew!
>
>
> --- Andrew Hill <an...@gridnode.com> wrote:
> > Ive been validating in my actions as I find doing it in the actionForm
> > inconvienient.
> >
> > My app has metainfo on which fields are mandatory etc... however the
> actual
> > validation process is still the good old process of checking if whats in
> the
> > actionform is valid, and if not saving an an appropriate actionError for
> > that field.
> >
> > For rendering the error, my field rendering code will check to see if
the
> > field has an associated actionError, and if so will render the i18ned
text
> > for the error into an element in the dom with the id attribute
"bob_error"
> > (where the fieldname is "bob").
> >
> > -----Original Message-----
> > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > Sent: Monday, 7 April 2003 14:03
> > To: Struts User
> > Subject: RE: JSP/taglibs vs. XMLC
> >
> >
> > What did you do for validations? Can you share a little bit about that?
> > Thanks!
> >
> > -Harish
> >
> >
> > --- Andrew Hill <an...@gridnode.com> wrote:
> > > I dont think your missing anything. JSPs mingling of layout with the
> code
> > to
> > > render the dynamic bits is truly diabolical.
> > >
> > > I am using the DOM API for my view rendering and it is very powerful
and
> > > flexible. hehe try using the decorator pattern on an already prepared
> JSP
> > > page ;-)
> > >
> > > I didnt end up using XMLC (didnt like the way it makes you generate
> class
> > > files to build your doms) but just use Xerces and standard DOM stuff.
> > >
> > > My code for rendering things like field values is flexible enough to
> cope
> > > with different types of elements, so I can play around with the actual
> > > layout xhtml files without having to recompile. If im in the process
of
> > > trying to making something look nice, Ill often just go and play with
> the
> > > xhtml files directly in the tomcat webapp directly until the screen
> looks
> > > nice, and then copy the source back into my source directory.
> > >
> > > There is nothing to stop you using XMLC with struts. Instead of
> forwarding
> > > to a jsp you forward to something that will use the appropriate xmlc
> class
> > > to give you a dom, and run the code to write the appropriate values
> (such
> > as
> > > actionform properties) into the dom, before serializing the results to
> the
> > > output.
> > >
> > > -----Original Message-----
> > > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > > Sent: Monday, 7 April 2003 08:41
> > > To: Struts User
> > > Subject: JSP/taglibs vs. XMLC
> > >
> > >
> > > Taglibs, the answer to separation of roles problem, seems like a
variant
> > of
> > > SAX solution in the
> > > sense that Tag Handlers for JSP resemble the SAX Handlers for XML.
When
> > JSP
> > > is nothing but XML
> > > behind the scenes, why not use SAX/DOM to manipulate the viewers like
> XMLC
> > > does? That way you
> > > force the logic out of web pages and there is clear separation of
visual
> > > design and content
> > > generation. Sounds like a no brainer to me, I don't understand why SUN
> > would
> > > put more efforts into
> > > JSP. Am I missing something?
> > >
> > > -Harish
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - File online, calculators, forms, and more
> > > http://tax.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Harish Krishnaswamy <wh...@yahoo.com>.
If performance is the concern, I think this where XMLC would take over becuase you have the pages
pre-compiled like JSPs and it does not have the other drawbacks that JSPs do. With XMLC you don't
have to deal with the model objects in the pages and so you don't need the if/then/while
behaviour. All this for what - becuase it is not easy to find an intelligent designer :)
-Harish
--- Brandon Goodin <ma...@phase.ws> wrote:
> Rendering DOMS? Sounds expensive on memory and processor cycles. How would
> that scale on a production site with moderate users in a shared hosting
> environment? What are the real +/- regarding dom rendering vs. jsp. Constant
> page rendering with dom objects vs. compiled page rendering... being able to
> transform a page with xslt vs. most site never need to use xslt.
>
> Personally, I am a jsp guy because it is right for what I am doing. If I
> needed the ability to tranform my pages I WOULD use xml. But, I think I
> would use velocity because it is faster, simpler and even more flexible for
> page tweaking on a live site than dom rendering.
>
> JSP can be set up as xml compliant. So if you wanted to pass the jsp results
> through a transformation... you could (Not that I would). Also, I think a
> model 2 architecture is possible. But, you still must deal with a way to
> represent the model objects in your page and render/iterate/condition the
> data in the view. So, removing if/then/while behavior is pretty difficult to
> remove from your page unless what you are doing is very simplistic. Finding
> intelligent designers is another option :-D
>
> Brandon Goodin
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, April 07, 2003 1:19 AM
> To: Struts Users Mailing List
> Subject: RE: JSP/taglibs vs. XMLC
>
>
> Cool, thanks for sharing Andrew!
>
>
> --- Andrew Hill <an...@gridnode.com> wrote:
> > Ive been validating in my actions as I find doing it in the actionForm
> > inconvienient.
> >
> > My app has metainfo on which fields are mandatory etc... however the
> actual
> > validation process is still the good old process of checking if whats in
> the
> > actionform is valid, and if not saving an an appropriate actionError for
> > that field.
> >
> > For rendering the error, my field rendering code will check to see if the
> > field has an associated actionError, and if so will render the i18ned text
> > for the error into an element in the dom with the id attribute "bob_error"
> > (where the fieldname is "bob").
> >
> > -----Original Message-----
> > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > Sent: Monday, 7 April 2003 14:03
> > To: Struts User
> > Subject: RE: JSP/taglibs vs. XMLC
> >
> >
> > What did you do for validations? Can you share a little bit about that?
> > Thanks!
> >
> > -Harish
> >
> >
> > --- Andrew Hill <an...@gridnode.com> wrote:
> > > I dont think your missing anything. JSPs mingling of layout with the
> code
> > to
> > > render the dynamic bits is truly diabolical.
> > >
> > > I am using the DOM API for my view rendering and it is very powerful and
> > > flexible. hehe try using the decorator pattern on an already prepared
> JSP
> > > page ;-)
> > >
> > > I didnt end up using XMLC (didnt like the way it makes you generate
> class
> > > files to build your doms) but just use Xerces and standard DOM stuff.
> > >
> > > My code for rendering things like field values is flexible enough to
> cope
> > > with different types of elements, so I can play around with the actual
> > > layout xhtml files without having to recompile. If im in the process of
> > > trying to making something look nice, Ill often just go and play with
> the
> > > xhtml files directly in the tomcat webapp directly until the screen
> looks
> > > nice, and then copy the source back into my source directory.
> > >
> > > There is nothing to stop you using XMLC with struts. Instead of
> forwarding
> > > to a jsp you forward to something that will use the appropriate xmlc
> class
> > > to give you a dom, and run the code to write the appropriate values
> (such
> > as
> > > actionform properties) into the dom, before serializing the results to
> the
> > > output.
> > >
> > > -----Original Message-----
> > > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > > Sent: Monday, 7 April 2003 08:41
> > > To: Struts User
> > > Subject: JSP/taglibs vs. XMLC
> > >
> > >
> > > Taglibs, the answer to separation of roles problem, seems like a variant
> > of
> > > SAX solution in the
> > > sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When
> > JSP
> > > is nothing but XML
> > > behind the scenes, why not use SAX/DOM to manipulate the viewers like
> XMLC
> > > does? That way you
> > > force the logic out of web pages and there is clear separation of visual
> > > design and content
> > > generation. Sounds like a no brainer to me, I don't understand why SUN
> > would
> > > put more efforts into
> > > JSP. Am I missing something?
> > >
> > > -Harish
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - File online, calculators, forms, and more
> > > http://tax.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by "Daniel H. F. e Silva" <dh...@yahoo.com>.
Hi all,
Adding more fuel to this discussion, i think that you are talking about something like
Cocoon. What about it?
Best regards,
Daniel.
--- Brandon Goodin <ma...@phase.ws> wrote:
> Rendering DOMS? Sounds expensive on memory and processor cycles. How would
> that scale on a production site with moderate users in a shared hosting
> environment? What are the real +/- regarding dom rendering vs. jsp. Constant
> page rendering with dom objects vs. compiled page rendering... being able to
> transform a page with xslt vs. most site never need to use xslt.
>
> Personally, I am a jsp guy because it is right for what I am doing. If I
> needed the ability to tranform my pages I WOULD use xml. But, I think I
> would use velocity because it is faster, simpler and even more flexible for
> page tweaking on a live site than dom rendering.
>
> JSP can be set up as xml compliant. So if you wanted to pass the jsp results
> through a transformation... you could (Not that I would). Also, I think a
> model 2 architecture is possible. But, you still must deal with a way to
> represent the model objects in your page and render/iterate/condition the
> data in the view. So, removing if/then/while behavior is pretty difficult to
> remove from your page unless what you are doing is very simplistic. Finding
> intelligent designers is another option :-D
>
> Brandon Goodin
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, April 07, 2003 1:19 AM
> To: Struts Users Mailing List
> Subject: RE: JSP/taglibs vs. XMLC
>
>
> Cool, thanks for sharing Andrew!
>
>
> --- Andrew Hill <an...@gridnode.com> wrote:
> > Ive been validating in my actions as I find doing it in the actionForm
> > inconvienient.
> >
> > My app has metainfo on which fields are mandatory etc... however the
> actual
> > validation process is still the good old process of checking if whats in
> the
> > actionform is valid, and if not saving an an appropriate actionError for
> > that field.
> >
> > For rendering the error, my field rendering code will check to see if the
> > field has an associated actionError, and if so will render the i18ned text
> > for the error into an element in the dom with the id attribute "bob_error"
> > (where the fieldname is "bob").
> >
> > -----Original Message-----
> > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > Sent: Monday, 7 April 2003 14:03
> > To: Struts User
> > Subject: RE: JSP/taglibs vs. XMLC
> >
> >
> > What did you do for validations? Can you share a little bit about that?
> > Thanks!
> >
> > -Harish
> >
> >
> > --- Andrew Hill <an...@gridnode.com> wrote:
> > > I dont think your missing anything. JSPs mingling of layout with the
> code
> > to
> > > render the dynamic bits is truly diabolical.
> > >
> > > I am using the DOM API for my view rendering and it is very powerful and
> > > flexible. hehe try using the decorator pattern on an already prepared
> JSP
> > > page ;-)
> > >
> > > I didnt end up using XMLC (didnt like the way it makes you generate
> class
> > > files to build your doms) but just use Xerces and standard DOM stuff.
> > >
> > > My code for rendering things like field values is flexible enough to
> cope
> > > with different types of elements, so I can play around with the actual
> > > layout xhtml files without having to recompile. If im in the process of
> > > trying to making something look nice, Ill often just go and play with
> the
> > > xhtml files directly in the tomcat webapp directly until the screen
> looks
> > > nice, and then copy the source back into my source directory.
> > >
> > > There is nothing to stop you using XMLC with struts. Instead of
> forwarding
> > > to a jsp you forward to something that will use the appropriate xmlc
> class
> > > to give you a dom, and run the code to write the appropriate values
> (such
> > as
> > > actionform properties) into the dom, before serializing the results to
> the
> > > output.
> > >
> > > -----Original Message-----
> > > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > > Sent: Monday, 7 April 2003 08:41
> > > To: Struts User
> > > Subject: JSP/taglibs vs. XMLC
> > >
> > >
> > > Taglibs, the answer to separation of roles problem, seems like a variant
> > of
> > > SAX solution in the
> > > sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When
> > JSP
> > > is nothing but XML
> > > behind the scenes, why not use SAX/DOM to manipulate the viewers like
> XMLC
> > > does? That way you
> > > force the logic out of web pages and there is clear separation of visual
> > > design and content
> > > generation. Sounds like a no brainer to me, I don't understand why SUN
> > would
> > > put more efforts into
> > > JSP. Am I missing something?
> > >
> > > -Harish
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - File online, calculators, forms, and more
> > > http://tax.yahoo.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Brandon Goodin <ma...@phase.ws>.
Rendering DOMS? Sounds expensive on memory and processor cycles. How would
that scale on a production site with moderate users in a shared hosting
environment? What are the real +/- regarding dom rendering vs. jsp. Constant
page rendering with dom objects vs. compiled page rendering... being able to
transform a page with xslt vs. most site never need to use xslt.
Personally, I am a jsp guy because it is right for what I am doing. If I
needed the ability to tranform my pages I WOULD use xml. But, I think I
would use velocity because it is faster, simpler and even more flexible for
page tweaking on a live site than dom rendering.
JSP can be set up as xml compliant. So if you wanted to pass the jsp results
through a transformation... you could (Not that I would). Also, I think a
model 2 architecture is possible. But, you still must deal with a way to
represent the model objects in your page and render/iterate/condition the
data in the view. So, removing if/then/while behavior is pretty difficult to
remove from your page unless what you are doing is very simplistic. Finding
intelligent designers is another option :-D
Brandon Goodin
-----Original Message-----
From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
Sent: Monday, April 07, 2003 1:19 AM
To: Struts Users Mailing List
Subject: RE: JSP/taglibs vs. XMLC
Cool, thanks for sharing Andrew!
--- Andrew Hill <an...@gridnode.com> wrote:
> Ive been validating in my actions as I find doing it in the actionForm
> inconvienient.
>
> My app has metainfo on which fields are mandatory etc... however the
actual
> validation process is still the good old process of checking if whats in
the
> actionform is valid, and if not saving an an appropriate actionError for
> that field.
>
> For rendering the error, my field rendering code will check to see if the
> field has an associated actionError, and if so will render the i18ned text
> for the error into an element in the dom with the id attribute "bob_error"
> (where the fieldname is "bob").
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, 7 April 2003 14:03
> To: Struts User
> Subject: RE: JSP/taglibs vs. XMLC
>
>
> What did you do for validations? Can you share a little bit about that?
> Thanks!
>
> -Harish
>
>
> --- Andrew Hill <an...@gridnode.com> wrote:
> > I dont think your missing anything. JSPs mingling of layout with the
code
> to
> > render the dynamic bits is truly diabolical.
> >
> > I am using the DOM API for my view rendering and it is very powerful and
> > flexible. hehe try using the decorator pattern on an already prepared
JSP
> > page ;-)
> >
> > I didnt end up using XMLC (didnt like the way it makes you generate
class
> > files to build your doms) but just use Xerces and standard DOM stuff.
> >
> > My code for rendering things like field values is flexible enough to
cope
> > with different types of elements, so I can play around with the actual
> > layout xhtml files without having to recompile. If im in the process of
> > trying to making something look nice, Ill often just go and play with
the
> > xhtml files directly in the tomcat webapp directly until the screen
looks
> > nice, and then copy the source back into my source directory.
> >
> > There is nothing to stop you using XMLC with struts. Instead of
forwarding
> > to a jsp you forward to something that will use the appropriate xmlc
class
> > to give you a dom, and run the code to write the appropriate values
(such
> as
> > actionform properties) into the dom, before serializing the results to
the
> > output.
> >
> > -----Original Message-----
> > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > Sent: Monday, 7 April 2003 08:41
> > To: Struts User
> > Subject: JSP/taglibs vs. XMLC
> >
> >
> > Taglibs, the answer to separation of roles problem, seems like a variant
> of
> > SAX solution in the
> > sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When
> JSP
> > is nothing but XML
> > behind the scenes, why not use SAX/DOM to manipulate the viewers like
XMLC
> > does? That way you
> > force the logic out of web pages and there is clear separation of visual
> > design and content
> > generation. Sounds like a no brainer to me, I don't understand why SUN
> would
> > put more efforts into
> > JSP. Am I missing something?
> >
> > -Harish
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Harish Krishnaswamy <wh...@yahoo.com>.
Cool, thanks for sharing Andrew!
--- Andrew Hill <an...@gridnode.com> wrote:
> Ive been validating in my actions as I find doing it in the actionForm
> inconvienient.
>
> My app has metainfo on which fields are mandatory etc... however the actual
> validation process is still the good old process of checking if whats in the
> actionform is valid, and if not saving an an appropriate actionError for
> that field.
>
> For rendering the error, my field rendering code will check to see if the
> field has an associated actionError, and if so will render the i18ned text
> for the error into an element in the dom with the id attribute "bob_error"
> (where the fieldname is "bob").
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, 7 April 2003 14:03
> To: Struts User
> Subject: RE: JSP/taglibs vs. XMLC
>
>
> What did you do for validations? Can you share a little bit about that?
> Thanks!
>
> -Harish
>
>
> --- Andrew Hill <an...@gridnode.com> wrote:
> > I dont think your missing anything. JSPs mingling of layout with the code
> to
> > render the dynamic bits is truly diabolical.
> >
> > I am using the DOM API for my view rendering and it is very powerful and
> > flexible. hehe try using the decorator pattern on an already prepared JSP
> > page ;-)
> >
> > I didnt end up using XMLC (didnt like the way it makes you generate class
> > files to build your doms) but just use Xerces and standard DOM stuff.
> >
> > My code for rendering things like field values is flexible enough to cope
> > with different types of elements, so I can play around with the actual
> > layout xhtml files without having to recompile. If im in the process of
> > trying to making something look nice, Ill often just go and play with the
> > xhtml files directly in the tomcat webapp directly until the screen looks
> > nice, and then copy the source back into my source directory.
> >
> > There is nothing to stop you using XMLC with struts. Instead of forwarding
> > to a jsp you forward to something that will use the appropriate xmlc class
> > to give you a dom, and run the code to write the appropriate values (such
> as
> > actionform properties) into the dom, before serializing the results to the
> > output.
> >
> > -----Original Message-----
> > From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> > Sent: Monday, 7 April 2003 08:41
> > To: Struts User
> > Subject: JSP/taglibs vs. XMLC
> >
> >
> > Taglibs, the answer to separation of roles problem, seems like a variant
> of
> > SAX solution in the
> > sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When
> JSP
> > is nothing but XML
> > behind the scenes, why not use SAX/DOM to manipulate the viewers like XMLC
> > does? That way you
> > force the logic out of web pages and there is clear separation of visual
> > design and content
> > generation. Sounds like a no brainer to me, I don't understand why SUN
> would
> > put more efforts into
> > JSP. Am I missing something?
> >
> > -Harish
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - File online, calculators, forms, and more
> > http://tax.yahoo.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Andrew Hill <an...@gridnode.com>.
Ive been validating in my actions as I find doing it in the actionForm
inconvienient.
My app has metainfo on which fields are mandatory etc... however the actual
validation process is still the good old process of checking if whats in the
actionform is valid, and if not saving an an appropriate actionError for
that field.
For rendering the error, my field rendering code will check to see if the
field has an associated actionError, and if so will render the i18ned text
for the error into an element in the dom with the id attribute "bob_error"
(where the fieldname is "bob").
-----Original Message-----
From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
Sent: Monday, 7 April 2003 14:03
To: Struts User
Subject: RE: JSP/taglibs vs. XMLC
What did you do for validations? Can you share a little bit about that?
Thanks!
-Harish
--- Andrew Hill <an...@gridnode.com> wrote:
> I dont think your missing anything. JSPs mingling of layout with the code
to
> render the dynamic bits is truly diabolical.
>
> I am using the DOM API for my view rendering and it is very powerful and
> flexible. hehe try using the decorator pattern on an already prepared JSP
> page ;-)
>
> I didnt end up using XMLC (didnt like the way it makes you generate class
> files to build your doms) but just use Xerces and standard DOM stuff.
>
> My code for rendering things like field values is flexible enough to cope
> with different types of elements, so I can play around with the actual
> layout xhtml files without having to recompile. If im in the process of
> trying to making something look nice, Ill often just go and play with the
> xhtml files directly in the tomcat webapp directly until the screen looks
> nice, and then copy the source back into my source directory.
>
> There is nothing to stop you using XMLC with struts. Instead of forwarding
> to a jsp you forward to something that will use the appropriate xmlc class
> to give you a dom, and run the code to write the appropriate values (such
as
> actionform properties) into the dom, before serializing the results to the
> output.
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, 7 April 2003 08:41
> To: Struts User
> Subject: JSP/taglibs vs. XMLC
>
>
> Taglibs, the answer to separation of roles problem, seems like a variant
of
> SAX solution in the
> sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When
JSP
> is nothing but XML
> behind the scenes, why not use SAX/DOM to manipulate the viewers like XMLC
> does? That way you
> force the logic out of web pages and there is clear separation of visual
> design and content
> generation. Sounds like a no brainer to me, I don't understand why SUN
would
> put more efforts into
> JSP. Am I missing something?
>
> -Harish
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Harish Krishnaswamy <wh...@yahoo.com>.
What did you do for validations? Can you share a little bit about that? Thanks!
-Harish
--- Andrew Hill <an...@gridnode.com> wrote:
> I dont think your missing anything. JSPs mingling of layout with the code to
> render the dynamic bits is truly diabolical.
>
> I am using the DOM API for my view rendering and it is very powerful and
> flexible. hehe try using the decorator pattern on an already prepared JSP
> page ;-)
>
> I didnt end up using XMLC (didnt like the way it makes you generate class
> files to build your doms) but just use Xerces and standard DOM stuff.
>
> My code for rendering things like field values is flexible enough to cope
> with different types of elements, so I can play around with the actual
> layout xhtml files without having to recompile. If im in the process of
> trying to making something look nice, Ill often just go and play with the
> xhtml files directly in the tomcat webapp directly until the screen looks
> nice, and then copy the source back into my source directory.
>
> There is nothing to stop you using XMLC with struts. Instead of forwarding
> to a jsp you forward to something that will use the appropriate xmlc class
> to give you a dom, and run the code to write the appropriate values (such as
> actionform properties) into the dom, before serializing the results to the
> output.
>
> -----Original Message-----
> From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
> Sent: Monday, 7 April 2003 08:41
> To: Struts User
> Subject: JSP/taglibs vs. XMLC
>
>
> Taglibs, the answer to separation of roles problem, seems like a variant of
> SAX solution in the
> sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When JSP
> is nothing but XML
> behind the scenes, why not use SAX/DOM to manipulate the viewers like XMLC
> does? That way you
> force the logic out of web pages and there is clear separation of visual
> design and content
> generation. Sounds like a no brainer to me, I don't understand why SUN would
> put more efforts into
> JSP. Am I missing something?
>
> -Harish
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online, calculators, forms, and more
> http://tax.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: JSP/taglibs vs. XMLC
Posted by Andrew Hill <an...@gridnode.com>.
I dont think your missing anything. JSPs mingling of layout with the code to
render the dynamic bits is truly diabolical.
I am using the DOM API for my view rendering and it is very powerful and
flexible. hehe try using the decorator pattern on an already prepared JSP
page ;-)
I didnt end up using XMLC (didnt like the way it makes you generate class
files to build your doms) but just use Xerces and standard DOM stuff.
My code for rendering things like field values is flexible enough to cope
with different types of elements, so I can play around with the actual
layout xhtml files without having to recompile. If im in the process of
trying to making something look nice, Ill often just go and play with the
xhtml files directly in the tomcat webapp directly until the screen looks
nice, and then copy the source back into my source directory.
There is nothing to stop you using XMLC with struts. Instead of forwarding
to a jsp you forward to something that will use the appropriate xmlc class
to give you a dom, and run the code to write the appropriate values (such as
actionform properties) into the dom, before serializing the results to the
output.
-----Original Message-----
From: Harish Krishnaswamy [mailto:whonts@yahoo.com]
Sent: Monday, 7 April 2003 08:41
To: Struts User
Subject: JSP/taglibs vs. XMLC
Taglibs, the answer to separation of roles problem, seems like a variant of
SAX solution in the
sense that Tag Handlers for JSP resemble the SAX Handlers for XML. When JSP
is nothing but XML
behind the scenes, why not use SAX/DOM to manipulate the viewers like XMLC
does? That way you
force the logic out of web pages and there is clear separation of visual
design and content
generation. Sounds like a no brainer to me, I don't understand why SUN would
put more efforts into
JSP. Am I missing something?
-Harish
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org