Carsten Ziegeler wrote:
Sylvain Wallez wrote:
This is clearly inconsistent.
Yepp
I personally would remove this syntactic sugar completly; it's imho not intuitiv what it means and the inconsistent implementation adds to it.
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?
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.
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?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
