Tapestry 5.4 Select: Can't stop tapestry generating it's own clientId

[Lance Java <la...@googlemail.com>]

I'm trying to do some ajax with tapestry 5.4 and no matter what I do, I
can't stop tapestry from generating it's own clientId.

TML:

<t:select t:id="category" t:clientId="category" ... />
<t:zone t:id="makeZone">
   <t:select t:id="make" t:clientId="make" t:mixins="mycustommixin" ... />
</t:zone>
<t:zone t:id="modelZone">
   <t:select t:id="model" t:clientId="model" t:mixins="mycustommixin" ... />
</t:zone>


I update the zone(s) using some custom javascript:
   define(["jquery", "t5/core/zone"], function($, zoneManager) {
      return function(spec) {
        var $element = $('#' + spec.id);
        $element.on(spec.event, function() {
            zoneManager.deferredZoneUpdate(spec.zone, spec.url);
        });
    }

The first time the select fields are rendered, they have clientIds of
"make" and "model" as expected. But after ajax rendering, they have id's
like "make1_af42a49d19a" etc.

Is this expected behaviour? Since I've specified a clientId parameter I was
hoping this would override the auto-generation.

Note: Under the hood, AbstractField is calling
allocatedClientId = javaScriptSupport.allocateClientId(clientId);

Re: Tapestry 5.4 Select: Can't stop tapestry generating it's own clientId

[Lance Java <la...@googlemail.com>]

I was forced to add data- attributes to the fields and use jquery selectors
by the data attributes instead of by id. I can only assume these selectors
perform poorly compared with id selectors.

Having no way to set the id on a field is a pretty epic fail to me. I feel
this should be fixed before 5.4 is released.

Re: Tapestry 5.4 Select: Can't stop tapestry generating it's own clientId

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Wed, 21 May 2014 15:17:42 -0300, George Christman  
<gc...@cardaddy.com> wrote:

> Lance, I think I'm encountering a similar issue with the textfields. I  
> have a textfield nested in a ajaxformloop.

The code that generates the client ids for almost all Tapestry-provided  
form field components is the same, located in AbstractField, so that's  
expected, even if not what we want (yet).

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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

Re: Tapestry 5.4 Select: Can't stop tapestry generating it's own clientId

[George Christman <gc...@cardaddy.com>]

Lance, I think I'm encountering a similar issue with the textfields. I have
a textfield nested in a ajaxformloop. When I create a new row the textfield
gets the initial id of activityCode_a91bfdca926f. This is a required field,
so when I leave it blank and try to save the form I get the serverside
validation, but I do not get a highlighted field and that is because the id
changed to activityCode_1. Now the next save, tapestry will continue to use
activityCode_1 and highlight the field properly. Like you, I tried
providing my own id with clientId and it failed to work properly. I'm
thinking there is a bug with how tapestry generates the initial id before
saving.

Anybody have any thoughts?


On Thu, May 15, 2014 at 6:43 AM, Lance Java <la...@googlemail.com>wrote:

> https://issues.apache.org/jira/browse/TAP5-2331
>



-- 
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: Tapestry 5.4 Select: Can't stop tapestry generating it's own clientId

[Lance Java <la...@googlemail.com>]

https://issues.apache.org/jira/browse/TAP5-2331

Re: Tapestry 5.4 Select: Can't stop tapestry generating it's own clientId

[Thiago H de Paula Figueiredo <th...@gmail.com>]

On Mon, 12 May 2014 15:00:34 -0300, Lance Java <la...@googlemail.com>  
wrote:

> Note: Under the hood, AbstractField is calling
> allocatedClientId = javaScriptSupport.allocateClientId(clientId);

Yeah, this doesn't match the corresponding behavior in Zone, which uses  
the clientId as is if provided:
clientId = resources.isBound("id") ? idParameter :  
renderSupport.allocateClientId(resources);

I think the clientId should be respected if bound. JIRA please? :)

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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