commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration]More docs
Date Fri, 14 Nov 2003 23:24:53 GMT
Wow...

I can't wait to read through your patch tomarrow..  Only have a minute, so I
thought I would address the XMLReaderProvider....

Maybe it is just me, but something I don't like about java and interfaces is
that sometimes I get so lost in all the interfaces..  Everything implements
an interface and behave's differently depending on which interface is being
used etc..

I think you are 100% right, if we had 3 cases..  But with two cases, I feel
like since we still have an if statement, we aren't gaining much.  If and
When we get the if/elseif/else structure, then I think that would be great..

Part of me wonders why it doesn't look like this:

       return new ((XMLReaderProvider) config).createXMLReader();,

why the BaseConfigurationXMLReader is differnet.  Why not have
BaseConfigurationXMLReader implement createXMLReader as well?

Eric

> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Friday, November 14, 2003 8:12 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration]More docs
>
>
> Hi,
>
> I followed Yoav's suggestion and created an example page with usage
> examples for some of the features of ConfigurationFactory. I think if
> another structure is preferred, the texts can easy be copied
> and pasted.
> The patch is in bugzilla with the bug id 24716.
>
> Eric, I see your point with keeping the Configuration interface as
> simple as it can be. A ConfigurationXMLDocument class is
> surely a good
> idea; it could also provide some other functionality like creating a
> Document (dom4j or w3c), storing a Configuration object as
> XML file, or
> utility methods for Digester interaction.
>
> There is only one thing I feel uneasy with: The new class
> would have to
> instantiate a specific ConfigurationXMLReader instance
> depending on the
> class of the actual Configuration object (there is one specific class
> for HierarchicalConfiguration and one that handles the other
> classes).
> Code like
>
>   if(config instanceof HierarchicalConfiguration)
>   {
>       return new HierarchicalConfigurationXMLReader(config);
>   }
>   else
>   {
>       return new BaseConfigurationXMLReader(config);
>    }
>
> would make every refactoring guru mad because such a problems
> scream for
> polymorphism. Would it be a solution to introduce a new interface,
> something like XMLReaderProvider, with only a
> createXMLReader() method?
> Then we could have code like the following
>
>   if(config instanceof XMLReaderProvider)
>   {
>       return new ((XMLReaderProvider) config).createXMLReader();
>   }
>   else
>   {
>       return new BaseConfigurationXMLReader(config);
>    }
>
> This is maybe a bit better. The base configuration classes would
> implement this interface in a proper way. What do you think?
>
> Oli
>
> Shapira, Yoav wrote:
>
> >Howdy,
> >Suggestion: add an Examples page (xdocs/examples.xml) to the
> nagivation
> >bar (xdocs/navigation.xml).  Write some examples there, starting with
> >very basic ones that seem trivial to you.  Maven will take care of
> >publishing it.  This is consistent with many other commons
> projects.  If
> >you need any help with the mechanical parts (writing xdocs,
> using maven
> >to publish the site, etc.) I'll be glad to help.  And as Senor Pugh
> >said, don't worry about your English ;)  Thanks,
> >
> >Yoav Shapira
> >Millennium ChemInformatics
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Eric Pugh [mailto:epugh@upstate.com]
> >>Sent: Tuesday, November 11, 2003 10:50 AM
> >>To: 'Jakarta Commons Developers List'
> >>Subject: RE: [configuration]More docs
> >>
> >>Oliver,
> >>
> >>I would say that your English is better then 90% of the english
> >>
> >>
> >speaking
> >
> >
> >>world, so don't feel hesitant writing docs.  I recommend
> using the xdoc
> >>format as that is native to Maven, and I would add maybe
> some "howto"
> >>docs..
> >>
> >>Maybe  a: howto-configurationfactory.xml,
> howto-hierarchical.xml etc..
> >>
> >>The createXMLReader is an interesting idea..  However, I think that
> >>
> >>
> >maybe
> >
> >
> >>instead it would be better to have a
> ConfigurationXMLDocument that took
> >>
> >>
> >in
> >
> >
> >>a
> >>Configuration object.  I am somewhat hesitant to add more methods to
> >>
> >>
> >the
> >
> >
> >>Configuration interface that arne't really directly related to
> >>
> >>
> >retrieving
> >
> >
> >>configuration values.  Especially if it releies on each
> concrete class
> >>implementing it, as that starts to raise the bar more and more for
> >>
> >>
> >adding
> >
> >
> >>the underlying concrete implmentations...
> >>
> >>Eric
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> >>>Sent: Tuesday, November 11, 2003 4:32 PM
> >>>To: Jakarta Commons Developer List
> >>>Subject: [configuration]More docs
> >>>
> >>>
> >>>Eric,
> >>>
> >>>I am willing to produce some more docs about my changes.
> What is the
> >>>preferred way to do that? Changing the overview page? Of
> >>>course a native
> >>>speaker should review my results ;-)
> >>>
> >>>Some other point: The last patch includes the feature that each
> >>>configuration object can be transformed in a XML document (or
> >>>at least
> >>>allows XML-like processing by firing SAXEvents) by using one of the
> >>>ConfigurationXMLReader classes. This is certainly something
> >>>that needs
> >>>to be documented in some more detail, too.
> >>>
> >>>Do you think it would make sense to add a createXMLReader()
> >>>method (or
> >>>similar) to the Configuration interface? This method would be
> >>>implemented in the concrete classes by returning the proper
> >>>implementation of ConfigurationXMLReader. Then this
> feature could be
> >>>accessed directly through the interface.
> >>>
> >>>Oli
> >>>
> >>>
> >>>-----------------------------------------------------------
> ----------
> >>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> >>>
> >>>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> >
> >This e-mail, including any attachments, is a confidential
> business communication, and may contain information that is
> confidential, proprietary and/or privileged.  This e-mail is
> intended only for the individual(s) to whom it is addressed,
> and may not be saved, copied, printed, disclosed or used by
> anyone else.  If you are not the(an) intended recipient,
> please immediately delete this e-mail from your computer
> system and notify the sender.  Thank you.
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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


Mime
View raw message