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 xml files via
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,
-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 not
Jason Carreira wrote:
Sort of, but it's not used that way.
In what way is it not used as a cache?
E.g.: xwork !-- Register subapp foo which uses XML config --
application name=foo param name=config.xmlfoo.xml/param
/application !-- Register subapp bar which uses DB config --
application
-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
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 always
-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 them to
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
-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 needed here? I thought this was just a
singleton
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
-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 need to be
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.
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. Let's keep
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 to build webapps
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 describe as
correctly as (the name I named
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
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Programmatic configuration
Jason Carreira wrote:
How about ManagableConfiguration?
or ConfigurationPackage
or ConfigurationUnit
or ConfigurationBundle
Either works, but maybe ConfigurationBundle best describes what it
actually
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 configuration
Jason Carreira wrote:
How about
-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
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
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
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 26, 2003, at 08:27 AM, Jason Carreira wrote
22 matches
Mail list logo
