Thread: [Springframework-developer] Re: [Springframework-user] New technique for working with <spring:bind>

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

My personal take on the tag library topic, quoted from a comment on =
Matt's Spring Live blog (see =
http://www.jroller.com/page/raible?anchor=3Dsimplifying_spring_bind_in_js=
ps =
<http://www.jroller.com/page/raible?anchor=3Dsimplifying_spring_bind_in_j=
sps>  for the full context):

"
Actually, Seth's version does *not* require less typing: It just avoids =
repeating the command name. Without Seth's setNestedPath tag, you'll get =
the 3 lines per field, saying "command.firstName" respectively =
"command.lastName". I actually prefer the latter; I personally don't =
think that such a setNestedPath tag adds value - except for very =
repetitive forms where you reuse the same bind tag snippet for various =
command names.=20

You can also put those 3 lines per field into 1 line, putting the bind =
tag right before/after the input tag. Of course, this is still =
significantly more verbose than the Struts tag library, but it doesn't =
issue any HTML from within the tag. As Keith has noted, this is the =
original design philosophy behind Spring's tag library: The template =
defines each HTML character that gets issued to the browser; no need for =
rendering Velocity templates from within a tag library like WebWork =
does.=20

If someone wants to reuse bind tags with specific HTML portions, simply =
turn them into parameterizable snippets: for example, with JSP 2.0's tag =
files. It should be straightforward to define Struts-style "html:xxx" =
custom tags this way, using the bind tag (or RequestContext/Errors =
scriptlets) underneath. I think this is a viable alternative to =
WebWork's way of custom tags rendering Velocity templates, being equally =
powerful.=20

There is also quite a lot of people who actually prefer having custom =
tags that just issue dynamic values, leaving static HTML to the template =
itself. Still, a remaining question is whether Spring should provide =
HTML-issuing custom tags (JSP 2.0 tag files built on top of the bind =
tag) in the standard distribution. If there is agreement on their =
default contents, we might do this; after all, being JSP tag files, they =
could be easily customized.=20
"

As we're about to get into strategic issues and implementation details, =
I suggest to move the discussion to the developer list.

Juergen

________________________________

Von: spr...@li... im Auftrag von =
Daniel Miller
Gesendet: Do 20.05.2004 00:39
An: spr...@li...
Betreff: RE: [Springframework-user] New technique for working with =
<spring:bind>

Seth,

I'm sorry to say it, but I think you're a bit confused here. As I =
understand
it, the commandName property of the controller (Handler?) is used solely =
to
identify the command object in the view. As per the Spring javadoc for
BaseCommandController:

Exposed configuration properties

name: commandName
default: command
description: the name to use when binding the instantiated command class =
to
the request

The object is bound to the request using this name. It has no impact on =
the
actual class name of the object being bound to the session. XDoclet (I
assume, but don't actually use it) and Commons-Validator Adapter use the
_class_name_ of the object to respectively create and locate the form
definition in validation.xml. As far as I know this has nothing to do =
with
the commandName property of BaseCommandController.

As a solution to the reply you sent to Keith, just always use the =
default
value of the commandName property ("command"), which can be done by =
simply
not specifying a commandName in your bean definition in the Spring
configuration file (*-servlet.xml).

For reference (You replied to Keith with the following):

> Even with the setNestedPath tag, you still need to specify the name of
the command object in the JSP file.  I'd like to only specify it in the
Handler (or the XML for the Handler).  Then, when the Handler is passing
control off to the View (indirectly, but you get the idea), it would
bind in a well known generic name to the name of the command object.
For instance, the Model would contain:

> model.put("nameFromHandlerConfigForCommandObject", command);
> model.put("commandName", "nameFromHandlerConfigForCommandObject");

> This way, all JSPs would be able to always know the command object's
name.  If the Handler's config changes, the JSPs don't change.  Plus, an
added benefit would be the tags could default to working with the
command object if no other path is specified.

Now back to my reply:

Currently, if you use the default value of commandName, you will end up =
with
this in each of your JSP's:

<spring:bind path=3D"command.someProperty">...</spring:bind>

I hope this didn't come across as too strongly, I'm just trying to help.

Daniel Miller

-----Original Message-----
From: spr...@li...
[mailto:spr...@li... =
<mailto:spr...@li...> ]On Behalf Of
Seth Ladd
Sent: Wednesday, May 19, 2004 5:42 PM
To: spr...@li...
Subject: Re: [Springframework-user] New technique for working with
<spring:bind>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| Out of curiosity, what led you to believe that this a requirement? I
do not
| remember this being a requirement, and I believe I am currently using =
the
| Commons-Validator adaptor for Spring with the default command name
| (command). I apologize in advance if I have misled you in some way
that has
| caused extra work on your part. Am I going so crazy that I can't even
| remember requirements of code that I wrote?

hehe, well, from what I read in the code (I'll try to verify right now)
it matches the command bean with its rules via the name.  Otherwise, how
else would it know which form bean to get from the xml file?

Also, I could be missing some cool elite secret piece of code. :)

Part of the puzzle is the xdoclet code that generates the validation.xml
file.  It generates the command bean names by using the class name.  For
instance, foo.bar.CommandBean becomes <form name=3D"commandBean">

OK, here is the code from BeanValidator (sandbox):

        /**
         * If <code>useFullyQualifiedBeanName</code> is false (default =
value),
         * this function returns a string containing a short name for =
the given
         * class (e.g. myBean for the class com.domain.test.MyBean). =
Otherwise, it
         * returns the value returned by Class.getName().
         *
         * @param clazz Class of the bean to be validated.
         *
         * @return String containing the bean name.
         */
        protected String getBeanName(Class clazz) {
                String name =3D clazz.getName();
                if (useFullyQualifiedBeanName) {
                        return name;
                } else {
                        int afterDot =3D name.lastIndexOf(".") + 1;
                        String firstChar =3D name.substring(afterDot, =
afterDot + 1).toLowerCase();
                        String otherChars =3D "";
                        if (afterDot + 1 <=3D name.length()) {
                                // Get the rest of the bean name
                                otherChars =3D name.substring(afterDot + =
1);
                        }
                        return firstChar + otherChars;
                }
        }

This is called from the validate() method.  I fear it's mere coincidence
that it all works, because both this code and the xdoclet code make this
same bean name assumption.  No real chance to specify it yourself.

Seth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org =
<http://enigmail.mozdev.org>=20

iD8DBQFAq9SPKZsFSwtW+wIRAl6PAKCC7oC+nXlw9lM+BAL7EEsqLJzGbgCfe/qx
M4eJ7VJzcQFmV030pqOmzKc=3D
=3DFwem
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick =
<http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick>=20
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user =
<https://lists.sourceforge.net/lists/listinfo/springframework-user>=20

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick =
<http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick>=20
_______________________________________________
Springframework-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user =
<https://lists.sourceforge.net/lists/listinfo/springframework-user>=20

Thread: [Springframework-developer] Re: [Springframework-user] New technique for working with <spring:bind>

springframework-developer