tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: [jira] Commented: (TAPESTRY-517) Using a FieldLabel component after the decorated form component causes the FieldLabel's id attribute to be wrong
Date Wed, 07 Sep 2005 21:30:23 GMT
Didn't mean to jab at you; I'm trying to fix a lot of bugs and pay the
mortgage, so I lose track of some little things.

The static structure of Tapestry makes this coordination pretty difficult.

I think the best thing would be to add a "prerender" parameter to
ListEdit that would default on, and can be turned off in the case that
the FieldLabel occurs after the field.

Yes, it would be nice if they could play well together. 

It's possible that a future, and much different, version of Tapestry
will do two passes over the render tree to handle situations like
this.

On 9/7/05, Jonas Maurus (JIRA) <tapestry-dev@jakarta.apache.org> wrote:
>     [ http://issues.apache.org/jira/browse/TAPESTRY-517?page=comments#action_12322826
]
> 
> Jonas Maurus commented on TAPESTRY-517:
> ---------------------------------------
> 
> I honestly don't know why I feel attacked by you, but you didn't say that this is hard
to fix, at least not in any official comments you've made.
> 
> Of course, _I know it's hard to fix_, otherwise I'd have a well thought-out patch by
now. I _explicitly_ called my code a work-around, because _it is_ bad design. I described
3 additional approaches to fix the problem, none of which I feel would be able to land in
time for 4.0 final because they'd  break existing components and change existing contracts
or introduce more bad design, but at the component level. Providing the one component where
this bug manifests itself right now with a work-around parameter, which was your suggestion,
only pushes the bug down the road to be rediscovered by (I'd guess) primarily AJAX components
and makes handling FieldLabel's awkward.
> 
> Not fixing this bug would mean to ship Tapestry with components that work only if they're
used in a certain order, which is, I'd say, _worse_. Especially since they don't fail "gracefully".
> 
> At the center of the problem is Tapestry's quirky identity concept, which might even
be a primary cause for quick page rendering and low memory consumption, so it probably should
be kept that way, but it doesn't allow simple loop-handling, I've documented that in my other
comments on this bug.
> 
> I believe more and more that my last comment (changing IdAllocator so it can "look into
the future") is the way to go. I'm experimenting with different approaches in my spare time.
Nevertheless, I seem to remember seeing multiple ways to get Ids in the current Tapestry codebase,
so this would have to be unified first, then handling Ids should probably become a HiveMind
service. I'm still trying to make loop-handling transparent, so a component doesn't have to
know it's in a loop and a "looping component" doesn't have to do any special handling, but
this is not easily done. Making it possible to prerender a page's "identity tree" is my current
idea that I'm experimenting with.
> 
> I've called for developer input multiple times, in JIRA and on the mailing list and received
no reply. If there existed a consensus on how to fix this for 4.0, I'd be more than willing
to fix this properly, but I'll be out of the country during the last two weeks of september.
I don't mind working on this until then and after coming back and I'd welcome any help. Perhaps
you could outline what mechanism you're thinking of, then, at least, there'd be a goal to
work toward.
> 
> 
> > Using a FieldLabel component after the decorated form component causes the FieldLabel's
id attribute to be wrong
> > ----------------------------------------------------------------------------------------------------------------
> >
> >          Key: TAPESTRY-517
> >          URL: http://issues.apache.org/jira/browse/TAPESTRY-517
> >      Project: Tapestry
> >         Type: Bug
> >   Components: Framework
> >     Versions: 4.0
> >     Reporter: Jonas Maurus
> >     Assignee: Howard M. Lewis Ship
> >  Attachments: AbstractFormComponent.clientid_fix.diff, AbstractFormComponent.clientid_fix_2.diff,
AbstractFormComponent.clientid_fix_3.diff, AbstractFormComponent.clientid_fix_4.diff, AbstractFormComponent.clientid_fix_cvs_HEAD_20050825_1358.diff,
TAPESTRY-517.clientid_fix.diff
> >
> > Quoting from TAPESTRY-409:
> > <!-- page definition -->
> >   <component id="bookkeeperRCB" type="Checkbox">
> >     <binding name="selected" value="hasBookkeeperRole" />
> >   </component>
> >
> >   <component id="adminRCB" type="Checkbox">
> >     <binding name="selected" value="hasAdministratorRole" />
> >   </component>
> > <!-- page template -->
> > <tr>
> >   <td><input jwcid="bookkeeperRCB" type="checkbox" value="Y" /></td>
> >   <td><label jwcid="@FieldLabel" for="bookkeeper"
> >             field="ognl:components.bookkeeperRCB" displayName="message:form.roles.bookkeeper">Bookkeeper</label></td>
> > </tr>
> > <tr>
> >   <td><input jwcid="adminRCB" type="checkbox" value="Y" /></td>
> >   <td><label jwcid="@FieldLabel" for="admin"
> >            field="ognl:components.adminRCB" displayName="message:form.roles.administrator">Administrator</label></td>
> > </tr>
> > yields:
> > <tr>
> >   <td><input type="checkbox" name="bookkeeperRCB" id="bookkeeperRCB" value="Y"/></td>
> >   <td><label for="bookkeeperRCB$0">Bookkeeper</label></td>
> > </tr>
> > <tr>
> >   <td><input type="checkbox" name="adminRCB" checked="checked" id="adminRCB"
value="Y"/></td>
> >   <td><label for="adminRCB$0">Administrator</label></td>
> > </tr>
> > as you can see the generated fieldnames ("bookkeeperRCB$0"...) are wrong. This always
results in a stale-link exception.
> > I tracked down the bug: FieldLabel calls prerenderField() which in turn causes an
uniqueId to be allocated in AbstractFormComponent.renderIdAttribute. Everything works out
when the FieldLabel precedes the form component it decorates. If it comes after the form component,
IRequestCycle.getUniqueId() will already have stored an id for the component and return a
new one.
> > I'm not quite sure about the mechanics described above, as I don't fully understand
FormSupportImpl yet, perhaps someone else can shed light on this.
> > However, the allocated client id wasn't cached properly in AbstractFormComponent.renderIdAttribute.
I'll attach a patch as soon as I've saved this bug report.
> 
> --
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message