You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <u....@cbim.it> on 2003/10/15 22:29:03 UTC
[Woody] Purpose of DynamicSelectionList.SelectionListHandler
To all Woddy gurus out there: what is the purpose of the
DynamicSelectionList.SelectionListHandler class? Why doesn't
DynamicSelectionList just spit out the SAX events generated from its
source. What conversions do take place there?
I'm asking because I'm writing a new type of SelectionList, one that
fetches list items from the context object, and I was wondering whether
I should do the same kind of post-processing or not.
TIA,
Ugo
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Ugo Cei <u....@cbim.it>.
Ugo Cei wrote:
> To all Woddy gurus out there: what is the purpose of the
> DynamicSelectionList.SelectionListHandler class? Why doesn't
> DynamicSelectionList just spit out the SAX events generated from its
> source. What conversions do take place there?
OK, nevermind, I just figured out that I completely misunderstood how
DynamicSelectionList works. This also means that the test I previously
wrote is completely useless :-(.
Ugo
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Ugo Cei <u....@cbim.it>.
Bruno Dumon wrote:
> Ah, now I see what you mean. Try using this class:
>
> org.apache.avalon.framework.service.WrapperServiceManager
Indeed. In the meantime, I had stumbled upon this class while browsing
around the classes with Eclipse. So now I think I just need to get hold
of a Datatype. Can you point me in the right direction?
Ugo
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2003-10-18 at 10:53, Ugo Cei wrote:
> Bruno Dumon wrote:
> > euh... wrong I think. The ExcaliburTestCase creates an ECM, and the ECM
> > supports both Composable and Serviceable. Or what problem do you see?
>
> OK, now my testcase implements ExcaliburTestCase and I get an ECM from
> it. Now, how do I get a ServiceManager from the ECM?
Ah, now I see what you mean. Try using this class:
org.apache.avalon.framework.service.WrapperServiceManager
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Ugo Cei <u....@cbim.it>.
Bruno Dumon wrote:
> euh... wrong I think. The ExcaliburTestCase creates an ECM, and the ECM
> supports both Composable and Serviceable. Or what problem do you see?
OK, now my testcase implements ExcaliburTestCase and I get an ECM from
it. Now, how do I get a ServiceManager from the ECM?
Ugo
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Ugo Cei <u....@cbim.it>.
Bruno Dumon wrote:
>>Unfortunately, for unit testing, we only have an
>>AbstractCompositeTestCase which extends ExcaliburTestCase, which
>>implements Composable and not Serviceable, right?
> euh... wrong I think. The ExcaliburTestCase creates an ECM, and the ECM
> supports both Composable and Serviceable. Or what problem do you see?
I only see my ignorance regarding Avalon, ECM, etc. ;-). Thanks for
clarifying the issue.
> Maybe it would be easier if you ran the tests from inside a running
> Cocoon (possibly using the CocoonBean), so that the whole environment is
> created. But maybe that goes against the spirit of unit tests?
I'm afraid that starting Cocoon every time you want to run a test might
take so much time that you'd end up not running them at all. Or at
least, you'd end up running the full test suite before releasing
something, which is perfectly fine, but is not what Test Driven
Development is all about. I want my tests to drive coding: write a test,
see it fail (red bar), fix the code, green bar, refactor, green bar
(hopefully), and so on...
Ugo
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-10-16 at 00:11, Ugo Cei wrote:
> Bruno Dumon wrote:
> > On Wed, 2003-10-15 at 22:29, Ugo Cei wrote:
> >>To all Woddy gurus out there: what is the purpose of the
> >>DynamicSelectionList.SelectionListHandler class? Why doesn't
> >>DynamicSelectionList just spit out the SAX events generated from its
> >>source. What conversions do take place there?
> > conversion from how things were formatted where the list data was
> > retrieved from to how it should be formatted so that the widget will
> > recognize it upon form submit.
>
> Yeah, somehow I figured it out by myself after I wrote my mail. However,
> this means that, in order to test this conversion I need to pass an
> instance of a subclass of Datatype to the DynamicSelectionList
> constructor, and the only way to get one is via the DatatypeManager and
> in turn that requires having an Avalon ServiceManager. Is that correct?
>
> Unfortunately, for unit testing, we only have an
> AbstractCompositeTestCase which extends ExcaliburTestCase, which
> implements Composable and not Serviceable, right?
euh... wrong I think. The ExcaliburTestCase creates an ECM, and the ECM
supports both Composable and Serviceable. Or what problem do you see?
>
> So, what do we do? Do we implement a ServiceableTestCase or do we forget
> about unit testing Woody components? And what about other components
> after the migration from ECM to Fortress is completed in Cocoon 2.2?
>
> I'm feeling somewhat lost here. I didn't figure unit-testing Cocoon was
> so hard :-(.
Maybe it would be easier if you ran the tests from inside a running
Cocoon (possibly using the CocoonBean), so that the whole environment is
created. But maybe that goes against the spirit of unit tests?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Ugo Cei <u....@cbim.it>.
Bruno Dumon wrote:
> On Wed, 2003-10-15 at 22:29, Ugo Cei wrote:
>>To all Woddy gurus out there: what is the purpose of the
>>DynamicSelectionList.SelectionListHandler class? Why doesn't
>>DynamicSelectionList just spit out the SAX events generated from its
>>source. What conversions do take place there?
> conversion from how things were formatted where the list data was
> retrieved from to how it should be formatted so that the widget will
> recognize it upon form submit.
Yeah, somehow I figured it out by myself after I wrote my mail. However,
this means that, in order to test this conversion I need to pass an
instance of a subclass of Datatype to the DynamicSelectionList
constructor, and the only way to get one is via the DatatypeManager and
in turn that requires having an Avalon ServiceManager. Is that correct?
Unfortunately, for unit testing, we only have an
AbstractCompositeTestCase which extends ExcaliburTestCase, which
implements Composable and not Serviceable, right?
So, what do we do? Do we implement a ServiceableTestCase or do we forget
about unit testing Woody components? And what about other components
after the migration from ECM to Fortress is completed in Cocoon 2.2?
I'm feeling somewhat lost here. I didn't figure unit-testing Cocoon was
so hard :-(.
Ugo
Re: [Woody] Purpose of DynamicSelectionList.SelectionListHandler
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-10-15 at 22:29, Ugo Cei wrote:
> To all Woddy gurus out there: what is the purpose of the
> DynamicSelectionList.SelectionListHandler class? Why doesn't
> DynamicSelectionList just spit out the SAX events generated from its
> source. What conversions do take place there?
conversion from how things were formatted where the list data was
retrieved from to how it should be formatted so that the widget will
recognize it upon form submit.
For example, suppose you retrieve a list of dates which are formatted
like yyyyMMdd but the format towards the user is dd/MM/yyyy, then this
conversion is needed. (there's an example of this in the Woody samples)
Obviously this is only needed for non-string datatypes.
>
> I'm asking because I'm writing a new type of SelectionList, one that
> fetches list items from the context object, and I was wondering whether
> I should do the same kind of post-processing or not.
If you want to support non-string types, yes.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org