[
https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688811#action_12688811
]
Johan Compagner commented on WICKET-2111:
-----------------------------------------
hmm do we really need 3 public none final method get starts with
getMarkupXXXXX()?
so they can override everything AND also have Application:
public IMarkupId newMarkupId(final Component component)
and besides that, the method that is removed i want to keep...
setMarkupId(String)
Thats what uses get, now they have to wrap and know about StringMarkupId??
Why do we need to have:
public final Component setMarkupId(final IMarkupId markupId)
Because now we can set it but we also have a getter
why not have something like this:
public final String getMarkupId()
{
if (markupId == null)
{
markupId = createMarkupId();
}
return markupId.toString();
}
public final Component setMarkupId(String)
{
markupId = new StringMarkupId(string);
}
public IMarkupId createMarkupId()
{
markupId = getApplication().newMarkupId(this);
}
Who uses by the way the should create boolean? I dont see any reference to it
in our methods.?
for example the patch has a bug:
public String getMarkupId(boolean createIfDoesNotExist)
{
return getMarkupIdImpl(createIfDoesNotExist).toString(this);
}
that bombs out big time now with a null pointer if the boolean is false.
But users who needs the create boolean can overwrite the createMarkupId and
dont let it happen?
> 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.
