You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by "Gogineni, Pratima" <pg...@selectica.com> on 2005/02/15 19:12:29 UTC

RE: [digester] Portion of configuration handled by a different pr ocessor.

Sorry about that I have now added digester in the subject.

I think a custom rule class similar to the nodecreaterule will work in my
scenario. The plugin still seems to assume that digester would be handling
the rules for the plugin classes (even though we get the flexibility of
adding these rules dynamically). 

Thanks
Pratima

-----Original Message-----
From: Simon Kitching [mailto:skitching@apache.org]
Sent: Monday, February 14, 2005 6:11 PM
To: Jakarta Commons Users List
Subject: Re: Portion of configuration handled by a different processor.


Hi Pratima,

On Mon, 2005-02-14 at 17:37 -0800, Gogineni, Pratima wrote:
> Hi,
> 
> I have a weird requirement that Im trying to figure out how to address
with
> the digester.

Firstly, could you please prefix your email subject lines with
[digester]? Because this is a list shared by multiple commons projects
that makes life easier for everyone.


> To Illustrate:
> 
> <configuration>
> <config1...>
> <config2...>
> <handler>
> <type = "com.test.handler1"/>
> <extrainfo><tag1></tag1><config name="abc"/></extrainfo>
> </handler>
> <config3...>
> </configuration>
> 
> I have rules created for config1, config2 and config3 tags in digester.
when
> I hit the <handler> tag - I would like to instantiate com.test.Handler1
and
> pass the data under extrainfo as a  "String" or "Reader" or "InputStream"
to
> the handler. 
> 
> It would be preferable to pass the current stream rather than a string to
my
> handler because i will also be processing the tags and would not like the
> overhead of converting this to a string and then reparsing.

I would suggest having a look at the CreateNodeRule, which can build a
DOM representation of a section of the input. That DOM can then be
passed to an arbitrary method on the top object on the digester stack
for processing.

If this doesn't suit, then I suggest you have a look at the source code
for CreateNodeRule; you might get inspiration for how to code a custom
Rule class of your own.

Before doing any of that, though, I suggest looking at the "plugins"
package for digester (esp. the package description page of the javadoc).
It might just do what you want.

Regards,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


RE: [digester] Portion of configuration handled by a different pr ocessor.

Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2005-02-15 at 10:12 -0800, Gogineni, Pratima wrote:
> I think a custom rule class similar to the nodecreaterule will work in my
> scenario. The plugin still seems to assume that digester would be handling
> the rules for the plugin classes (even though we get the flexibility of
> adding these rules dynamically). 

Yes, using digester plugins means using digester rules to process the
associated xml input.

If your goal is to integrate code that *already implements* its own
initialisation code by parsing an input xml stream, then I expect
creating a custom rule to pass the xml to that object is the way to go.

Of course well-designed code really should separate configuration code
from the business-logic code. And the digester plugins package does that
quite cleanly. So if the plugin classes you are trying to integrate
don't yet have any configuration/initialisation code, I would recommend
a good look at plugins.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org