[Zope3-dev] RFC: zcml:condition

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> [snip]
> 
>> Thoughts?
> 
> 
> No objections to this design, but some questions about the decisions 
> that went into the design.
> 
> Not as powerful as before, which is good. External ZCML processors might 
> mostly try to ignore this, 

Are there any?  I don't think so, so it's hard to imagine what they
will do.

> though that also depends on how conflicts are 
> dealt with -- see my question below.
> 
> I'm not sure about the 'verb arguments' construction -- is there a need 
> for verbs or is this a YAGNI? Could you list some other potential verbs? 

Yes, "if":

    zcml:condition="if .checkplatforms.validPlatform"


> I can come up with 'nothave', not sure whether I can come up with 
> applications for it. :)
> 
> 'platform' might be a useful verb, perhaps. Then again, you could also 
> work this with the semantics for 'have', I think, if you allow for 
> featurenames to be specified *before* all ZCML processing starts.

I don't think this is workable.  It's hard to predict what a useful
platform would be.

> Why the choice to make the verb be part of the attribute value, instead 
> of having the verb *be* the attribute? i.e. you could have
> 
> zcml:feature
> 
> or zcml:hasfeature or zcml:iffeature
> 
> or something along those lines.

Because I think the idea of a general condition is
easier to understand than a number of similar features.

It is also similar to tal:condition, allowing people
to leverage that knowledge.

I also think the verb-arguments format reads fairly well.

Finally, the implementation is simpler, because we split the
conditional zcml processing from expression evaluation.

> Another question: How does this impact conflicts? i.e. will conflicts 
> still occur with declarations if a piece of ZCML is conditioned out? I 
> guess not, as you might want to supply multiple conflicting pieces of 
> ZCML. Then again, if you want to do that for feature A and B, you have 
> no guarantee both features won't be there at the same time, so that 
> might lead to trouble...

The condition feature would work like tal:condition.  If
the expression evaluates to false, the element and all of it's children
won't be processed and, thus, can't conflict with anything.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org