|
From: bryan <nih...@gm...> - 2004-09-20 16:32:05
|
If you use a non xml based import facility i think it will be harder to use
xml editors like xmlbuddy with them as there will be problems with entities
referencing entities that are not in the document, this will make it harder to
validate at development time.
Why not instead take the approach of a single big file like a registry
depending on a single properties file or set of preferences ( registry )
values.
The problem is that with some things like
org.springframework.web.context.ContextLoaderListener get the list of
properties files using a context-param.
How can the user change this unless she unzips the application, manually
edits the value and then redeploys it ?
Wouldn't it be far simpler from an end user ( at the end of the day they
drive requirements ) point of view if they could just run a simple program
which would edit the registry keys and then restart the application with the
changes happening automatically ?
Very few web applications are well designed from an installation/administration
point of view, but there are a couple that really stand such as the php based
squirrelmail.
It offers an easy to use perl config program that chooses sensible defaults for
the administrator but allows them to change them as they see fit.
If there is no chance of making the changes to the xml format perhaps it
would be good to at least allow some mechanism for changing the files that
ContextLoaderListener uses at runtime without unzip, edit xml, re-zip
cycle.
Not everyone is a programmer or technically literate, this is fine for some
but not fine for your average point and click windows "administrator".
--b
On Mon, 20 Sep 2004 08:15:41 -0400, Chris Eldredge
<chr...@co...> wrote:
> As my message stated, I think the import tag is a good feature and look
> forward to using it. It should solve your 3 * 300 problem.
>
> The part I take issue with is putting conditionals and other
> meta-programming into an xml file. Keep in mind, xml and IoC are
> intended to divorce configuration from the program. Turning a bean
> configuration file into a bean "script" entirely defeats that purpose
> because essentially you are putting the program into the configuration.
>
> What is the perceived advantage of using
>
> <condition test="foo"> <import name="sometimes.xml"> </condition>
>
> instead of the java equivalent:
>
> if (foo) {
> context = new ClassPathXmlApplicationContext(new String[] {"main.xml",
> "sometimes.xml"});
> } else {
> context = new ClassPathXmlApplicationContext(new String[] {"main.xml"});
> }
>
> All you would be doing is mixing your configuration with your program.
>
>
>
> bryan wrote:
> > Chris,
> >
> > You must really like keeping 3 * 300 line files in sync with each
> > other when just
> > 60/70 lines are different in each one .....
> >
> > I'm not talking about adding #ifdef and #define to the top of your java source
> > files here !
> >
> > --b
> >
> >
> >
> > On Thu, 16 Sep 2004 14:46:45 -0400, Chris Eldredge
> > <chr...@co...> wrote:
> >
> >>bryan wrote:
> >>
> >>
> >>><beans>
> >>><if value="test" equals="test">
> >>> <import resource="myImport1.xml"/>
> >>></if>
> >>
> >>This looks an awful lot like meta-programming to me. This becomes a
> >>slippery slope. IMO, xml bean files should be for configuration, not
> >>for scripting.
> >>
> >>The <import>, however, is something that I am looking forward to using
> >>on my current project.
> >>
> >>Chris.
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> >>Project Admins to receive an Apple iPod Mini FREE for your judgement on
> >>who ports your project to Linux PPC the best. Sponsored by IBM.
> >>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|