Immutability of buri.ddmsence.ddms.Resource

[Catchwa]

Hi,

Is there any way to get around the immutability of the Resource
object? I have a use case where I need to:

1. Read in a String (of DDMS)
2. Use the DDMSReader to parse the String into a Resource.
3. Update a single field in the Resource.
4. Stream out the Resource back out to a String.

The only way I seem to be able to do it right now is to create a brand
new Resource and set all the fields based on the original except for
the one I want to change.

Cheers,

Andrew

[Brian Uri!]

Hi Andrew,

This is a definite gap in the supported use cases: DDMSence works well
to read existing DDMS records or write new ones, but was not
originally designed to EDIT existing records. I have opened a ticket
to see if there's a way it can be supported:
http://code.google.com/p/ddmsence/issues/detail?id=68

In the meantime, I see two ways to get around this limitation:

1) A clean way to consider would be to make the changes at an XML
level. If the changes are programmatic enough (i.e. every creator is
changing to Jon, or every title will now have the prefix "AUS-") they
could be applied to an XML DDMS record with XSL. Then, the string read
into the DDMSReader would already have the changes applied.

2) If the changes could be open-ended (i.e. placed in a GUI for user
input), have complex dependencies on existing data, or you aren't
comfortable with XSL, the Java approach you outlined in your post is
the only recourse today.

Regards,
BU

[Brian Uri!]

Hi Andrew,

This is something I've been playing around with in my head for a few weeks now, and I'm hoping to have some time in the spring to try out a few implementations.

What I'm thinking of at the moment is a set Builder classes, one for each DDMSComponent, with the same accessors. This set of classes would differ from the current components as follows:

1) Each Builder would incorporate a setXxxx() method which alters a field without validation.
2) A Builder would be stateful, and could either be initialized empty or loaded from a DDMSComponent.
3) A Builder would not validate until you were to commit(). The result of a commit() would either be a set of errors or a new DDMSComponent.
4) A Builder would not include the DDMSComponent output methods like toXml(), because it represents a component in limbo of creation.

I see the Builder idea as being most useful in a wizard-style building of DDMS bits over time. The bottoms-up approach shown in Tutorial #2 is passable, but there's really no way to store a DDMSComponent in any kind of form bean right now. By using, for example, a SubjectCoverageBuilder as the form bean, you could edit an existing component or just prevent validation from occurring until you're ready to finalize. The safety gained by immutability is also preserved with this approach.

Among the issues still to be worked out:

1) Whether every component should have its own Builder, or whether there should be a master ResourceBuilder with a single commit() that can build the subcomponents.
2) How to cleanly keep the immutable and builder versions of each component in sync and understandable.

I'll continue to brainstorm this, but feel free to chime in if something like this would work with your use case, or just misses the mark.

Regards,
BU

[Brian Uri!]

These changes are now incorporated into DDMSence 1.8.0. Happy Editing!

Regards,
BU