Re: [Springframework-developer] Re: Import tag for XML bean definitions

[bryan <nih...@gm...>]

So is my point valid or not ? Has anyone gone so far as to consider the 
deployment part of the spring lifecycle ?

--b


On Tue, 21 Sep 2004 13:40:19 +0200, bryan <nih...@gm...> wrote:
> Chris did you read my reply ?
> 
> --b
> 
> 
> 
> 
> On Mon, 20 Sep 2004 18:32:00 +0200, bryan <nih...@gm...> wrote:
> > 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
> > >
> >
>