Re: [configuration]More docs
Okay, I can live with this if condition for the two cases. If later
other cases are added, this should be easy to refactor.
My code fragment contained the paranoia check whether the passed in
Configuration object implements the XMLReaderProvider interface. If this
is the case, the createXMLReader() method can be called (which at the
moment would return either a BaseConfigurationXMLReader or a
HierarchicalConfigurationXMLReader). Otherwise always a
BaseConfigurationXMLReader is returned, which can handle all types of
Configuration objects.
Oli
Eric Pugh wrote:
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:[EMAIL PROTECTED]
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]More docs
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]More docs
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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
