Re: [Zope-dev] Re: [Zope-PTK] PROPOSAL: Splitting ZPatterns into two products
Steve Alexander wrote: "Phillip J. Eby" wrote: So, I am thinking perhaps I should split ZPatterns into two products: PlugIns and DataSkins. If 'PlugIns' includes plugins, plugin groups and plugin containers, then that's a pretty good name :-) (If I've missed bits out and the like, please let me know, I'm trying to keep up to date ;-) 'DataSkins' doesn't mean a lot to me as a name :S What components would go into this product? I'm all for this proposal. Yup, sounds like a great idea. Hopefulyl Pluggins could get into the Zope core ASAP. I reckon they might be quite useful to ZMI mark II :-) The only problem I see is that the work of updating the developer documentation on the Wikis, and putting "historical documents", like the IRC chat transcript, in a context where they make sense. I'm willing to spend some time on the documentation work. Has anyone done anything with the 'glossary wiki' idea I punted out a while back? I would have liked to have done it but have been a little busy :( anyway, sounds cool :-) Chris ___ 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] patches to make ZServer's http_request subclassable
Hi all - I made a couple of patches to ZServer (medusa, actually) to make medusa'a http_request objects subclassable... the motivation is to make customizing medusa / ZServer's logging easier to do just overriding http_request's log() method in a subclass. Patches are attached to this message, suggestions welcome! --Brian Hooper Tokyo, Japan medusa-2.1.6.patch medusa-2.2.0.patch
Re: [Zope-dev] Re: [Zope-PTK] PROPOSAL: Splitting ZPatterns into two products
Chris Withers wrote: 'DataSkins' doesn't mean a lot to me as a name :S What components would go into this product? An object that has DataSkin as a base class allows a DataManager to look after its data storage requirements. The DataManager stores all the propertysheets and attributes, and works out what to do and who to notify when things change. There are various types of DataManager in ZPatterns, and the important ones take plug-ins so that you can greatly modify their behaviour. Specialists and Customizers (aka Folders w/ customizer support) are the main DataManagers you build an application out of. Specialists may have Racks inside them to actually do the work of storing the data, so you can think about your application's architecture at many different levels of abstraction. You can say "The AddressBook specialist manages Address DataSkins" but you can also say "The Addresses rack in the AddessBook specialist stores the Address DataSkins". When Objects get created or deleted or changed, a DataManager will tell any Agents it knows about that this has happened, in case they are interested. An Agent is anything that monitors the events produced when things happen to DataSkins. A Trigger is a kind of Agent that does something concrete, like calling a method, in response to a change in a DataSkin. You can use a Trigger to update a ZCatalog when a DataSkin gets added or deleted or changes. This is good because catalog-awareness gets to move out of the domain objects (business objects, or whatever) and into the parts of your system that are concerned with the management of those objects. You can even use two Triggers to update two different Catalogs when a DataSkin changes -- for example, the AddressBook catalog, and also a SiteIndex catalog for searching all the data in your system. Perhaps the SiteIndex holds just minimal indexes and meta-data, whereas the AddressBook catalog holds meta-data and indexes more specialised to an address book. Two other important aspects of the DataSkins part of ZPatterns are SheetProviders and AttributeProviders. These plug into Racks (and anything else that takes "Data Plugins") and do the work of getting propertysheets and calculating or importing attributes. These attributes and propertysheets generally end up as the data belonging to the DataSkins. Yup, sounds like a great idea. Hopefulyl Pluggins could get into the Zope core ASAP. I reckon they might be quite useful to ZMI mark II :-) What is ZMI? -- 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] Re: [Zope-PTK] PROPOSAL: Splitting ZPatterns into two products
At 09:51 AM 7/28/00 +0100, Chris Withers wrote: Steve Alexander wrote: "Phillip J. Eby" wrote: So, I am thinking perhaps I should split ZPatterns into two products: PlugIns and DataSkins. If 'PlugIns' includes plugins, plugin groups and plugin containers, then that's a pretty good name :-) Yes. 'DataSkins' doesn't mean a lot to me as a name :S What components would go into this product? DataSkins themselves, and all the things that support them. Data Managers (Racks and Customizers), Data Manager containers (Specialists and Folders w/Customization Support), and Data Plug-Ins (Attribute Providers, Sheet Providers, Triggers, etc.) Yup, sounds like a great idea. Hopefulyl Pluggins could get into the Zope core ASAP. I reckon they might be quite useful to ZMI mark II :-) That might be, but the PlugIns part isn't really where it should be before it could even be proposed to go into the Zope core. The biggest hurdle remaining is full ZClass support. I would like to have it so that if you base a ZClass on PlugInContainer, you get a tab in the ZClass management screen where you can add and configure plug-in groups... and the groups themselves would be plug-ins, so that you could have specialized forms of plug-in groups. Has anyone done anything with the 'glossary wiki' idea I punted out a while back? I don't believe so. But I think that splitting the package will make documentation easier. Partly because it will allow starting from a fresh viewpoint that is DataSkins-centric and more use-oriented. I figure on leaving the ZPatterns Wiki alone for the most part until the DataSkins docs start to mature, and then yanking out documentation-type stuff from the ZPatterns Wiki and re-purposing it to focus on application design, object modelling, and the like, in the context of the DataSkins and PlugIns packages. ___ 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] Re: [Zope-PTK] PROPOSAL: Splitting ZPatternsinto two products
"Phillip J. Eby" wrote: DataSkins themselves, Okay, I'm being dumb again, but could someone explain to me how the name DataSkin came about and how it relates to what these objects do? :S That might be, but the PlugIns part isn't really where it should be before it could even be proposed to go into the Zope core. The biggest hurdle remaining is full ZClass support. How does this interact with DC's plans to redo ZClasses? (although I'm not sure there are plans here yet, I just got the feeling there were..) Has anyone done anything with the 'glossary wiki' idea I punted out a while back? I don't believe so. But I think that splitting the package will make documentation easier. Partly because it will allow starting from a fresh viewpoint that is DataSkins-centric and more use-oriented. I figure on leaving the ZPatterns Wiki alone for the most part until the DataSkins docs start to mature, and then yanking out documentation-type stuff from the ZPatterns Wiki and re-purposing it to focus on application design, object modelling, and the like, in the context of the DataSkins and PlugIns packages. Sounds great :-) cheers, Chris ___ 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] Stuff hanging off user not in cookies
On Tue, 25 Jul 2000, Brian Lloyd wrote: I'm thinking of the dimensions/etc of the edit boxes and the like. I do a lot of work through virtual domains and it's a real pain having to resize that edit box every time I log in through a different domain or on a different computer... Have you looked at the "Better User Management" proposal? One aspect of it is a better level of lowest-common-denominator support for extended attributes. I think that a prerequisite On the other hand, Chris's specific proposal has some problems grin. Suppose I'm running Netscape in view and IE in another...I don't want the same size edit box in both...nor do I necessarily even if I just have more than one window of the same kind of browser open. This whole issue is a user preference thing, so you really ought to support a 'default' setting and a 'this screen' setting. (And while we're at it, those buttons ought to be some sort of image map or multi-button scale bar so you could just click to the size you want instead of having to click-wait-click-wait-click-wait) Actually, I use w3m, so in reality I don't *care* what the size of the edit box is, so don't tell me that patches are accepted grin. --RDM ___ 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] Re: [Zope-PTK] PROPOSAL: Splitting ZPatterns into two products
Steve Alexander wrote: An object that has DataSkin as a base class allows a DataManager to look after its data storage requirements. The DataManager stores all the propertysheets and attributes, and works out what to do and who to notify when things change. Okay, makes sense... There are various types of DataManager in ZPatterns, and the important ones take plug-ins so that you can greatly modify their behaviour. I thought there were only two right now? Specialists may have Racks inside them to actually do the work of storing the data, Now what's a rack in Plugin terminology? so you can think about your application's architecture at many different levels of abstraction. You can say "The AddressBook specialist manages Address DataSkins" but you can also say "The Addresses rack in the AddessBook specialist stores the Address DataSkins". By DataSkins here, particularly in the secodn phrasing, wouldn't it be better to say the AddressBook specialist stores the flesh and bones of the Address DataSkins? When Objects get created or deleted or changed, a DataManager will tell any Agents it knows about that this has happened, in case they are interested. Are 'Objects' here DataSkins, non-DataSkins or either? An Agent is anything that monitors the events produced when things happen to DataSkins. But they're actually called by the Data Managers? A Trigger is a kind of Agent that does something concrete, like calling a method, in response to a change in a DataSkin. You can use a Trigger to update a ZCatalog when a DataSkin gets added or deleted or changes. Sounds cool, where does SkinScript fit in here? This is good because catalog-awareness gets to move out of the domain objects (business objects, or whatever) and into the parts of your system that are concerned with the management of those objects. I think I like this... You can even use two Triggers to update two different Catalogs when a DataSkin changes -- for example, the AddressBook catalog, and also a SiteIndex catalog for searching all the data in your system. Now how would these triggers actually get added to the datamanager in the above example? I like this very much as it's something I've often wondered about but which CatalogAware never seemed to address... Two other important aspects of the DataSkins part of ZPatterns are SheetProviders and AttributeProviders. These plug into Racks (and anything else that takes "Data Plugins") and do the work of getting propertysheets and calculating or importing attributes. These attributes and propertysheets generally end up as the data belonging to the DataSkins. Ah, okay, I see now. So, for example, a SheetProvider would prove a property sheet for each DataSkin served by the DataManager in which it was located? What is ZMI? Zope Management Interface (specifically Mark II ;-) It's a proposal on dev.zope.org... cheers, Chris ___ 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] PROPOSAL: Splitting ZPatterns into two products
At 10:22 PM 7/28/00 +0100, Chris Withers wrote: Steve Alexander wrote: There are various types of DataManager in ZPatterns, and the important ones take plug-ins so that you can greatly modify their behaviour. I thought there were only two right now? Technically, there are three - Specialist, Rack, and Customizer. But Specialist is never directly used by a DataSkin as its data manager, because of the Rack. Specialist derives from DataManager, though, so it can have data plug-ins for use by its Racks. So there are only two "true" DataManagers - Rack and Customizer. I don't expect there will be any more in future, because I don't know of any other ways to organize Zope objects besides: 1) a flat namespace (Rack), or 2) a sub-object tree (supported by Customizers). Specialists may have Racks inside them to actually do the work of storing the data, Now what's a rack in Plugin terminology? A plug-in that's also a plug-in container. so you can think about your application's architecture at many different levels of abstraction. You can say "The AddressBook specialist manages Address DataSkins" but you can also say "The Addresses rack in the AddessBook specialist stores the Address DataSkins". By DataSkins here, particularly in the secodn phrasing, wouldn't it be better to say the AddressBook specialist stores the flesh and bones of the Address DataSkins? Here's how I prefer to say it... An "AddressBook" specialist is where you get, create, or manipulate en-masse, things which you'd like to have in an address book. It may contain one or more racks which store some particular concrete class of things which have addresses, and which you want to have available through your addressbook specialist. The rack does not necessarily store the "flesh and bones", because that might reside in LDAP, SQL, the filesystem, or something else altogether. The rack is a "storage manager" which manages the process of realizing DataSkins of a particular class with common storage characteristics. When Objects get created or deleted or changed, a DataManager will tell any Agents it knows about that this has happened, in case they are interested. Are 'Objects' here DataSkins, non-DataSkins or either? DataSkins only. An Agent is anything that monitors the events produced when things happen to DataSkins. But they're actually called by the Data Managers? Yes. DataSkins tell their DataManager they've changed; the DM forwards the appropriate messages to the Agents. A Trigger is a kind of Agent that does something concrete, like calling a method, in response to a change in a DataSkin. You can use a Trigger to update a ZCatalog when a DataSkin gets added or deleted or changes. Sounds cool, where does SkinScript fit in here? SkinScript can be used to specify DTML expressions to be called as triggers, or to be used to calculate attributes, etc. In place of an AttributeProvider or Trigger, you plug-in a SkinScript Method to a DataManager, then write the SkinScript code to describe all the attributes and triggers, etc. you want. You can even use two Triggers to update two different Catalogs when a DataSkin changes -- for example, the AddressBook catalog, and also a SiteIndex catalog for searching all the data in your system. Now how would these triggers actually get added to the datamanager in the above example? You go to its Data Plug-ins tab, and select from the "Add" dropdown the kind of trigger or provider you want. Then you fill in its settings to do what you want it to do. Ah, okay, I see now. So, for example, a SheetProvider would prove a property sheet for each DataSkin served by the DataManager in which it was located? Yep. ___ 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] New Client.py bug(?) in 2.2.0 affects ZScheduler
In Zope version 2.2.0b3 Client.py calls connect in httplib (in two different places) like this: sock.connect(self.host,self.port) In Zope version 2.2.0 (final) it's like this: sock.connect((self.host,self.port)) In the latter case, Python complains: TypeError: 'argument 1: ..., tuple found' Does anyone know what was the motivation for the change in the syntax for the call to connect? Should I drop this in the Collector? -- Loren ___ 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] [Re: [Zope-dev] ZPatterns Documentation]
"Phillip J. Eby" wrote: Despite the implications of the bait-and-switch subject line, I have not yet written any substantial amounts of documentation. I have, however, written this: http://www.zope.org/Members/pje/Wikis/ZPatterns/DataSkinsOverview Which was actually exceptionally useful, at least for me :-) Thanks, Chris PS: Could anyone who gets a chance please give me some feedback? I'd like to know if this is the kind of stuff that people would like to see more of, Yes please! :-) whether it's too much detail, Perhaps still a little too much jargon still, if there's anything to complain about. I can't help thinking that a _really_ simple example that _only just_ uses the available features would help to make it real for people like me... ___ 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] New Client.py bug(?) in 2.2.0 affects ZScheduler
Loren Stafford wrote: Does anyone know what was the motivation for the change in the syntax for the call to connect? To make it Python 2 compatible, but this shouldn't cause these errors since connect is supposed to be able to takea tuple now. Confusedly, Chris ___ 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] [Re: [Zope-dev] ZPatterns Documentation]
Chris Withers wrote: I can't help thinking that a _really_ simple example that _only just_ uses the available features would help to make it real for people like me... Well, I have made a 'News Article' toy from ZPatterns, more so to get a feel for the mechanics than for any 'advantage' ZPatterns offers (AIUI). I could post the process I made, like a walkthrough if anyone is interested. (Thanks to Steve Alexander for som ehelp on #zope last night!) Bill -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password. ___ 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] Client.py prevents ZScheduler with SSL? (was: Zope.org feedback)
Moving this to zope-dev and changing title... From: "Jim Sanford" [EMAIL PROTECTED] We have no http access to our site. It is a corporate Client Relationship Management, Job Tracking and Order Processing, Production and Tracking system that is accessed from all over the world. I will send this to the list to see if any one else can provide help. From: Loren Stafford [EMAIL PROTECTED] From: "Jim Sanford" [EMAIL PROTECTED] URL: http://www.zope.org/Members/lstaffor ZScheduler uses Client.py. Would it be correct to say that if my entire site is only accessible via SSL (https) that ZScheduler will not work? I hadn't thought about this before, so you probably know more about it than I do. But given that the python lib that Client.py uses for http (httplib.py) doesn't support https, then you're right. Solutions? 1. Permit http traffic to your site if it comes fromt the same IP and is for URLs that end in "/trigger". I suppose that IP spoofing makes this something of a security hole. How bad? 2. Enhance either Client.py or httplib.py to support at least enough https to get the job done. I know nothing about this. Is it reasonably doable? Is there a Zopista willing and able to do it? 3. ? -- Loren ___ 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] Membership 0.6.1 available
OK, I have an updated Membership product avalable at http://www.zope.org/Members/Bill/Products/Membership Basically, it fixes the keyword parameter problem, and I've started adding the hooks to eventuall plant a user management interface onto. I just need one crucial piece of the puzzle ... I think. ;) Anyway, same warnings on this as with the version Kevin had. Use in production at your own risk (yes, I take the risk ;) Bill -- Do not meddle in the affairs of sysadmins, for they are easy to annoy, and have the root password. ___ 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 )
