[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689035#action_12689035 ]
Johan Compagner commented on WICKET-2111: ----------------------------------------- but with the additions of the IMarkupId it is becoming a mess. Then we should really try to clean it up, in a nice getter/setter and a factory (2 could have 2 getters if that boolean is important) Is it for the outside world also really important to have access to the instanceof IMarkupId ? > 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.