Markus Angst wrote:
Jörn Nettingsmeier wrote:
but the publication should be *able* to override anything, right?
The idea was that a command line property should be able to override even a
publication property, but i don't have very strong feelings about this
particular issue.
makes sense imho. i hadn't really thought of command line properties,
but yes, they should be the mostest mightiest.
so it ought to be at the beginning if the parsing follows "first one wins".
Regarding the point in time the publication properties are read in last (if
nobody else finds a better solution) so the order of precedence has to be kept
artificially by applying some magic (like leaving alone some properties with
particular name prefixes and overwriting others...).
ok, so then forget my remark about parsing order. it's "order of
precedence" then, which could be accomplished by
if (property) {
remove(property);
add(property,otherSource);
}
i don't think prefixes should have an impact on whether a property can
be overridden. they should just be there to avoid *accidetal* overriding
when names clash.
i'm a little confused about some things:
can there be a lenya.properties in the core (i.e. under webapp/lenya)?
can there be one lenya.properties per publication? or does that have to
be local.lenya.properties? if so, why?
will template publications be taken into account? if so, we should mimic
(or better yet, re-use) an aggregating fallback behaviour with
last-one-wins as described above. are you doing that already?
thanks,
jörn
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
