cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: FOM inconsistency (was Re: [VOTE] Unrestricting the FOM)
Date Thu, 10 Feb 2005 07:54:07 GMT
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").
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 Ziegeler - Open Source Group, S&N AG

View raw message