Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2
"Phillip J. Eby" wrote: > > >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. sorry -- I didn't really mean that. > 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. That's what I meant. Great. > >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. I'll take that as a "yes" then. :-) > >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... I had a bit of oddness with a Folder with Customizer Support on upgrading from 0-4-1snap1 to 0-4-2a1. Until I added then removed a datamanager, there was some attribute error occuring. Unfortunately, I didn't look into it before I accidentally fixed it. I'll be upgrading another zope instance with ZPatterns later on, so I'll watch out for the same behaviour then. > 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. I have a DataSkins how-to / short introduction that is about half complete. I was hoping to get this out by today, but then I discovered SkinScript, and also real work got in the way :-) I'll try and get it finished this weekend. Perhaps some of that can be reused as help in the management screens. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2
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. 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. 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. 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. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0
Phillip J. Eby wrote: > > Would it be an undue hardship to copy these into all the relevant racks or > customizers, until there is a feature to allow inclusion from another rack > or customizer? Not at all. :-) > 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. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0
At 11:04 AM 8/27/00 +0100, Steve Alexander wrote: > >I have been putting CatalogTriggers as DataManagers directly in >Specialists. > And this *works*??? None of the "Acquired ... Provider" classes supported forwarding to an acquired trigger, as far as I can recall. The fact that it's so bloody awkward to forward to acquired providers is part of why I think they should be dropped. Hmm... looking at source code... aha! Okay, so "Link to Parent Data Plug-ins" provides linking to triggers. I'd forgotten about that, obviously. Dang. >This seems to me the obvious place to do some triggering action that >applies over all the Specialist's racks, but which has nothing to do >with storage. Yes, it is. But it also adds to new user confusion, and leads to a bunch of otherwise-unnecessary code complication. In particular, Specialist wouldn't need to be a DataManager when it's really only a PlugInContainer. >I don't yet use SkinScript. However, I imagine there are a number of >uses for Triggers that apply at the level of abstraction of a >Specialist. Would it be an undue hardship to copy these into all the relevant racks or customizers, until there is a feature to allow inclusion from another rack or customizer? >Please think about keeping the feature, if it doesn't make things too >complicated. Basically, the problem is that I am trying to decouple delegation interfaces from the ZPatterns core. That is, I'm trying to make it such that DataManagers don't have to know about all the possible things that can be delegated to Data Plug-ins. That way, as additional plug-in capabilities are added, such as content providers and local role providers, the DataManager class doesn't change, since it's just an intermediary for *finding* those providers, and giving dataskins certain persistence-related services. Unfortunately, using items that link to acquired providers with any kind of filtering means that the link itself must provide some form of the interface which is being delegated, which means that the link must know about all possible interfaces. :( 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. Hmmm. Let me think about this. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0
Phillip Eby wrote: > > * We would like to drop support for Specialists directly containing data > plug-ins. This feature was intended to allow for acquiring shared data > plug-ins from within Racks, so that common attribute or sheet providers > could be shared among Racks without copying. In practice, Ty and I have > never once used this capability, and it could be easily replaced with the > ability to "include" a SkinScript within another SkinScript, if we take > advantage of 2.2.x-isms. I have been putting CatalogTriggers as DataManagers directly in Specialists. This seems to me the obvious place to do some triggering action that applies over all the Specialist's racks, but which has nothing to do with storage. I don't yet use SkinScript. However, I imagine there are a number of uses for Triggers that apply at the level of abstraction of a Specialist. Please think about keeping the feature, if it doesn't make things too complicated. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0
Hi folks. I'm working on a ZPatterns 0.4.2b1 release for the early part of the coming week, and intend to bug Ty into perhaps releasing an 0.9.0 beta later in the week. However, these versions are likely to have some (hopefully minor) compatibility issues with previous releases. Specifically: * We would like to drop support for Zope 2.1.x from here on out. I know at least one user has a production 2.1.x system, and I hate to strand them, but at least they can continue to use existing ZPatterns releases until their client can upgrade. Dropping 2.1.x support means that we may be able to get rid of DynPersist, which should be a big plus for ease of installation. It also means that we'll be able to start adding newer capabilities that take advantage of 2.2.x-isms such as getPhysicalPath()/restrictedTraverse(), etc. * We would like to drop support for Specialists directly containing data plug-ins. This feature was intended to allow for acquiring shared data plug-ins from within Racks, so that common attribute or sheet providers could be shared among Racks without copying. In practice, Ty and I have never once used this capability, and it could be easily replaced with the ability to "include" a SkinScript within another SkinScript, if we take advantage of 2.2.x-isms. * Related to the above, the "Link to Acquired Provider" and "Acquired ... Provider" objects would no longer be needed, since they exist only to make use of shared plug-ins contained in Specialists. We would remove these classes from ZPatterns, causing any existing instances to become "broken". Deleting these "broken" objects, however, would restore normal operations of the system. As you can see, all of these issues are somewhat interrelated. I wanted to post some advance warning of all this, so that if anyone has any objections, they would have a last chance to protest. :) The overall release plan at this point is that the only other major features planned in the 0.4.x series are content providers (mirroring virtual sub-objects from SQL, LDAP, or whatever) and local role providers (computation by an object of local roles applicable to a user). I do expect to add a few minor features in the way of easier SkinScript editing, and some hooks to allow help to be added to the management tabs which are auto-generated for PlugInGroups. The next big project will be documentation, now that the feature set and terminology is beginning to stabilize. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
