commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: New sandbox component: at-digester
Date Thu, 07 Jan 2010 01:27:12 GMT
One option to consider, if you want, is to branch digester into the
sandbox and work on it that way. In case trying to treat it as an
extension gets too painful.

Hen

On Wed, Jan 6, 2010 at 5:15 AM, Simone Tripodi <simone.tripodi@gmail.com> wrote:
> Hi Jochen,
> first of all nice to meet you :) There are not differences since mine
> is an extension that uses annotations to build the Digester, I
> proposed the sandbox because is not complete, once terminated I'll
> propose to merge the sanbox code in the proper one.
> Have a nice day, best regards,
> Simo
>
> On Wed, Jan 6, 2010 at 2:02 PM, Jochen Wiedmann
> <jochen.wiedmann@gmail.com> wrote:
>> What is the difference between this and the digester? Why is it a new
>> project and can't it be integrated into the existing?
>>
>>
>>
>> On Wed, Jan 6, 2010 at 1:38 PM, Simone Tripodi <simone.tripodi@gmail.com> wrote:
>>> Hi all guys
>>> As a new ASF committer, I'm setting up a new Commons Sandbox, called "@Digester"
>>>
>>> @Digester
>>>
>>> The Apache commons-digester[1] is a great, light and fast XML parser;
>>> it works with the SAX APIs and provides a serie of facilities to map
>>> XML to POJOs.
>>> It's configurable in the following ways:
>>> * instancing and registering digester's rules into the digester;
>>> * using the shorthand registration methods
>>> * XML digester rules.
>>>
>>> Even if these methods are excellent, they are limited - if Java
>>> objects are due to be changed quickly, all previous methods need to be
>>> extended/modified.
>>>
>>> Inspired by the basic idea behind the JPA, JAXB's specifications, the
>>> digester-annotations package would add some facilities to configure
>>> the commons-digester using the Java5 language metadata annotations
>>> support, it means creating the digester ruleset introspecting the
>>> target POJOs, using a provided set of annotations. Using the annotated
>>> Java object it's possible to create, in runtime the digester parser,
>>> avoiding manual updates.
>>>
>>> I mean, for example, given the following XML snippet
>>>
>>> <web-app>
>>> [...]
>>>   <servlet>
>>>       <servlet-name>action</servlet-name>
>>>       <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
>>>       <init-param>
>>>           <param-name>application</param-name>
>>>           <param-value>org.apache.struts.example.ApplicationResources</param-value>
>>>       </init-param>
>>>       <init-param>
>>>           <param-name>config</param-name>
>>>           <param-value>/WEB-INF/struts-config.xml</param-value>
>>>       </init-param>
>>>   </servlet>
>>> [...]
>>> </web-app>
>>>
>>> It could be mapped as
>>>
>>> @ObjectCreate("web-app/servlet")
>>> public final class ServletBean {
>>>
>>>   @BeanPropertySetter("web-app/servlet/servlet-name")
>>>   private String servletName;
>>>
>>>   @BeanPropertySetter("web-app/servlet/servlet-class")
>>>   private String servletClass;
>>>
>>>   private final Map<String, String> initParams = new HashMap<String,
>>> String>();
>>>
>>>   public String getServletName() {
>>>       return this.servletName;
>>>   }
>>>
>>>   public void setServletName(String servletName) {
>>>       this.servletName = servletName;
>>>   }
>>>
>>>   public String getServletClass() {
>>>       return this.servletClass;
>>>   }
>>>
>>>   public void setServletClass(String servletClass) {
>>>       this.servletClass = servletClass;
>>>   }
>>>
>>>   @CallMethod("web-app/servlet/init-param")
>>>   public void
>>> addInitParam(@CallParam("web-app/servlet/init-param/param-name")
>>> String name,
>>>           @CallParam("web-app/servlet/init-param/param-value") String value)
{
>>>       this.initParams.put(name, value);
>>>   }
>>>
>>>   [...]
>>>
>>> }
>>>
>>> and a special DigesterLoader is able to create Digester rules simply
>>> by analizing the ServletBean class:
>>>
>>> Digester digester = DigesterLoader.createDigester(ServletBean.class);
>>>
>>> Of course, this approach has limitations too - i.e. it doesn't work
>>> with 3rd part developed objects - but the combined use of the
>>> different approaches should reduce the manually produced code.
>>>
>>> Current status of code:
>>> I've already done almoust the 80% of code on google-code[2] licensed
>>> under ASF2 license and also submitted a deprecated patch[3] on
>>> commons-digester Jira: I would like to remove the
>>> project on google-code and complete the work in
>>> the sandbox, then re-propose to commons-digester community the new
>>> feature.
>>>
>>> I really hope you'll find this new way of parsing XML interesting like I do :P
>>> Thanks in advance, best regards!!!
>>> Simone Tripodi
>>>
>>> [1] http://commons.apache.org/digester/
>>> [2] http://code.google.com/p/digester-annotations/source/browse/
>>> [3] https://issues.apache.org/jira/browse/DIGESTER-135
>>>
>>> --
>>> http://www.google.com/profiles/simone.tripodi
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> --
>> Germanys national anthem is the most boring in the world - how telling!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> --
> http://www.google.com/profiles/simone.tripodi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message