Oh and BTW - i do know that i could accomplish this just by simply using
XSLT transformation after full serialization but my main goal is efficiency.
The object tree i mentioned below is really a "hibernated" domain model with
lazy-resolved relationships.
I cannot explode the whole graph because it would create enormous level of
database activity.
That is why the XML version needs to be suppressed during serializations and
calls to java/lang/Method.invoke() by betwixt must be avoided at all cost if
the resultant objects don't participate in the suppressed XML tree.
On 10/13/05, Maciek Kolesnik <[EMAIL PROTECTED]> wrote:
>
>
> 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]
> >
> >
>
