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

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

Any concrete suggestions on how to move forward with this? Seth? Darren?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 19:54
An: spr...@li...
Betreff: Re: [Springframework-developer] New technique for working with =
<spring:bind>

Furthermore, Velocimacros - and therefore form simplification macros for =
Velocity that we might provide out-of-the-box - are available even for =
Servlet 2.2 (JSP 1.1) containers. So for older containers, Velocity will =
become an even more compelling choice as view technology, once we =
provide such default form macros.

http://jakarta.apache.org/velocity/user-guide.html#Velocimacros =
<http://jakarta.apache.org/velocity/user-guide.html#Velocimacros>

FreeMarker actually offers a macro mechanism very similar to Velocity's. =
Therefore, we should be available to provide analogous form =
simplification macros for FreeMarker - again, leveraging its native =
macro mechanism. Actually, the syntax is so similar to Velocity that we =
might be able to use the same set of macro files...

http://www.freemarker.org/docs/dgui_misc_userdefdir.html =
<http://www.freemarker.org/docs/dgui_misc_userdefdir.html>

Any volunteers for those 3 form macro sets? :-) Maybe Seth for JSP 2.0? =
Darren for Velocity, maybe also for FreeMarker? I'll care for overall =
consistency. Target milestone could already be Spring 1.0.3 (end of =
June), but 1.1 RC1 (end of August) would be good enough too.

BTW, thanks, everybody, for all your input!

Juergen

________________________________

Von: j=FCrgen h=F6ller [werk3AT]
Gesendet: Sa 22.05.2004 19:27
An: spr...@li...
Betreff: Re: [Springframework-developer] New technique for working with =
<spring:bind>

Regarding Velocity, there is actually a similar native technique: =
Velocimacros can achieve more or less the same as JSP 2.0 tag files, in =
a pretty similar style. IIRC, Darren is using Velocimacros exactly for =
rendering form elements, just like Seth uses JSP 2.0 tag files.

I guess such simplifications for form building will always be specific =
to a view technology. What we could do is ship both default JSP 2.0 tag =
files *and* default Velocimacros for simplified form rendering, keeping =
them as analogous as possible (fetching dynamic values via bind tags =
respectively the RequestContext).

In both cases, Java code would not issue HTML; rather, the HTML code is =
always kept in a template that allows for easy customization. I believe =
that having such analogous solutions for both JSP 2.0 and Velocity (and =
possibly FreeMarker) is quite promising.

There's also value in leveraging the respective native macro mechanism =
of each view technology: This allows for natural integration without =
special bridges, also avoiding the need to learn yet another macro =
mechanism if you already know your view technology's native one.

You do have a point that JSP 1.x does not have such a native macro =
mechanism. Of course, there's still the option of coding the form =
elements directly (just like our current samples do), so those users are =
by no means locked out. And as you say, it's a good reason for them to =
upgrade to JSP 2.0 :-)

Whether or not to provide Java-coded form simplification tags for JSP =
1.2 is a question of tradeoff. For JSP 2.0, tag files are absolutely =
preferable, so Java-coded tags for JSP 1.2 would be a completely =
separate effort - even more extra effort if also attempting to provide a =
customization option for the HTML code.

My personal point of view is that we should focus on providing good form =
simplification macros for JSP 2.0 and Velocity / FreeMarker, and keep =
recommending direct form elements with bind tags for JSP 1.2. Time is on =
our side in that respect, inevitably leading to broader adoption of JSP =
2.0.

And of course, there's always the option of using Struts or WebWork on =
top of a Spring middle tier. Particularly for JSP 1.1, Struts is a =
compelling option, as its tags work there too. For JSP 1.2, both Struts =
and WebWork are viable choices for scenarios where form simplification =
macros are important.

Juergen

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Sa 22.05.2004 17:38
An: spr...@li...
Betreff: Re: [Springframework-developer] New technique for working with =
<spring:bind>

I agree that JSP 2.0 tag files for rendering form elements is a *very*
cool idea.  Unfortunately, there will probably be some flack from the
community because it won't work on most of the containers out there.
However, I think it's a good thing - let's drag those suckers into
using JSP 2.0 and help them simplify their lives. ;-) Hopefully more
containers will start producing J2EE 1.4-compatible servers.  To my
knowledge, only Tomcat, Resin and WebSphere support JSP 2.0.

The one nice thing about the WW tags is that they can actually be used
in both Velocity templates or in JSP pages.  I believe that's
accomplished with some Velocity magic that invokes JSP Tags.  It would
be nice if whatever Spring develops (to simplify JSP forms) can also be
used to simplify Velocity forms.

Matt

On May 22, 2004, at 5:48 AM, j=FCrgen h=F6ller [werk3AT] wrote:

> Seth,
>
> I do see what you intend setNestedPath for - I just feel that Matt has
> "misused" it in his example: In his 2-input-field form, setNestedPath
> complicates matters rather than simplifies it; this is definitely
> *not* "the Spring version that requires less typing" (as Matt has put
> it). Please read my initial post mainly as direct reaction to Matt's
> blog entry rather than as critique of setNestedPath per se.
>
> For a large number of input fields, setting a specific nested path in
> an outer tag does indeed simplify things. But even more important is
> that it allows for reuse of entire sub-forms, like Jon has pointed out
> with his address example; that was what I had in mind with reusing
> bind tag snippets. This usage is similar to setNestedPath on an Errors
> object (which is where you got the original idea from, I assume).
>
> Your "ideal looking page" is exactly what I envisage as optimal use of
> JSP 2.0 with Spring! With such concise input field syntax, specifying
> the nested path in an outer tag already makes sense for a small number
> of fields - agreed. It might be worth designing a "form:form" tag (as
> JSP 2.0 tag file) that sets the nested path (using setNestedPath
> underneath) but also renders a corresponding HTML form tag, analogous
> to Struts' "html:form".
>
> So moving forward, I consider adding a setNestedPath-style tag to
> Spring's standard tag library, possibly as "spring:nestedPath" (no
> "set" in the name, analogous to "spring:htmlEscape"). This does make
> sense both with and without JSP 2.0, so should be part of Spring's
> standard (Java-coded) tag library, I guess. Multiple
> "spring:nestedPath" tags could also be nested, building hierarchical
> nested paths.
>
> Have you considered donating your "form" tag library (JSP 2.0 tag
> files) to Spring? It's exactly what I had in mind with my suggestion
> in yesterday's blog comment. It would be a welcome option in standard
> Spring, and an excellent showcase for JSP 2.0 tag files: high-level
> HTML-issuing tags (coded as tag files) built on lower-level value
> access tags (classic Java-coded tags).
>
> Such a form tag library coded as JSP 2.0 tag files is much preferable
> to (Struts-style) classic Java-coded tags for each and every input
> field type, IMO, mainly because it's so easy to customize. There is
> still no HTML content in Java code -rather in JSP tag files. I believe
> that this is a very viable alternative to WebWork's form tags that
> issue HTML content from corresponding Velocity templates.
>
> Spring 1.0.2 will be released on Monday, so we should avoid further
> new functionality there. I plan to add "spring:nestedPath" for 1.0.3;
> it would be great to already have a basic "form" tag file library in
> that release too (or in 1.1 RC1)! A sample application that
> illustrates usage of those tag files is a necessity (of course, that
> sample will require JSP 2.0): maybe alternative JSP views for
> JPetStore's Spring web tier?
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag
> von Seth Ladd
> Gesendet: Sa 22.05.2004 00:02
> An: spr...@li...
> Betreff: Re: [Springframework-developer] Re: [Springframework-user]
> New technique for working with <spring:bind>
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks Juergen for pointing out this post.
>
>
> | 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.
>
> That's exactly why I would want it and use it.  I don't want to repeat
> anything.  The setNestedPath tag follows very closely the bind tag.
> That is, just helps with setting scope of a bean that bind is using.
> It's entirely optional, too.  The bind tag works/should work just fine
> without it.  I've found it very useful in developing our JSPs that use
> many fields, where many of the fields are withing nested objects.
>
> I still believe it saves typing for anything more than 2 fields.  =
Also,
> it saves a chance for error, as I'm not repeating the command name =
over
> and over.
>
> Having said that...
>
> |
> | 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.
>
> That's exactly what I, and I suspect many, people are doing right now.
> I've wrapped the bind tag and the logic to render the HTML (for
> instance, select and option tags) inside a tag file.  Using the
> struts-esque tag files + setNestedPath, I'm pretty close to very
> minimal
> JSP typing.
>
> I see setNestedPath as an optional, but extremely helpful tag when
> writing anything but the most simple JSP page.  I then see a separate
> set of convinience tags/tag files that render HTML markup as a really
> nice value add that everyone will end up writing anyway.
>
> See the original wiki page that started this.  There is a comment =
there
> that gives examples of these tag files.
>
> My ideal looking page (and what I'm using now):
>
> <springx:setNestedPath path=3D"command">
>
> First Name: <form:text name=3D"firstName"/>
> Last Name: <form:text name=3D"lastName" />
>
> Address:
> <springx:setNestedPath path=3D"address">
> Street1: <form:text name=3D"street1"/>
> Street2: <form:text name=3D"street2"/>
> ...
> </springx:setNestedPath>
>
> <input type=3D"submit"/>
> </springx:setNestedPath>
>
> Hope that helps.
>
> Thanks,
> Seth
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3-nr1 (Windows XP)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFArnxpKZsFSwtW+wIRAvUmAJ92o8EtbvaoyqGBd+MJa7apQRisXgCeO72t
> PHxE0WKTDhfnnfi20RfGThA=3D
> =3DoMwA
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> 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_id149&alloc_id(tm)66&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

-------------------------------------------------------
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_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

-------------------------------------------------------
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_id149&alloc_id=8166&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer