[jira] Issue Comment Edited: (WICKET-2111) Ability to generate markup ids in alternate fashion

["Matej Knopp (JIRA)" <ji...@apache.org>]

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

Matej Knopp edited comment on WICKET-2111 at 3/25/09 12:35 PM:
---------------------------------------------------------------

Guys, before you throw around ideas like IMarkupId and markup ids as strings please consider that the Component itself has been profiled a lot and there is very good reason why the internals look as they do (even though the code is not pretty). In one project (rather ajax heavy) storing component data as Object and having used only int slot for markup id has reduced the memory consumed by wicket components by 30-40% on certain pages.

If you have lot of ajax enabled components a string field for markup id is a *huge* waste of memory.

      was (Author: knopp):
    Guys, before you throw around ideas like IMarkupId and markup ids as strings please consider that the Component itself has been profiled a lot and there is very good why the internals look as they do (even though the code is not pretty). In one project (rather ajax heavy) storing component data as Object and having used only int slot for markup id has reduced the memory consumed by wicket components by 30-40% on certain pages.

If you have lot of ajax enabled components a string field for markup id is a *huge* waste of memory.
  
> 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.3.6, 1.4-RC3
>
>         Attachments: 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.