avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Component Design Question
Date Wed, 17 Apr 2002 14:03:55 GMT
Hmmm. Not sure I got across what I meant to. Basically it came down to this. 
If you don't implment XMLizable (and thus decouple from xml.* package) then 
you can reuse the whole package in other contexts. 

For instance I would like to use it to retrieve
* xml and xsl sheets as per Cocoon
* velocity templates
* other resources that can be referred to by a URI. In Ant2 quite a few things 
will be resolvable by URIs and it would be nice to have a common interface to 
it all.

Anyways I think that should be possible ? And I would love it to be ;P

BTW you should probably move the classes into org.apache.excalibur.source.* 
priorit to releasing it.

BTW2 if you would like to move the implementations of the various interfaces 
into a subpackage org.apache.excalibur.source.impl.* then that would make the 
component much more easier to learn IMHO

BTW3 Love the javadocs! :)

On Wed, 17 Apr 2002 23:52, Peter Donald wrote:
> On Wed, 17 Apr 2002 19:09, Carsten Ziegeler wrote:
> > Putting it short, the question is: Should instanceof be used or avoided?
> > My short answer to this is: It should be avoided as it is not
> > object-oriented.
>
> We use instanceof throughout avalon. ie We often pick out features of a
> component and apply special processing to component if component requires
> feature. Consider the
>
> if( object instanceof Initializable )
> {
>   ((Initializable)object).initialize();
> }
>
> However using instanceof operator to pick up out members in a inheritance
> hierarchy (aka members in a classification hierarchy) is definetly
> considered bad. As a rule of thumb - Anytime the second parameter to
> instanceof operator is a class (and not an interface) you know you are
> probably doing something bad.
>
> > The Source interface can be *extended* with several features, for example
> > the ModifiableSource or the XMLizable interface.
> >
> > Now, when dealing with a Source object (especially in Cocoon, but I
> > believe in other environments as well), the client of the source resolver
> > has always to check if the returned source object is modifiable (=
> > instanceof ModifiableSource)
> > or not.
> > Within Cocoon this leads to two checks for instanceof Modifiable for each
> > URI
> > used (this means for each XML or XSL file read etc.).
> > I don't think that this is very elegant.
>
> I think mergingthe ModificableSource and Source is a good idea as it is a
> reasonable assumption that in the majority of use cases the two interfaces
> will be highly correlated and it does not hurt to expose the Modifiable
> features in base interface as there is no security/performance or other
> issues that I am aware of ?
>
> > For Cocoon the same applies to the XMLizable interface which marks a
> > Source object that it can produce XML SAX represantation. I would like to
> > add a isXMLizable() method and extend the Source interface with the
> > XMLizable interface.
>
> XMLizable is a different kettle of fish IMHO. It is not part of the work
> interface exposed by Resolver but a feature of implementation returned. I
> would highly recomend you dont mix these concerns.
>
> For instance I was considering using the source stuff inside myrmidon (Ant2
> proposal) but have no real need of toXML and thus requiring that would be
> overkill for my use.
>
> If you actually look at the implementations of source in package they
> actually are just convenience methods. You could quite easily implement
> toXML outside the class with zero negative effects. Doing it this way would
> decouple source from the excalibur.xml.* package and the
> framework.component.* package making it much more easier to support in
> future. Ad much easier to extract and use in other contexts.

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message