Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
Furthermore, I really don't like this naming scope filled from
different sources (the object itself and some other data), especially
when one of the sources comes from the browser.
And what about conflicts? Fortunately the object is searched before
request parameters, otherwise this would be a nice security hole.
So, what do we do? Do we keep this inconsistent behaviour, deprecate
it, remove it now?
WDYT?
I personally would remove this syntactic sugar completly; it's imho
not intuitiv what it means and the inconsistent implementation adds to
it.
In addition it would make our unified object model implementation (for
flow, jxtg etc.) much easier as we don't have to simulate this in Java.
Unfortunately, I fear that this is common use, so let's deprecate it
with 2.1.x and remove for 2.2 completly
agree :-)
Now with all this deprecated stuff floating around, we should have a
centralized deprecation Logger so that users can easily be informed of
the deprecated features they use (in the case of Javascript, there's no
compiler warning like in Java).
That would make a new log file (e.g. deprecated.log), but IMO that one
deserves to exist.
Yes, and we should really try to add *all* "deprecated log messages" there.
Where can we put that deprecation logger? What comes to mind is either
the Avalon Context, or a component, i.e. lookup(Logger.ROLE +
"deprecated").
WDYT?
I think this should be as simple as possible. What about a static
accessor, e.g. on the Core object? You might want to use this logger
where you don't want to either implement Serviceable nor
Contextualizable, so imho it should be easier.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
