[Zope3-dev] About zcml:condition

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:

>> This discussion was taking place on the zope3-checkins list, and I 
>> didn't want it to be lost there without any public discussion.
>>
>> Stephan Richter wrote:
>>
>>> On Friday 07 January 2005 11:43, Fred L. Drake, Jr. wrote:
>>>
>>>> Log message for revision 28766:
>>>>  Add ZCML support for conditional directives using the zcml:condition
>>>>  attribute.  The value of the attribute is a TALES expression; if the
>>>>  expression is true, the element the attribute is attached to will be
>>>>  used, otherwise the element and its descendents will be ignored.
>>>
>>> I was waiting for the day when this would happen. Doesn't this 
>>> violate the pricniple that we don't want to evolve ZCML to a 
>>> language? The reason we chose ZCML over Python was that we did not 
>>> want all the powerful features of a true programming language.
>>>
>>
>> To me this is a rather major conceptual change. My worries grow the 
>> more I think about it.
>  
> I guess we we should have done a proposal ...

That would've helped, certainly.

>> I don't know anything about the details of how these TALES expressions 
>> get evaluated (in what context, etc), so I may be misinterpreting 
>> this, but:
> 
> They are pretty context free.

That's good.

> The use case was to only include some zcml is running on windows. 

This I understood, but adding support for something as broad as Python 
expressions is not the only way to deal with this.

> I wanted the ability to
> define variable and be able to conditionally configure based on those
> variable, as in:
> 
>   zcml:condition"in_development|nothing"
> 
> to include things that should only be around during development.

Right. It's not so much the conditionals I'm worried about, it's the 
expressions.

>> I am worried about allowing people to write Python code in ZCML. Only 
>> allowing a simple expression language like path expressions, accessing 
>> some predefined context, would be far more palatable to me. Python 
>> conditionals could, by calling into a large codebase, affect some 
>> arbitrary part of that codebase. Side effects might happen, errors 
>> could occur.
> 
> Errors could occur lots of ways.  The intendion here is not to
> perform lots of computation in zcml.

I understand this is the intention, which is why I question allowing 
Python in ZCML. No matter what the intention is of its use, allowing 
expressions will allow the processing of ZCML code to be affected by 
arbitrarily complicated state. This makes analysis a lot harder.

>  > Python expressions also harm the processability of ZCML by
> 
>> external tools which want to do some analysis of ZCML code.
> 
> That would be true of a path-based syntax.

I'm not suggesting full path-based syntax either. Current TALES path 
syntax is also too powerful, as it allows functions to be called as well.

A simple flat namespace with a few variables, or a well defined nested 
namespace, would make automated analysis a lot easier. If we know the 
only variables that can exist are, say, 'in_development' and 'windows', 
analysis is doable. If however people can put in arbitrarily complicated 
expressions that may be calling functions that call functions cascading 
arbitrarily deep into Python code, this analysis is not doable anymore.

I'm suggesting there is a true alternative that is indeed more simple 
than what has been introduced now, and that is a namespace with values 
in it that are defined *before* any ZCML code is run.

>  > This
> 
>> includes Zope 3 source code analysis tools and authoring environments.
>>
>> I'm therefore worried that Python expressions could compromise the 
>> declarative nature of ZCML. I think that the genericity of using 
>> Python in ZCML is a YAGNI; a simpler fix would be to have conditionals 
>> depend on some simple, predefined and precalculated state that starts 
>> before ZCML processing begins. This could include things like the 
>> platform.
> 
> Precalculated how?

I mean calculated before any ZCML processing takes place. You can 
calculate 'platform_windows' and 'in_development' in whatever way you 
like, it should just happen before the processing of ZCML code itself 
takes place. ZCML can then only depend on the precalculated state, not 
call into anything else to drive its conditionals.

What seems to have happened with zcml:condition is that just a little 
bit more expressive power was needed and the whole Python language was 
dragged in. Alternative designs are possible. Were things considered 
like introducing an overlay concept to ZCML instead, for instance? You 
could have a design where certain files only are activated if certain 
(global, context-free) conditions are met, for instance.

This change feels a little bit like what happened to DTML way back when, 
and in that case it led to awful cruftiness. I'm not saying that will 
happen here, but a bit more of language design consideration would've 
been nice before this was introduced.

Regards,

Martijn