[
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
A new attempt on the topic:
- generated markup ID (int) and the meta data are still there and maintained by
the Component => no change. We still have min overhead for ajax heavy pages
with generated IDs
- Setter: No more "Object" and "instanceof String" or "instanceof Integer", and
no more public setMarkupIdImpl(). Users will only see one method
setMarkupId(String).
// what users will use. A thin wrapper only
public final Component setMarkupId(final String markupId)
// Used to set generated ID. No need for users to use directly. Not
private, but hidden, since required by ComponentSourceEntry. A thin wrapper
final Component setMarkupId(final int markupId)
// copies markupID settings from "comp". Required by
MarkupContainer.replace(). hidden. A thin wrapper
final Component setMarkupId(final Component comp)
// private; low level work; set generatedMarkupId and metakey
private final void setMarkupId(final int iId, final String sId)
- Getter: similar API but at least IMO clearer with respect to what they do and
thus simpler to understand
// public; non-final (can be replaced by user). Find the markup
starting with the markup itself, than check the generated Id, than meta data,
and optionally a global strategy.
// In case of the generated ID, the "int" will be converted into a W3C
compliant string etc. => getMarkupImpl() is responsible to convert the internal
representation into an external one (return value is a String)
public String getMarkupIdImpl()
// A little helper: make sure the ID is W3C compliant
private String makeMarkupIdCompliant(String markupId)
// Some of the logik around generated ID has been moved into
getMarkupIdImpl() as explained above which IMO assigns clear responsibilities
to each and makes it easier to read. This also allowed to make getMarkupId()
final (all methods are final except getMarkupIdImpl)
public final String getMarkupId(boolean createIfDoesNotExist)
// As before. no change
public final String getMarkupId()
- Introduces a global strategy with a simple interface which is invoked during
getMarkupIdImpl() if no other ID was found. This way you can register a
strategy during development and simplify testing with the various tools around.
In prod you'd use generated ID enjoying optimized performance
String getMarkupId(Component component);
feedback and comments are welcome
> 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.
