> -Original Message-
> From: Patrick Lightbody [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 03, 2003 4:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Programmatic configuration
>
>
> > > Why not use the standard XML way to include files in
> > Why not use the standard XML way to include files in other files, i.e.
> > using entities? The above seems a bit like reinventing the wheel.
>
> I've used entities to include XML files before and I don't them for the
> following reasons:
>
> * It's difficult to figure out exactly where a proble
> > Here's a suggested solution:
> >
> > * Each application should have its own xwork.xml file that is placed
at
> > the root level of the project. For example,
> > com/indigoegg/myproject/xwork.xml for a project with a root of
> > com.indigoegg.myproject
> >
> > * Allow xwork.xml to include other
Jason Carreira wrote:
-Original Message-
From: Rickard Öberg [mailto:[EMAIL PROTECTED]
Yes, and the right way to do this is probably to enforce that
views have
this style "/WEB-INF/foo" where "foo" is the name of the
subapp, i.e. do
a "hard prefixing". This will ensure that you can al
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
>
> Jason Carreira wrote:
> > Sort of, but it's not used that way.
>
> In what way is it not used as a cache?
In the way in which if it doesn't find it in the runtime configuration it fails back
to the programmatic
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
>
> Yes, and the right way to do this is probably to enforce that
> views have
> this style "/WEB-INF/foo" where "foo" is the name of the
> subapp, i.e. do
> a "hard prefixing". This will ensure that you can always
Jason Carreira wrote:
Sort of, but it's not used that way.
In what way is it not used as a cache?
E.g.:
foo.xml
java:/BarDS
What happened to the idea of breaking up the config file with an
entity resolver? Then you could have
&package1 &package2
This could be another way of breaking up
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
>
> But, that data structure could be created on each call to the
> configuration, i.e. there's a deterministic way to get it from the
> registered package contexts. So, in *effect* it *is* a cache.
Sort of, but it's
Matt Ho wrote:
2. register each subapp via web.xml
config
/WEB-INF/struts-config.xml
config/admin
/WEB-INF/struts-config-admin.xml
config/voice
/WEB-INF/struts-config-voice.xml
Jason Carreira wrote:
I was thinking it would be good to let them be able to do a series of
modifications to the programmatic configuration side then commit them
all at once. The runtime configuration is not really a cache, it's
another set of data structures that is built from the first set.
But,
Patrick Lightbody wrote:
Interfaces are nice to make mock objects of. Let's keep it around, helps
with unit testing I believe :)
Well, that argument could be used to justify using interfaces everywhere
for anything. It's not really a good reason, in itself. As a "bonus"
perhaps. But, again, since
> >> In general, this "app created from subapps" is something that needs
> >> to be considered in all aspects. WebWork was monolithic in this
> >> sense, and it'd be good if we can move away from that. As I've
> >> already noted a couple of times, I think in the future it will be
> >> more common t
> >
> > Ok. Then I'd propose that it's removed. :-) Let's keep
> simple things
> > simple. Sometimes you want flexibility and strategy
> possibilities, and
> > sometimes you want rigidity and stability. This is a case of the
> > latter I think.
>
> Interfaces are nice to make mock objects of
> Jason Carreira wrote:
> >> Why is an interface needed here? I thought this was just a
> >> singleton thingy which the app can query. Are there several
> >> implementation possibilities, and if so, why?
> >
> > Probably not needed. I just created them to keep me sane.
>
> Ok. Then I'd propose tha
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 27, 2003 10:33 AM
> >
> > The problem here is the case of programmatic configuration.
> If someone
> > writes code to call into the ConfigurationManager to change the
> > configs, then they
Jason Carreira wrote:
Here's what I'm thinking:
1) Remove the ManageableConfiguration Interface (was
ProgrammableConfiguration) - this is just ConfigurationManager 2)
Make RuntimeConfiguration into a class and move that part of
ConfigurationManager over to it
There will always be only one RuntimeC
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 27, 2003 3:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Programmatic configuration
>
>
> Jason Carreira wrote:
> >> Why is an interface neede
Jason Carreira wrote:
Why is an interface needed here? I thought this was just a
singleton thingy which the app can query. Are there several
implementation possibilities, and if so, why?
Probably not needed. I just created them to keep me sane.
Ok. Then I'd propose that it's removed. :-) Let's kee
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
>
> Why is an interface needed here? I thought this was just a singleton
> thingy which the app can query. Are there several implementation
> possibilities, and if so, why?
>
Probably not needed. I just created the
Jason Carreira wrote:
-Original Message- From: Rickard Öberg
[mailto:[EMAIL PROTECTED]
Ah, ok, I looked at the interface you sent in email, and true, it
doesn't describe it well. But, I would argue that the interface
should be split, as I described in my first email on programmatic
confi
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]
>
> Ah, ok, I looked at the interface you sent in email, and true, it
> doesn't describe it well. But, I would argue that the
> interface should
> be split, as I described in my first email on programmatic
> config
Jason Carreira wrote:
Well, it's supposed to provide an interface to allow the
configuration to be modified and then deployed to runtime. I'm not
sure how well ConfigurationBundle describes that.
Ah, ok, I looked at the interface you sent in email, and true, it
doesn't describe it well. But, I wou
I'm not sure how well
> ConfigurationBundle describes that.
>
> > -Original Message-
> > From: Rickard Öberg [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 26, 2003 10:30 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [OS-webwork] Programmatic
uary 26, 2003 10:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Programmatic configuration
>
>
> Jason Carreira wrote:
> > How about ManagableConfiguration?
>
> or ConfigurationPackage
>
> or ConfigurationUnit
>
> or ConfigurationBundle
>
>
Jason Carreira wrote:
How about ManagableConfiguration?
or ConfigurationPackage
or ConfigurationUnit
or ConfigurationBundle
Either works, but maybe ConfigurationBundle best describes what it
actually is.
---
This SF.net email is sponsored b
How about ManagableConfiguration?
> -Original Message-
> From: Jason Carreira
> Sent: Tuesday, February 25, 2003 11:50 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [OS-webwork] Programmatic configuration
>
>
> Rename away I don't think any of those des
y, February 25, 2003 11:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Programmatic configuration
>
>
> Eww, what a horrible name, ProgrammableConfiguration! How about
> ModifiableConfiguration? DynamicConfiguration? SettableConfiguration?
>
> On Wednesday, February
Eww, what a horrible name, ProgrammableConfiguration! How about
ModifiableConfiguration? DynamicConfiguration? SettableConfiguration?
On Wednesday, February 26, 2003, at 08:27 AM, Jason Carreira wrote:
I checked in the first pass at programmatic configuration. The way it
works is that any class,
28 matches
Mail list logo
