[Zope-dev] Compatibility issues: ZPatterns 0.4.2

[Phillip J. Eby]

At 10:37 AM 9/1/00 +0100, Steve Alexander wrote:
>Steve Alexander wrote:
>
>> Phillip J. Eby wrote:
>>
>> > Now, I can provide *unfiltered* linkage by direct delegation, but this
>> > would mean dropping the ability to selectively take only certain
>> > attributes
>> > or sheets from the parent.  But I suppose that, compared to dropping the
>> > capability to acquire altogether, this might be preferable.
>> 
>> 
>> This sounds fine for my use of Triggers that apply across everything
>> that a Specialist manages.
>
>I've got ZPatterns 0.4.2a1 now.
>
>I see that Folders w/ customizer support now have their own 
>Data-plug-ins tab (they didn't before), and that it does direct 
>delegation, rather than filtered forwarding.

Direct delegation?  I've lost you here.  If it's doing that, then
something's broken.  Check and see if you have any "Link to Parent Data
Plug-ins" in your customizers (they're added by default now on new
customizers).  You can filter the parent providers by selecting the ones
you want to leave out on the "exclude" property.


>Does this mean that your suggestion above has become a design decision 
>for ZPatterns? Data plug-ins directly in Customizers and Specialists 
>aren't due to be deprecated? I'm guessing that this is the case.

Argh.  I knew there was something (else) I was forgetting to document in
the CHANGES file.  I had better go fix that now.


>Also, it is a bit of a pain to refresh each of the DataManager instances 
>on each upgrade. How about an external method in ZPatterns to walk the 
>object tree and update instances as required? Perhaps it could use 
>ZopeFind. Or, seeing as Specialists and Customizer folders contain other 
>DataManagers, could you add a button to a tab in Specialists and 
>Customizer folders that refreshes them, and recursively all the 
>DataManagers they contain? Then I'd just have to go to each top-level 
>datamanager and refresh them when I upgrade.

It isn't actually be necessary to refresh on every upgrade.  IIRC, that
note about refreshing is in reference to pre-0.4.x versions.  I guess I
need to fix that too...


>Oh also, FYI, we're using ZPatterns for a couple of medium sized 
>projects, one of which is functionally complete. SkinScript has proved 
>extremely useful. I've been able to evolve an application in a very 
>clean way using propertysheets and SkinScript, whereas before I'd have 
>had to retrofit a custom base class.
>
>Phillip and Ty, thanks for your sharing your work and sharing your ideas.

You're welcome.  Since you've obviously managed to figure out how to code
SkinScript just from my cryptic notes on the mailing list, and perhaps by
looking at the grammar embedded in the compiler, do you think you could
perhaps be persuaded to write a short reference and/or tutorial for us to
include (perhaps as a help screen from the SkinScript method object's
management screens)?  Thanks.