Stephen McConnell wrote:
>
>
> Leo Sutic wrote:
>
>>
>>
>>> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>>> To be concrete, this is the Cocoon Context:
>>>
>>>
>>
>>
>> Nicola, I do not understand what you're getting at.
I'm just telling you what Cocoon uses as a Context *now*.
It's just a fact.
What I would like is to see suggestions from you on how it should be
done instead, or if it's ok as-is.
>> My point is that if the context is only constants that
>> are entered by an assembler (a person), then it is not
>> different from a Configuration.
And the Cocoon one is not entered by an assembler.
It contains also params that change *per request*.
> Disagree - a configuration is an object model that provides access to
> basic types (Strings, booleans, long, int, etc.). It has no support for
> complex types (e.g. java.io.File). A context object created using
> directives prepared by an assembler can contain directives for the
> creation of basic AND complex types (see earlier example and
> ContextFactory source). I can write directives for creation of objects
> with multiple argument constructors - which basically means that minimal
> effort is needed.
This is what happens now, but IMHO it's not a definition of what a
context should do (and I don't think you were giving a definition BTW ;-)
Can you guys please tell me what you would do for the CocoonContext or
you don't have a clue?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
