[ 
https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934386#action_12934386
 ] 

Igor Vaynberg commented on WICKET-2111:
---------------------------------------

do we need private transient String markupId; its a big penalty to add a 
runtime slot to all components when it will mostly go unused.

ive been thinking about how to fix this mess we have with multiple setters, etc.

what if:

we generate the integer id like we do now, automatically. but, on output we 
encode it into the [a-zA-Z0-9]+ alphabet. then we have a single setter that 
takes a string, and if it can be parsed back into an integer we set the 
generated int id to the parsed integer. the internals will be much simpler as 
well if we do this.

a nice sideeffect is that ids will become much shorter. instead of "id53" it 
can be "idZ" and instead of "id1000" it will be "idyQ" or whatever the encoded 
version will be.

> Ability to generate markup ids in alternate fashion
> ---------------------------------------------------
>
>                 Key: WICKET-2111
>                 URL: https://issues.apache.org/jira/browse/WICKET-2111
>             Project: Wicket
>          Issue Type: Improvement
>    Affects Versions: 1.3.5, 1.3.6, 1.4-RC3
>            Reporter: Berry van Halderen
>             Fix For: 1.5-M4
>
>         Attachments: patch, wicket-2111.patch, wicket-2111.patch
>
>
> In the attempts to setup integrated testing one particular piece of wicket 
> code isn't quite extendible enough for our needs, which is the generation of 
> markup ids by the wicket session class. The ability to extend this 
> functionality is not limited to the particular use case, I'd like to propose 
> a small change. 
> The issue is the following; when a Component has no explicit markup-id set, 
> the markup id is generated by the Session which has an internal counter and 
> uses an increment of this to generate a mark-id.  The flaw IMHO is that a 
> Component requests the Session to generate an id, without passing it any 
> context.  Especially the most logical context, i.e. "please session, generate 
> a markup id for _ME_" is missing.  Therefore I'd propose that the 
> Session.getMarkupId() is passes the Component object for which the markup id 
> is to be generated.
> By default, the operation should remain as is and the Session object falls 
> back to the default getMarkupId() without parameters, which is already 
> overrideable.  But now you can override the getMarkupId() and generate more 
> useful markup ids.
> In our case, we are able to generate markup ids which contain part of the 
> hierarchy and in this manner generate stable Ids, namely those which do not 
> change after several requests.  This particular usage may just work for our 
> case (one page application, no back-button support, etc), but the fundamental 
> overrideable method to generate more useful IDs is more widely applicable, 
> hence this change request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to