that's why I was just saying, making it mutable, period. People can
look in there, remove, or add contributions, period. :) Let the chips
fall where they may. Instead of trying to get override rules worked
out, blah blah blah, just let us do what we need to do. :)
Something like that.
And if multiple people get to contribute/override, then they get to see
the current state of the configuration and apply their changes
appropriately..
again, the premise is that these modules and code are trusted to work
together, else, there are already many ways that they can screw with
each other ( like a module setting a contribution, on purpose or not,
and thus not allowing the app to override it ).
Howard Lewis Ship wrote:
I've been thinking of adding an override() method to
MappedConfiguration and OrderedConfiguration. The major issue is:
what if you override() something that doesn't exist? What if you
override something multiple times?
For OrderedConfiguration: if you override a contribution, what happens
to the origionals ordering constraints?
On Thu, Oct 30, 2008 at 5:40 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
So I was just thinking about how tapestry now makes contributions immutable.
And that is currently a pain point of ours because we can't properly
override the settings that we want.
But I was thinking in general, and it sounds like Tapestry should just open
up the contributions to allow people to look at them and modify then
whenever.
One reason is that one of the underpinnings of Tapestry-IoC ( at least one a
long time ago ), was that it's a simple module system because the assumption
is that all modules being loaded are within one server and all trusted. So
if all modules are trusted, why have such a big barrier as to not allow
modules to properly interact through modifying contributions, when those
modifications are trusted and expected too.
Also, if the modules are only trusted a little bit, then allowing modules to
inspect the contributions would be required, to make sure that no module
snuck in without us knowing and added rogue contributions we did not know
about..
Though I like the idea of putting up blinders between modules, it seems kind
of burdensome since it really limits what we can do, and it looks like
module system will never have truly hard lines between them.. so I vote to
take down the blinders around contributions, and let them visible and
mutable from anyone contributing to them, what do you guys think?
---------------------------------------------------------------------
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]
