Re: [Springframework-developer] Final preparations for 1.1 RC1

[Darren D. <da...@da...>]

> No problem - let's add those for 1.1 final or even 1.1.1, whenever they
> are ready. Do you in principle envisage copying Velocity/FreeMarker mac=
ros
> to the user's resource loader path, to allow for easy customization?

it hadn't been my original intention, but then again I havn't really spen=
t
time thinking about it either :)  Originally I'd expected to make all the
macros standard but parameterisable, building on the binding ability just
added.  The html output would work without modification and a parameter
could be passed to the macro to customize the html.  Something like;

#macro (springTextInput $htmlAttributes)
  ## assume bind already performed
  <input
    type=3D"text"
    name=3D"${status.expression}"
    value=3D"$!status.value"
    $htmlAttributes
  #if ($xhtmlCompliant) "/>" #else ">" #end
#end


The following VTL;

#springTextInput('style=3D"border: 1px solid silver" maxlength=3D"30"')

would output (if binding to a 'name' field);

<input
    type=3D"text"
    name=3D"name"
    value=3D"Darren Davison"
    style=3D"border: 1px solid silver" maxlength=3D"30"
>

Further conveniences like allowing default htmlAttributes (defined by the
user, not Spring) would clearly be simple to implement too.

The Struts guys have gone to the trouble of duplicating almost all of the
HTML 4.0.1 attribute set in their custom tags, which sounds to me like an
awful lot of copy/paste just to get a nice IDE integration!

If the convenience macros fail to meet some unusual requirement in the
html form, the user can always fall back to using the springBind macro an=
d
completely handcoding individual fields - or the entire html form - as
required (like you would have to do now with what's in CVS).

I'm a bit unsure how copying macro definitions to app resource locations
works in practice: presumably we can only do this once to avoid
overwriting customizations made by the user?  How would we manage updates
made to the macros inside spring.jar in future releases?  It just sounds =
a
bit kludgy to me, but I'm probably missing an obvious benefit.

In my experience, the standard macros briefly outlined would be more
useful - I guess if a  user really wanted to completely customize the
macro set, s/he could manually take a copy from the Spring source and do
so, but I'm definitely open to opinions here.

Regards,

--=20
Darren Davison
Public Key: http://www.davison.uk.net/pages/key.htm