Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 392526

Summary:	Allow a pluggable custom id generator (for testing)
Product:	[RT] RAP	Reporter:	Thomas Kratz <eiswind>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	mknauer, rsternberg
Version:	2.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Thomas Kratz

2012-10-21 08:01:59 EDT

I did a little hack for testing purposes to get contribution item ids rendered in testing mode.
https://gist.github.com/3321417

It would be great and not so hackish if we could plugin ID generators.

Comment 1 Ralf Sternberg

2013-01-22 07:55:38 EST

As of RAP 2.0M4, there's an internal interface IdGenerator. A custom implementation of this interface can be registered with the system property (see the JavaDoc of the interface for details). If this approach proves helpful, we can consider publishing the interface as API.

Comment 2 Ralf Sternberg

2013-02-14 10:22:46 EST

It turned out that this approach goes too short as the IdGenerator is called at construction time of a widget. At this point in time, widgets are not yet configured and provide little clues for a custom id.

I'm looking into a solution that would defer the creation of ids until it is actually required, e.g. by the message renderer.

Comment 3 Thomas Kratz

2013-06-07 04:59:55 EDT

Hey Ralf,

I'm currently also investigating Q7 for my tests, but I'm still intereted in a general solution for injecting at least some widget data somehow if not for testing then for tracking purposes.

Comment 4 Ralf Sternberg

2013-06-16 07:44:29 EDT

Thomas, you can still use WidgetUtil.CUSTOM_WIDGET_ID.

I would, however, not recommend to manipulate the widget ids. I've learned that UI test ids are often not unique, and non-unique custom widget ids would result in errors that are hard to track down.

An alternative approach is to use a PhaseListener that adds an additional DOM element to every widget. Here's an example:

https://gist.github.com/ralfstx/5791804

Comment 5 Ralf Sternberg

2013-06-16 08:03:01 EDT

Custom widget IDs have once been introduced to provide more stable IDs for load tests. We may be able to make the protocol IDs more stable (bug 410886) and get rid of the need for custom widget IDs altogether.

For UI tests, the approach outlined in comment 4 could be a better alternative. If this approach works out, we may encapsulate it in some Util class.