[ http://issues.apache.org/jira/browse/TAPESTRY-5?page=all ]
Howard M. Lewis Ship resolved TAPESTRY-5:
-----------------------------------------
Resolution: Won't Fix
Assign To: Howard M. Lewis Ship
I can see what you'd like to do; this follows some of my ideas for what may
some day be Tapestry 5, in that you want fine-grained aspect-like control over
the output.
We've tried to keep Tapestry simple and with good reason; breaking out explicit
seperate renderers for every type of form control (or other) component adds a
lot of complexity, even if it makes edge cases like these easier.
However, with the 4.0 changes, it is now very, very easy to create your own
implementations of any of basic form control components. If you look at the
code for TextField now, it is down to extendeding a base class and a couple of
lines of code.
> Enhancement to customize rendering of form components
> -----------------------------------------------------
>
> Key: TAPESTRY-5
> URL: http://issues.apache.org/jira/browse/TAPESTRY-5
> Project: Tapestry
> Type: New Feature
> Components: Framework
> Versions: 2.3, 3.0, 3.0.1, 3.0.2
> Environment: Operating System: Other
> Platform: All
> Reporter: Dorothy Gantenbein
> Assignee: Howard M. Lewis Ship
> Fix For: 4.0
>
> ------------Migrated from Sourceforge --------
> Enhancement to customizer rendering of form components
> Would like ability to extend form components like
> Select, TextArea, CheckBox, PropertySelection, etc
> with additional parameters. My particular case is I want
> all Checkboxs to have a default HTML class.
> For TextField, could inherit from Tapestry's text field and
> then override the beforeCloseTag method. However,
> TextArea, Select, etc do not have a beforeCloseTag
> method.
> One approach to is add a beforeCloseTag method to the
> other form components and provide a uniform way to
> customize their rendering.
> Another approach (from Howard) is to make components
> act like PropertySelection and have a delegate for
> rendering. You could then create standard Foo's with an
> alternate FooRenderDelegate to accomplish what you
> want.
> Either approach works for my requirements. However,
> the rendering delegate seems to provide more flexiblity
> for customization.
> ---------------- followup -----------------------------
> Date: 2003-02-20 08:08
> Sender: hship
> Logged In: YES
> user_id=26816
> Could you elaborate (here, in the RFE) why this is required,
> rather than using informal parameters (in the HTML template)
> to accomplish this? All of the form element components
> support informal parameters for this purpose.
> ------------ reply to followup ------------------------------
> Informal parameters would not be an ideal solution for us.
> We want all our text fields to be the same HTML class.
> If we used an optional parameter, then our HTML designer would
> always have to remember to pass the correct class.
> Not ideal.
> When this was posted to the mailing list, it sparked a lively debate
> and it appeared that others have the same issue. Here is the
> link, https://sourceforge.net/mailarchive/message.php?msg_id=2920735.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
