[ 
https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Juergen Donnerstag updated WICKET-2111:
---------------------------------------

    Attachment: wicket-2111.patch

I would go even one step further and introduce a IMarkupId type. Our current 
implementation not only lacks the flexibility mentioned above, the source code 
- for historic reasons - is rather awkward as well:
- two places where markupId are stored: Component.generatedMarkupId for integer 
and a MetaData entry for string markupIds
- the source code is scattered all over with "if (markupId instanceof Integer)" 
and  "if (markupId instanceof String)" 
- the API is using Object for the same reason
- set/getMarkupId and set/getMarkupIdImpl are rather confusing

The attached patch - which changes the API and hence can only be applied to 1.5 
- is an attempt to improve all that.
- removed generatedMarkupId and the MetaDataKey from Component
- added private IMarkupId markupId
- cleaned up set/getMarkupId and getMarkupIdImpl. Removed setMarkupIdImpl
- created an IMarkupId interface
- created a base class AbstractMarkupId
- created a DefaultMarkupId which uses an int. Can be subclassed to provide 
your own means to get to the int id.
- added Application.newMarkupId() to allow application wide to use your own 
IMarkupId implementation. Component.getMarkupId can be replaced by a subclass 
to provide a component specific IMarkupId implementation
- StringMarkupId is an string based markupId

I also updated ComponentSourceEntry and this is where I'm not 100% sure. Each 
IMarkupId must implement String getShortValue which is what is needed to 
automatically reconstruct the markupId. But different to our current 
implementation when the Component is reconstructed via 
ComponentSourceEntry.applyComponentInfo a StringMarkupId will be created 
irrespective of what type markupId was before. Since the markupId will not be 
modified it should just be fine. 

Some test cases fail but that is only because sequence.nextValue() is invoked 
in a slightly different order. All other tests are successful.

> 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.

Reply via email to