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

Bug 360371

Summary:

Allow subclasses to override default element naming in XML list binding

Product:

z_Archived

Reporter:

Rob Cernich <rcernich>

Component:

Sapphire

Assignee:

Konstantin Komissarchik <konstantin>

Status:

CLOSED FIXED

QA Contact:

Severity:

enhancement

Priority:

CC:

konstantin

Version:

unspecified

Keywords:

plan

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Proposed Implementation	konstantin: iplog+

Description Rob Cernich

2011-10-09 18:12:58 EDT

Build Identifier: 

Extenders should be able to provide a customized element naming scheme.  This is useful when possible types are provided through a custom service.

In my case, I'm using XmlRootBinding to generate element names for unmapped types contributed through a custom PossibleTypesService.

Reproducible: Always

Comment 1 Rob Cernich

2011-10-09 18:15:44 EDT

Created attachment 204847 [details]
Proposed Implementation

Simply created a protected method that can be overridden by extenders.  Default implementation provides the same default naming in the current implementation.

Comment 2 Konstantin Komissarchik

2011-10-10 11:56:47 EDT

This scenario is handled in the current API by overriding the protected initBindingMetadata method. Is there something that you were not able to implement using that API?

Comment 3 Rob Cernich

2011-10-10 12:48:19 EDT

(In reply to comment #2)
> This scenario is handled in the current API by overriding the protected
> initBindingMetadata method. Is there something that you were not able to
> implement using that API?

This is a possible solution, but it requires duplicating the entire initBindingMetadata() implementation within StandardXmlListBindingImpl, which is less than ideal.

This is because the current implementation does not allow one to simply provide element names for only the dynamically contributed types, which means one has to:
1. Iterate the entire list of names.
2. Generate a default name for each entry.
3. Test to see if the name matches the default.
4. Update the name, if necessary (possibly inadvertently overriding a mapped name with my default value, in the event the mapped name matches the default name).

At that point, simply copying the entire implementation and swapping out the portion that generates the default name becomes the simpler option.  Ideally, being able to substitute my own algorithm for producing default names is much simpler (and more usable).

Adding the proposed method into the API gives extenders the ability to provide the best default for their application.

Here is the basic use case:
1.  A container holds some type of element.
2.  That type may be specialized by extensions.
3.  A set of extensions is well known and incorporated into the model using mappings.
4.  A set of extensions is contributed dynamically through other plugins.  These extensions are added through a PossibleTypesService.
5.  The specialized custom binding implementation should only have to initialize binding metadata for the dynamically contributed extensions.

I think you could also argue that being able to specify a custom default naming algorithm would be useful for other, simpler cases, e.g specifying a namespace, using names that are all lower case, using hyphens instead of camel case, etc.

Comment 4 Konstantin Komissarchik

2011-10-11 12:30:00 EDT

Thanks for the explanation. I have accepted your patch after adding javadoc for the new method and making sure that the same method is called from the other branch in initBindingMetadata.

Please verify.

I also like your proposal in the forum to annotate the type with default xml element name. Please make sure to open an enhancement request to track that idea too. The two approaches can co-exist.

Comment 5 Rob Cernich

2011-11-28 14:58:13 EST

adopters can now override the default naming scheme.

Comment 6 Rob Cernich

2011-11-28 14:58:26 EST

closed.