castor

Enhancement: two new features to control Source Generator collection method generation

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 0.9.5
  • Fix Version/s: None
  • Component/s: XML code generator
  • Labels:
    None
  • Environment:
    Operating System: All
    Platform: All
  • Bugzilla Id:
    1331
  • Number of attachments :
    0

Description

1) Source Generator by default exposes collections only as arrays. When
o.e.c.b.extraCollectionMethods is set to true, it also exposes the underlying collection object, but
only as an afterthought. It would be nice to have the option to have the collection accessors be
the primary "bean-like" methods for generated objects.

2) When generating fields/methods in Java 2 mode, Source Generator uses ArrayLists as a drop-in
replacement for Vectors. This overlooks the flexibility possible with Java 2 collections. It would be
better to use parameters/return values of type List so that code that uses the generated object
model are not forced to convert to/from ArrayLists.

I'll attach a patch and one new class that implements these two features. They are disabled by
default, but may be enabled through properties in castorbuilder.properties.

There are no Sub-Tasks for this issue.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
rhett-sutphin added a comment -

Created an attachment (id=293)
Patch to Source Generator implementing these enhancements

Show
rhett-sutphin added a comment - Created an attachment (id=293) Patch to Source Generator implementing these enhancements
Hide
Permalink
rhett-sutphin added a comment -

Created an attachment (id=294)
New class: org.exolab.castor.builder.types.XSListj2AsInterface

Show
rhett-sutphin added a comment - Created an attachment (id=294) New class: org.exolab.castor.builder.types.XSListj2AsInterface
Hide
Permalink
rhett-sutphin added a comment -

The implementation contained in the above two attachments provides for three new properties:

o.e.c.b.collections.copy.suffix
A string property like the mostly undocumented o.e.c.b.collections.reference.suffix, except for
set-by-copy methods. Default is the empty string. Has no effect if not using
o.e.c.b.extraCollectionMethods.

o.e.c.b.collections.array.suffix
Also like reference.suffix, except for get-by- and set-by-array methods. Note that the set-by-
array methods get this suffix, even though they are also set-by-copy methods. Default is the
empty string. The user must take care that array.suffix and reference.suffix are not the same,
otherwise his/her code won't compile – it will have two methods with the same signature.

o.e.c.b.collections.useInterfaces
A boolean property that indicates that SG should not explicitly use ArrayList declarations for
collection handling. Specifically:

  • Declaration of a collection - use List. (Note that default initialization is still ArrayList.)
  • get[Element]ByReference - return List.
  • set[Element]ByReference(element) - parameter is a List
  • set[Element](elementCollection) - parameter is a Collection. (This patch also changes the
    generated implementation to use an Iterator instead of direct access.)
    Default is false. Has no effect if not using -types j2.

I've run both the MasterTestSuite and the RegressionTestSuite against the SG with this patch
applied and nothing failed that didn't also fail in the released version 0.9.5.

Show
rhett-sutphin added a comment - The implementation contained in the above two attachments provides for three new properties: o.e.c.b.collections.copy.suffix A string property like the mostly undocumented o.e.c.b.collections.reference.suffix, except for set-by-copy methods. Default is the empty string. Has no effect if not using o.e.c.b.extraCollectionMethods. o.e.c.b.collections.array.suffix Also like reference.suffix, except for get-by- and set-by-array methods. Note that the set-by- array methods get this suffix, even though they are also set-by-copy methods. Default is the empty string. The user must take care that array.suffix and reference.suffix are not the same, otherwise his/her code won't compile – it will have two methods with the same signature. o.e.c.b.collections.useInterfaces A boolean property that indicates that SG should not explicitly use ArrayList declarations for collection handling. Specifically: Declaration of a collection - use List. (Note that default initialization is still ArrayList.) get [Element] ByReference - return List. set [Element] ByReference(element) - parameter is a List set [Element] (elementCollection) - parameter is a Collection. (This patch also changes the generated implementation to use an Iterator instead of direct access.) Default is false. Has no effect if not using -types j2. I've run both the MasterTestSuite and the RegressionTestSuite against the SG with this patch applied and nothing failed that didn't also fail in the released version 0.9.5.
Hide
Permalink
Keith Visco added a comment -

Reassigning to Arnaud for review. Adding self to cc.

Show
Keith Visco added a comment - Reassigning to Arnaud for review. Adding self to cc.
Hide
Permalink
Werner Guttmann added a comment -

I wonder whether you'd still be in a position to attach your patch again (even if it'S been years since you attached the original patch).

Show
Werner Guttmann added a comment - I wonder whether you'd still be in a position to attach your patch again (even if it'S been years since you attached the original patch).
Hide
Permalink
Werner Guttmann added a comment -

Rhett, any feedback ?

Show
Werner Guttmann added a comment - Rhett, any feedback ?

People

  • Assignee:
    Werner Guttmann
    Reporter:
    rhett-sutphin
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:

Time Tracking

Estimated:
1h 30m
Original Estimate - 1 hour, 30 minutes
Remaining:
30m
Time Spent - 1 hour Remaining Estimate - 30 minutes
Logged:
1h
Time Spent - 1 hour Remaining Estimate - 30 minutes