Briefly:
What I'm looking for is a plugable strategy that would allow custom code to
suppress descent into a sub tree of a graph during serialization process
based on custom rules (specified in that strategy). Ideally the strategy
would "surround" invocation to writeElement(...) sort of like in http filter
API - see why below.
My custom strategy depends on current position of the serializer (bean
writer) in the graph (position is represented as simple xpath) which is then
compared to predefined set of simple xpaths that specify which sub-trees to
suppress/filter-out.
It is important for my custom code to "surround" invocation to
writeElement(...) in order to properly maintain the xpath (using thread
local repository as shown in the code snippet below - there maybe better
ways of solving this if strategy instance is tied to a thread thru bean
writer instance).
More specifically about the problem I'm solving:
Given a full object tree like this:
<root>
<a>
<aa/>
<aa/>
</a>
<b>
<bb/>
</b>
<collection>
<c/>
<c/>
<c/>
</collection>
</root>
I want to suppress nodes and sub-tress defined using a set of simple xpaths
(don't care about full xpath language here - too slow for me).
(the whole xpath thing would be custom implementation of the suppression
strategy)
/root/a/aa
/root/collection
Suppressed tree would then look like this:
<root>
<a/>
<b>
<bb/>
</b>
</root>
Maciek
On 10/13/05, robert burrell donkin <[EMAIL PROTECTED]>
wrote:
>
> On Thu, 2005-10-13 at 16:56 -0400, Maciek Kolesnik wrote:
> > Hi,
>
> hi Maciek
>
> > I recently downloaded v0.7 of the betwixt. The tool does really a great
> job
> > - highly customizable and easy to use.
> > I do have a suggestion for a small improvement though:
> > As far as I know currently it is impossible to intercept the process of
> > descending into the object graph by a custom code.
>
> that's true
>
> i usually lean towards delegation (over inheritance) when developing
> library code since i've often observed that novel use cases that require
> refactoring call signature and sequences. this makes library design a
> little different from the design of applications or frameworks.
>
> > Changing signature of these 2 methods
> >
> > writeElement(...) (2 signatures)
> >
> > to protected would give me ability to suppress the descent into children
> > when contextually my code determines that it does not need to go any
> deeper
> > (optimization measure). Any other similar scheme where execution of
> > writeElement(...) can be conditionally prevented could do a job too i
> think.
>
> that sounds like an interesting use case :)
>
> probably generally useful as well
>
> > Here is how I would like to use it:
> > protected void writeElement(String namespaceUri, String localName,
> String
> > qualifiedName, ElementDescriptor elementDescriptor, Context context)
> throws
> > IOException, SAXException, IntrospectionException {
> >
> > String currentPath = (String) BeanSerializer.PATH.get();
> >
> > try {
> >
> > BeanSerializer.PATH.set(currentPath + "/" + localName);
> > //filter the descriptor based on in-context filter spec - cached by spec
> > id
> >
> > FilterSpec filterSpec = (FilterSpec)
> > CallContext.getCurrentContext().getAttribute(
> > FilterSpec.ATTR_XML_FILTER);
> >
> > if (filterSpec != null
> > && filterSpec.isSuppressed((String)BeanSerializer.PATH.get())) {
> > return;
> > }
> >
> > super.writeElement(namespaceUri, localName, qualifiedName,
> > elementDescriptor,
> > context);
> > } finally {
> > BeanSerializer.PATH.set(currentPath);
> > }
> > }
> > MyBeanSerializer.PATH is a ThreadLocal string that specifies current
> path
> > (like /A/B/C/D) and my isSuppressed method compares current path with a
> list
> > of paths to-be-suppressed.
>
> in general, IMHO this kind of thing is usually better addressed by
> another pluggable strategy (rather than subclassing).
>
> to create such a strategy, need to understand your use case in detail
> and think about the best way to generalize it.
>
> opinions?
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
