commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [Digester] How can I build a Calendar from XML pieces?
Date Wed, 09 Apr 2003 17:10:39 GMT
(i'd say that the right place for this discussion is probably the dev list.
  why not join us there?)

there really hasn't been a lot of thought put into the Rule lifecycle. 
there is a 'finish' method but (as you rightly point out) no corresponding 
method that is called after the rule has registered.

there are issues which need a little thought when it comes to retrofitting 
a better Rule lifecycle. the issue you note about the digester not being 
available isn't insummountable - correctly behaved Rules instances would 
just have to through re-initialize every added Rule when the Digester is 
changed. (they already have to call setDigester when this happens.)

probably given hindsight, setDigester would probably be better replaced by 
a lifecycle init method which passes in the digester instance and the 
pattern. digester will break horribly if the user goes round and sets that 
property.

the biggest change would be that there would be a change in the symantic 
Rules contract. rather than having to call setDigester, the lifecycle 
method would have to be called. this may cause incompatibility between 
custom Rules implementations and new Rule implementations that rely on the 
new lifecycle method.

anyway, as i said - this is a matter which would be better raised on the 
dev list. why not set up those mail filters and post a new thread there?

- robert

On Monday, April 7, 2003, at 11:52 PM, Simon Kitching wrote:

> Jason's issue seems related to an issue I have been giving some thought
> to recently.
>
> I would like to propose an enhancement to the digester code. This
> proposal is not fully thought out yet; there are some problems with the
> suggestion below that I don't yet know how to resolve, so I hadn't
> intended to put it forward yet. However, as we are on the topic :-)
>
> I propose that Rule classes have a "postRegisterInit" method, which is
> called after the rule has been added to the digester's Rules object.
>
> The abstract Rule class could define the method as:
>   public void postRegisterInit(String pattern) {}
>
> A Rules instance is required to do the following in the last line of its
> add(Rule) method:
>     rule.postRegisterInit(pattern);
>
> For Jason's case, the custom "CalendarRule" class could override this
> method to do:
>    digester.addBeanPropertySetter(pattern+"/date");
> etc
>
> The result is that whenever an instance of the CalendarRule is
> registered, a method on that instance is invoked in a way that allows
> the Rule to add any custom subrules below the pattern.
>
>
> Having such an initialisation method will also be useful to rules like
> CallMethodRule, which currently performs its "initialisation" within the
> setDigester method - a fairly ugly hack I think.
>
> And this functionality would be *very* useful to me in my "plugin"
> module for Digester, which allows the user to specify which subclass
> should be instantiated at various points in the input xml file, rather
> like Avalon's config files.
>
> The main problem with the "postRegisterInit" proposal is that rules can
> be added via the digester, or they can be added to a Rules object, and
> the Rules object then added to the digester. It would be nice to ensure
> that postRegisterInit is only called after the setDigester() method has
> been called on the rule, as its initialisation code may well depend upon
> the digester being available.
>
> Any comments??
>
> Regards,
>
> Simon
>
> On Tue, 2003-04-08 at 04:46, Jason Carreira wrote:
>> Is there any way to build re-usable components which have sub-rules?
>> i.e., if I created a CalendarRule, could I have it have sub-rules which
>> would get events for the <date> and <time> elements below the root which
>>   the CalendarRule is added to watch, no matter what path that was added
>> to monitor? Or do I have to create those other rules and always put them
>> into the digester by hand?
>>
>> Jason
>>
>> Jason Carreira wrote:
>>> Calendar = java.util.Calendar
>>>
>>> I was going to get one with a Calendar.getInstance().
>>>
>>> The problem with the BeanProperySetterRule and CallParamRule is that
>>> what I need to do is:
>>>
>>> 1) create a java.util.Date from the <date> element
>>> 2) call calendar.set(date.getYear(), date.getMonth(),date.getDate())
>>> 3) If <time> is there, it needs to set the time fields on the calendar,
>>> too.
>>>
>>> I guess I'm going to need a custom rule...
>>>
>>> Jason
>>>
>>> robert burrell donkin wrote:
>>>
>>>> hi jason
>>>>
>>>> (this answer will probably be a little vague since i don't know the
>>>> structure of your objects.)
>>>>
>>>> if i've understood you correctly, you need to create a calendar
>>>> object. if this object is a bean (with a constructor which doesn't
>>>> need to know the data and time information and setters for these
>>>> properties) then you can probably create it with a rule mapped to
>>>> <CreateDate> and then set the properties with BeanPropertySetterRule's
>>>> mapped to <Date> and <Time>.
>>>>
>>>> if the calendar isn't bean like and it configures itself by a method
>>>> taking the <Date> and <Time> data, then you can use a CallMethodRule
>>>> and CallParamRule's.
>>>>
>>>> if the calendar needs to have the date and time passed into the
>>>> constructor, then i'm not sure any of the standard rules will work and
>>>> you might need to create a custom Rule implementation.
>>>>
>>>> hope this helps.
>>>>
>>>> - robert
>>>>
>>>> On Friday, April 4, 2003, at 07:21 PM, Jason Carreira wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm new to Digester and trying to replace some Castor XML binding
>>>>> with Digester rules. We've got one complex XSD type which is a
>>>>> structure like this:
>>>>>
>>>>>         <CreateDate>
>>>>>             <Date>2002-04-16</Date>
>>>>>             <Time>10:27:31.0</Time>
>>>>>         </CreateDate>
>>>>>
>>>>> In our current code, the <Date> element builds a Castor Date and
the
>>>>> <Time> element, which is optional, builds a Castor Time object.
We've
>>>>> got translation code which takes the year, month, and day from the
>>>>> Date object and the time fields from the Time object (if it's there)
>>>>> and builds a Calendar from it to be used in our domain models.
>>>>>
>>>>> I'm looking to bypass the Castor objects and translation and just
>>>>> build our domain models from the XML using Digester. My current
>>>>> question is, how would I go about translating the above structure
>>>>> into a Calendar? Part of the problem is that the ObjectFactory stuff
>>>>> only takes attributes,
>>>>>  not sub-elements or the body text, otherwise I could create an
>>>>> ObjectFactory.
>>>>>
>>>>> Thanks very much,
>>>>>
>>>>> Jason Carreira
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>


Mime
View raw message