Hello I'm currently integrating dojo into Tapestry5. Today things seem
to go well, but I've seen one thing that doesn't fully convince me.
In AbstractField we have
@Environmental(false)
private FormSupport formSupport;
and then
@SetupRender
final void setup()
{
// By default, use the component id as the (base) client id.
If the clientid
// parameter is bound, then that is the value to use.
String id = clientId;
// Often, these controlName and clientId will end up as the
same value. There are many
// exceptions, including a form that renders inside a loop, or
a form inside a component
// that is used multiple times.
if (formSupport == null) throw new
RuntimeException(InternalMessages.formFieldOutsideForm(getLabel()));
assignedClientId = renderSupport.allocateClientId(id);
String controlName = formSupport.allocateControlName(id);
formSupport.storeAndExecute(this, new Setup(controlName));
formSupport.store(this, PROCESS_SUBMISSION_ACTION);
}
so a formSupport null will throw an excpetion.
When I'll decorate components like TextField I'll be obliged to put it
inside a Form component, when people not always need it.
Should't be possible only to send a warning or something like that on
formSupport null in 5.1.x?
On Mon, Mar 9, 2009 at 7:11 PM, Howard Lewis Ship <[email protected]> wrote:
> I'm working on the last major feature I'd like to see in 5.1:
> template inheritance (*).
>
> With that, I'm ready to switch from implementing features to fixing bugs.
>
> I think it would be approrpriate to release 5.1.0.1, fix a bunch of
> bugs, then see about getting a beta release out.
>
> Outside of Spring Web Flow and Portlet support (things I'd like to
> work on in 5.2), the only other major feature I see people clammoring
> for is dynamic updates on Selects, something I'm still noodling on.
> There's probably a few other minor features that would be nice to
> haves, but you have to draw the line somewhere!
>
>
> (*) This is an idea I picked up from wicket, though I'm extending it
> quite a bit. Parent component templates will be able to define
> <t:extension-point>s, and child component template will be able to
> provide <t:replace> elements that replace them (a unique id ties the
> two together). This can be used an an alternative to using a layout
> component, where each page will <t:replace> the default page content
> inherited from the base class. I generally think that for pages, a
> layout component is better, but for complex components (such as the
> Grid), this will be a great new feature for allowing changes to a
> container template without cutting and pasting the whole thing.
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
