No. A TextField is a component that handles rendering an <input type="text" tag> and handling a subsequent form submission in the context of a Form component (including all the related Ajax and validation logic).
If you have a component that needs to render an <input> element for some other reason (I assume some DHTML/Ajaxy thing): just do that. Put <input> into the component's template. Come up with your own way of assigning a name and/or id. Tapestry won't care. On Mon, Mar 9, 2009 at 11:20 AM, Andrea Chiumenti <[email protected]> wrote: > 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] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
