You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Marinó A. Jónsson" <ma...@centrum.is> on 2003/07/26 17:52:10 UTC
Velocity Struts and XHTML ...
I've been throwing together a Struts 1.1 compatible version of the
ValidatorTool and one little thing grabbed my eye.
if you put the following tag in the .jsp page
<html:xhtml/>
it signals that the output of the current page should be xhtml.
All it really does is set the Globals.XHTML_KEY attribute to "true" in page
scope.
The effect is that all Struts html-tags on that page output xhtml instead of
regular html (including the validator javascript tag).
I guess my question is, shouldn't we also have a standard xhtml flag
available to all tools ... perhaps by using a very simple xhtml tool (a
Struts XhtmlTag counterpart) and a complementary StrutsUtils method (a
RequestUtils counterpart)?:
package org.apache.velocity.tools.struts;
import org.apache.velocity.tools.view.context.ViewContext;
import org.apache.velocity.tools.view.tools.ViewTool;
import org.apache.struts.Globals;
public class XhtmlTool implements ViewTool
{
protected ViewContext context;
/******************************* Constructors
****************************/
/**
* Default constructor. Tool must be initialized before use.
*/
public XhtmlTool() {}
/**
* Initializes this tool.
*
* @param obj the current ViewContext
* @throws IllegalArgumentException if the param is not a ViewContext
*/
public void init(Object obj)
{
if (!(obj instanceof ViewContext))
{
throw new IllegalArgumentException("Tool can only be initialized
with a ViewContext");
}
this.context = (ViewContext)obj;
}
public void on() {
context.getVelocityContext().put(Globals.XHTML_KEY, "true");
}
}
and the SrutsUtils method:
/**
* Returns true if the tools are in XHTML mode.
* @since Struts 1.1
*/
public static boolean isXhtml(VelocityContext context) {
String xhtml =
(String) context.get(Globals.XHTML_KEY);
return "true".equalsIgnoreCase(xhtml);
}
just wondering :-)
cheers,
Marino
Re: Velocity Struts and XHTML ...
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
...
> hmm ... sounds like you're really talking about a JavascriptValidatorMacro
> of sorts :) ... javascript insertion would then be template driven and the
> JavascriptValidatorTool would provide a collection of methods to aid in the
> production of dynamic javascipt:
>
> #validatorJavascript("nameOfForm")
>
> (or ... if we don't have an xhtml setting available, but want the output to
> be xhtml):
>
> #validatorJavascriptXhtml("nameOfForm")
yeah, i wondered if we'd get here soon... :)
maybe it's time to start thinking about how to
create/document/setup/distribute velocimacro libraries with the three
packages.
> Nathan wrote:
> > does anyone really design a web application where some pages are XHMTL and
> > some are just HTML? shouldn't this be an application-level setting
> > instead of a page-level one?
>
> probably yeah :)
...
> in any case - the xhtml setting would imho be very useful in forthcoming
> velocimacro libraries as well as some of the tools.
yeah, actually, i was thinking that it'd be pretty much necessary.
> If it's an application level setting ... imho it should then be available in
> the ViewContext - and thus be accessible to all tools
agreed. and easily done: just set application.setAttribute("isXhtml", new
Boolean(true)) and the ChainedContext takes care of the rest.
this could also allow it to be overridden at any "higher" level (session,
request, context) if someone really wanted (though i think that would be very
odd).
> (maybe set it in velocity.properties - rather than toolbox.xml?)
hmm. my instinct is to say it should happen in the toolbox.xml, but i suppose
that depends on whether macros for producing HTML/XHMTL would go with just
VelocityView and VelocityStruts, or if we would have web-based macros with the
generic tools as well. right now, i think it best to keep web-related stuff
out of the generic tools. i'm thinking a rule for an
<xhtml>true|false</xhtml> element added to the ServletToolboxRuleSet would be
the way to go.
> If it's a page level setting - we could move the XhtmlTool to the view.tools
> or generic packages and make isXhtml() a static method in the tool itself.
to me, it just seems like a waste of cycles and memory to have a tool when an
application attribute would be sufficient and simpler to use.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Velocity Struts and XHTML ...
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Nathan wrote:
> the reason Struts needs such a JSP tag and configuration setting is that
> they regularly output markup from java. this is IMHO, the biggest failing
> of JSP and the key to the superiority of template technologies like
> Velocity.
yup, I agree - just thought maybe the principle wouldn't apply to javascript
generated from Validator rules (since there's almost no markup or javascript
code in the tag).
Tim Colson wrote:
> I had to code/compile/restart just to insert an extra alert("Workin'
> here"). I was thinking that all that code should simply be in a velocity
> template that produces the dynamic javascript.
hmm ... sounds like you're really talking about a JavascriptValidatorMacro
of sorts :) ... javascript insertion would then be template driven and the
JavascriptValidatorTool would provide a collection of methods to aid in the
production of dynamic javascipt:
#validatorJavascript("nameOfForm")
(or ... if we don't have an xhtml setting available, but want the output to
be xhtml):
#validatorJavascriptXhtml("nameOfForm")
it's an idea :)
Nathan wrote:
> does anyone really design a web application where some pages are XHMTL and
> some are just HTML? shouldn't this be an application-level setting
> instead of a page-level one?
probably yeah :)
> if, however, a JavascriptValidatorTool or other tool also requires such an
> option, then yeah, it might be time to set up a standard way of
> setting/unsetting and checking such an option.
> also, i would want LinkTool (in the view package) to be able to
> automatically take advantage of this too, so we can't rely entirely on
> StrutsUtils to check the current setting.
in any case - the xhtml setting would imho be very useful in forthcoming
velocimacro libraries as well as some of the tools.
If it's an application level setting ... imho it should then be available in
the ViewContext - and thus be accessible to all tools (maybe set it in
velocity.properties - rather than toolbox.xml?)
If it's a page level setting - we could move the XhtmlTool to the view.tools
or generic packages and make isXhtml() a static method in the tool itself.
cheers,
Marino
-----Original Message-----
From: Nathan Bubna [mailto:nathan@esha.com]
Sent: 26. júlí 2003 17:36
To: Velocity Developers List
Subject: Re: Velocity Struts and XHTML ...
Marinó A. Jónsson said:
> I've been throwing together a Struts 1.1 compatible version of the
> ValidatorTool and one little thing grabbed my eye.
...
> <html:xhtml/>
> it signals that the output of the current page should be xhtml.
>
> All it really does is set the Globals.XHTML_KEY attribute to "true" in
page
> scope.
>
> The effect is that all Struts html-tags on that page output xhtml instead
of
> regular html (including the validator javascript tag).
>
> I guess my question is, shouldn't we also have a standard xhtml flag
> available to all tools ... perhaps by using a very simple xhtml tool (a
> Struts XhtmlTag counterpart) and a complementary StrutsUtils method (a
> RequestUtils counterpart)?:
...
> just wondering :-)
the reason Struts needs such a JSP tag and configuration setting is that
they
regularly output markup from java. this is IMHO, the biggest failing of JSP
and the key to the superiority of template technologies like Velocity. with
Velocity-Tools, we strive hard to avoid hard-coding any markup in the java
source (regardless of whether it's HTML, XHTML, or XML).
that said, there are times when usability and convenience legitimately
supersedes principle. so, there are places where we blur the line (e.g.
StrutsUtils.errorMarkup() or LinkTool.setXhtml()). at this point, the
LinkTool is the only tool we have in the repository that needs to concern
itself with the difference between HTML and XHTML. IMHO, that alone is not
worth a system of the type you suggest. if, however, a
JavascriptValidatorTool or other tool also requires such an option, then
yeah,
it might be time to set up a standard way of setting/unsetting and checking
such an option.
so, *if* that's the case, then let's discuss how best to set this up. as
usual, i'd rather do this better than JSP does than just mimic it. frankly,
the idea of an XhtmlTool that merely turns on/off an XHTML setting doesn't
sound very good to me. does anyone really design a web application where
some
pages are XHMTL and some are just HTML? shouldn't this be an
application-level setting instead of a page-level one? also, i would want
LinkTool (in the view package) to be able to automatically take advantage of
this too, so we can't rely entirely on StrutsUtils to check the current
setting.
thoughts?
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [VELTOOLS] FormTool design
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
...
> Thanks Nathan/Marino for so kindly pointing out my stupidity and somehow
> not reading all of the RTFM on this one. Will I ever learn not to post
> when I first wake up? ;-)
we've all got our brain-dead moments. RT[F]M is not something i'd ever say to
someone who wrote/enhanced a lot of our documentation. :)
> As pennance, howabout I do something I suggested a while ago - an
> abbreviated "Users Guide" doc for the Tools?
what if i say "no, i'll only forgive you if you write all the doc suggestions
in STATUS *and* the abbreviated UG!" ? ;-) just kidding, of course. when
it comes to docs, i'm eager for help!
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: [VELTOOLS] FormTool design
Posted by Tim Colson <tc...@cisco.com>.
> FormTool.getBean() is purely a convenience method for those
> not wishing to
> depend on the form name as specified in the struts-config.
> it even says so in
> the javadoc for the method. :) it simply provides a
> consistent interface.
Doh!
Thanks Nathan/Marino for so kindly pointing out my stupidity and somehow
not reading all of the RTFM on this one. Will I ever learn not to post
when I first wake up? ;-)
As pennance, howabout I do something I suggested a while ago - an
abbreviated "Users Guide" doc for the Tools?
-Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [VELTOOLS] FormTool design
Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
...
> I've been working a bit with the struts forms tool and find this syntax
> a bit cumbersome to explain to my Designer:
>
> ## The same can be written as
> <input type="text" name="username" value="$form.bean.username">
...
FormTool.getBean() is purely a convenience method for those not wishing to
depend on the form name as specified in the struts-config. it even says so in
the javadoc for the method. :) it simply provides a consistent interface.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: [VELTOOLS] FormTool design
Posted by Simon Christian <si...@stoutstick.com>.
Hi Tim,
I've only been using velstruts for a short while, so excuse me if this
is out of place, but I just sort of assumed you could use that short
syntax, and it does seem to work (!) like:
$!logonForm.username
Where logonForm is defined nowhere but struts-config.xml
- simon
Tim Colson wrote:
> Hey folks -
>
> I've been working a bit with the struts forms tool and find this syntax
> a bit cumbersome to explain to my Designer:
>
> ## The same can be written as
> <input type="text" name="username" value="$form.bean.username">
>
> On the page, there are 1 or more forms... named in the
> struts-config.xml, so couldn't we automatigally have them available to
> the template?
>
> Ex. FooAction.do has FooForm associated which has a field accessor
> getUsername().
>
> I think the template should be able to use
> $form.FooForm.username
> $FooForm.username
> or, perhaps the default form as simply:
> $form.username
>
> I can't recall if this has been discussed before, so perhaps I've just
> missed the reasons why this wouldn't be better?
>
>
> Cheers,
> Timo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: [VELTOOLS] FormTool design
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
hmm ... the forms _are_ automatically available in the template :)
Ex. FooAction.do has FooForm associated which has a field accessor
getUsername().
You should be able to use
$FooForm.username
I do it like this in all my projects (aside from the fact I use
DynaActionForms extensively).
cheers,
Marino
-----Original Message-----
From: Tim Colson [mailto:tcolson@cisco.com]
Sent: 29. júlí 2003 16:39
To: 'Velocity Developers List'
Subject: [VELTOOLS] FormTool design
Hey folks -
I've been working a bit with the struts forms tool and find this syntax
a bit cumbersome to explain to my Designer:
## The same can be written as
<input type="text" name="username" value="$form.bean.username">
On the page, there are 1 or more forms... named in the
struts-config.xml, so couldn't we automatigally have them available to
the template?
Ex. FooAction.do has FooForm associated which has a field accessor
getUsername().
I think the template should be able to use
$form.FooForm.username
$FooForm.username
or, perhaps the default form as simply:
$form.username
I can't recall if this has been discussed before, so perhaps I've just
missed the reasons why this wouldn't be better?
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[VELTOOLS] FormTool design
Posted by Tim Colson <tc...@cisco.com>.
Hey folks -
I've been working a bit with the struts forms tool and find this syntax
a bit cumbersome to explain to my Designer:
## The same can be written as
<input type="text" name="username" value="$form.bean.username">
On the page, there are 1 or more forms... named in the
struts-config.xml, so couldn't we automatigally have them available to
the template?
Ex. FooAction.do has FooForm associated which has a field accessor
getUsername().
I think the template should be able to use
$form.FooForm.username
$FooForm.username
or, perhaps the default form as simply:
$form.username
I can't recall if this has been discussed before, so perhaps I've just
missed the reasons why this wouldn't be better?
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Velocity Struts and XHTML ...
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
Tim Colson said:
> Marino - what's that looking like? I'd like to help out there but do not
> want to waste our efforts going in duplicate or separate ways! :-)
not much chance of wasted efforts ... i'm basically doing what you did -
copy-pasting the JavascriptValidatorTag code ;)
cheers,
Marino
-----Original Message-----
From: Tim Colson [mailto:tcolson@cisco.com]
Sent: 26. júlí 2003 18:23
To: 'Velocity Developers List'
Subject: RE: Velocity Struts and XHTML ...
> the reason Struts needs such a JSP tag and configuration
> setting is that they
> regularly output markup from java. this is IMHO, the biggest
> failing of JSP
I agree. The hacked up version of the Validator tool just mimics the JSP
and embeds the javascript code inside it. When I was debugging, I had to
code/compile/restart just to insert an extra alert("Workin' here"). I
was thinking that all that code should simply be in a velocity template
that produces the dynamic javascript.
But for the Struts 1.0 JavascriptValidatorTool, I did not want to go to
the trouble... I'd rather dig into the Struts 1.1 stuff and make it
better there.
Marino - what's that looking like? I'd like to help out there but do not
want to waste our efforts going in duplicate or separate ways! :-)
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Velocity Struts and XHTML ...
Posted by Tim Colson <tc...@cisco.com>.
> the reason Struts needs such a JSP tag and configuration
> setting is that they
> regularly output markup from java. this is IMHO, the biggest
> failing of JSP
I agree. The hacked up version of the Validator tool just mimics the JSP
and embeds the javascript code inside it. When I was debugging, I had to
code/compile/restart just to insert an extra alert("Workin' here"). I
was thinking that all that code should simply be in a velocity template
that produces the dynamic javascript.
But for the Struts 1.0 JavascriptValidatorTool, I did not want to go to
the trouble... I'd rather dig into the Struts 1.1 stuff and make it
better there.
Marino - what's that looking like? I'd like to help out there but do not
want to waste our efforts going in duplicate or separate ways! :-)
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Velocity Struts and XHTML ...
Posted by Nathan Bubna <na...@esha.com>.
Marinó A. Jónsson said:
> I've been throwing together a Struts 1.1 compatible version of the
> ValidatorTool and one little thing grabbed my eye.
...
> <html:xhtml/>
> it signals that the output of the current page should be xhtml.
>
> All it really does is set the Globals.XHTML_KEY attribute to "true" in page
> scope.
>
> The effect is that all Struts html-tags on that page output xhtml instead of
> regular html (including the validator javascript tag).
>
> I guess my question is, shouldn't we also have a standard xhtml flag
> available to all tools ... perhaps by using a very simple xhtml tool (a
> Struts XhtmlTag counterpart) and a complementary StrutsUtils method (a
> RequestUtils counterpart)?:
...
> just wondering :-)
the reason Struts needs such a JSP tag and configuration setting is that they
regularly output markup from java. this is IMHO, the biggest failing of JSP
and the key to the superiority of template technologies like Velocity. with
Velocity-Tools, we strive hard to avoid hard-coding any markup in the java
source (regardless of whether it's HTML, XHTML, or XML).
that said, there are times when usability and convenience legitimately
supersedes principle. so, there are places where we blur the line (e.g.
StrutsUtils.errorMarkup() or LinkTool.setXhtml()). at this point, the
LinkTool is the only tool we have in the repository that needs to concern
itself with the difference between HTML and XHTML. IMHO, that alone is not
worth a system of the type you suggest. if, however, a
JavascriptValidatorTool or other tool also requires such an option, then yeah,
it might be time to set up a standard way of setting/unsetting and checking
such an option.
so, *if* that's the case, then let's discuss how best to set this up. as
usual, i'd rather do this better than JSP does than just mimic it. frankly,
the idea of an XhtmlTool that merely turns on/off an XHTML setting doesn't
sound very good to me. does anyone really design a web application where some
pages are XHMTL and some are just HTML? shouldn't this be an
application-level setting instead of a page-level one? also, i would want
LinkTool (in the view package) to be able to automatically take advantage of
this too, so we can't rely entirely on StrutsUtils to check the current
setting.
thoughts?
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org