You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Berry van Halderen (JIRA)" <ji...@apache.org> on 2009/02/17 20:29:02 UTC
[jira] Created: (WICKET-2111) Ability to generate markup ids in
alternate fashion
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
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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Matej Knopp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689205#action_12689205 ]
Matej Knopp commented on WICKET-2111:
-------------------------------------
There is good reason why markup id is stored as integer by default! In 99.99% cases the integer is only thing necessary to get component's markup id. There is no reason to store it as string. We did that and the runtime penalty was really noticeable. In case someone wants to override it, we store it as metadata. Thus we don't need String slot for markup id.
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689183#action_12689183 ]
Johan Compagner commented on WICKET-2111:
-----------------------------------------
yeah i dont get that either.
Why store it as an integer anyway?
Why not do Integer.toString(generatedValue) instead of new Integer(generatedValue)
So it should be always just a string.
But i am not against IMarkupId and a factory method in component that defaults to Application
We only should clean up that we only have 2 or 3 (if we really need the boolean) method to get/set it.
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-2111:
----------------------------------
Fix Version/s: (was: 1.4.0)
1.4.1
> 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.4.1
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674711#action_12674711 ]
Igor Vaynberg commented on WICKET-2111:
---------------------------------------
i am thinking perhaps we should have a IMarkupIdStrategy { String getMarkupId(Component); } instead of baking this into the session and forcing subclassing on that level.
> 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
>
>
> 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.
[jira] Issue Comment Edited: (WICKET-2111) Ability to generate
markup ids in alternate fashion
Posted by "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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Juergen Donnerstag (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689168#action_12689168 ]
Juergen Donnerstag commented on WICKET-2111:
--------------------------------------------
IMO the mess starts with both Component.generatedMarkupId and a Component MetaDataKey used for markupIds. Two variables for doing almost the same; and several places in the source code with "if (markupId instanceof Integer)" and "if (markupId instanceof String)".
The solution to that is introducing a IMarkuId which can either be Integer or String or whatever. At least IMarkupId has a meaining, whereas Object has not.
I think in general we are not too far.
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Berry van Halderen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Berry van Halderen updated WICKET-2111:
---------------------------------------
Attachment: patch
This is the change I propose as a patch to the released 1.3.5 distribution. This patch has been created in such a way that it is a drop in add-on functionality and allows all previous extensions and overrides to work correctly.
If you look at the patch, its a little bit more than just the new method, that's because the patch is fashioned in such a way that the change is 100% compatible with previous workings of wicket in casu markup ids. Also, the getMarkupId used to return just an integer, while a string as return value is a more useful return value in a more context aware environment. To be sure the behavior is completely non-intrusive and compatible there is a little bit of glue coded needed.
I can elaborate further if needed
> 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
>
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-2111:
----------------------------------
Fix Version/s: (was: 1.4-RC7)
1.4-RC8
> 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.4-RC8
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson updated WICKET-2111:
-------------------------------------
Fix Version/s: (was: 1.4-RC5)
1.4-RC6
> 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.4-RC6
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801945#action_12801945 ]
Igor Vaynberg commented on WICKET-2111:
---------------------------------------
yeah, and that is fine. the MarkupId can fix the componentid when tostring() is called. but this extra level of indirection should allow us to work around current hierarchy limitations.
> 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-M1
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-2111:
----------------------------------
Fix Version/s: 1.5-M2
(was: 1.5-M1)
> 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-M2
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689394#action_12689394 ]
Johan Compagner commented on WICKET-2111:
-----------------------------------------
Better would be if we just would go through the page instead of the session
But i guess this cant be done because the markupid is already ask for before the component hierarchy is complete? :(
Because on a page would be way better for people because then the id is already pretty stable by default..
I agree with matej that would should look out for a big memory usage hit.
This can also be solved by having something like IMarkupId but then the instances of IMarkupId should be "interned" so they should be immutable and pooled
Problem is that we then also have to take care of deserialization so that the interned value is returned. But this is something IMarkupId implementations can do.
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Carlo M. Camerino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801907#action_12801907 ]
Carlo M. Camerino commented on WICKET-2111:
-------------------------------------------
hi,
+1 for this. wicket component paths do work but on one hand, selenium is always having a hard time finding the component making it harder to find it in the page. maybe it can be included as a setting to make this work. what i do is i use another tool to generate an xpath expression. if it could be simpler and selenium ide can find it , it will be easier to use. thanks a lot
> 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-M1
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705922#action_12705922 ]
Igor Vaynberg commented on WICKET-2111:
---------------------------------------
i am curious to see a strategy that will help with generating stabler ids and yet making sure they are unique for each component on the page.
for testing tools we have the option to output the page-relative path of the component in a wicket:path attribute which can be used to identify components on the page and is more stable then the auto-generated id.
> 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.4-RC5
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-2111:
----------------------------------
Fix Version/s: 1.5-M3
(was: 1.5-M2)
> 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-M3
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson updated WICKET-2111:
-------------------------------------
Fix Version/s: (was: 1.5-M3)
1.5-M4
> 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
>
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-2111:
----------------------------------
Fix Version/s: (was: 1.4.1)
1.5-M1
> 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-M1
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson updated WICKET-2111:
-------------------------------------
Fix Version/s: (was: 1.4-RC3)
(was: 1.3.6)
1.4-RC4
> 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.4-RC4
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Matej Knopp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801938#action_12801938 ]
Matej Knopp commented on WICKET-2111:
-------------------------------------
Just keep in mind one thing. We need to remember the markup id after it's rendered. For "standard" markup Id we only need one integer (4 bytes, not a reference). Otherwise it costs lot of state for ajax heavy apps.
> 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-M1
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801908#action_12801908 ]
Igor Vaynberg commented on WICKET-2111:
---------------------------------------
hrm, an interesting idea maybe that getmarkupid() returns an opaque object: class MarkupId() { } and the id itself is obtained by calling a .tostring(). this is basically an indirection that would allow us to defer id generation until render time. this way, even if component is not yet added to the page we can regurn an id representation that can be passed on to other components.
> 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-M1
>
> 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Antony Stubbs (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705907#action_12705907 ]
Antony Stubbs commented on WICKET-2111:
---------------------------------------
+1 for this issue being addressed - stable generated id's are *highly* desirable for tools such has selenium-ide which build automated test cases based on finding components from their id.
> 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.4-RC5
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-2111:
----------------------------------
Fix Version/s: (was: 1.4-RC6)
1.4-RC7
> 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.4-RC7
>
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Juergen Donnerstag (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "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 commented on WICKET-2111:
-------------------------------------
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.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Juergen Donnerstag (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689011#action_12689011 ]
Juergen Donnerstag commented on WICKET-2111:
--------------------------------------------
IMO we don't need all the getXXX. Intend was to simplify / cleanup the internals, keeping the API close to how it is today, assuming it is as is for good reasons.
> 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.
[jira] Updated: (WICKET-2111) Ability to generate markup ids in
alternate fashion
Posted by "Jeremy Thomerson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeremy Thomerson updated WICKET-2111:
-------------------------------------
Fix Version/s: (was: 1.4-RC4)
1.4-RC5
> 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.4-RC5
>
> 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.