Re: [Zope3-Users] Complex Adapter Requirements - Named Adapters?
On 12/11/05, Stephan Richter [EMAIL PROTECTED] wrote: On Sunday 30 October 2005 14:16, James Allwyn wrote: One thought I had, was creating an interface IStandard, with attributes like meetsstandard and nameofstandard, and then subclass this, e.g. to IAccreditationScheme and INationalCode (where Accreditation Scheme and National Code are the names of two of the standards). But I get a little stuck conceptually at the point where I try to handle, for example, the fact that for some ISharedHouse objects, IAccreditationScheme would be suitable, whilst for others it wouldn't, because of their location. In fact it's likely that in the future we will need to recognise two or more standards for a particular accommodation type (so IAccreditationScheme and IHouseCheck chould both apply to ISharedHouse objects, in differect areas). This is not such a complex case as you think. If you register an adapter from ISharedHouse to IAccreditationScheme then it will be only available for this interface and not for IAccommodation in general. I would even write a specific IAccreditationScheme for every scheme you support; thus you do not even need named adapters. OK, so by targeting the registration of the adapter I can make sure each adapter is not available for types of accommodation object that it would not apply to. I'm with you on that. My thoughts about named adapters were related to the 'other side of the coin', where I have more than one scheme (and hence adapter) that would apply to one type of accommodation (for example the schemes represented by IAccreditationScheme and IHouseCheck would both apply to ISharedHouses). I guess what I want is to have both IHouseCheck and IAccreditationScheme available for ISharedHouses *in general*, and to select either (or none) for a given *instance* of ISharedHouse. Are named adapters the way to go for this requirement, or am I not understanding some mechanism in Stephan's suggestion that makes this possible without invoking that level of complexity? Thanks for the guidance so far. James ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Complex Adapter Requirements - Named Adapters?
Hi, My project has an IAccommodation object type, representing a generic housing unit, from which we subclass several types of housing (ISharedHouse, IFamilyHouse, ILargerDevelopment,...). Now, we need to recognise various standards in relation to these accommodation units - these are standards that have been defined by various local councils etc, and an accommodation unit typically has to meet certain conditions before it can be deemed to meet that standard. A property that meets a standard is deemed to be better than one that doesn't. However, there is a degree of complexity to these standards... * Different standards will apply to different accommodation types. * Some accommodation types will have no relevant standard. * Some standards will apply to an accommodation type in some geographic areas but not other areas. One reason we want to handle these standards is to be able to rate the accommodation. E.g., a house that wasn't part of the Accreditation Scheme standard could appear lower in search results than one that was. Naturally, where there is no relevant standard for an accommodation to live up to, we do not want to penalise it in this way (or possibly would want it to appear below those that do meet a standard, and those that don't meet a standard but could...) Now, I believe I should be defining an interface or interfaces for standards and using adapters to adapt my Accommodation Objects to the 'standards' interface(s). My question is, how best to handle the complexity I've outlined above? One thought I had, was creating an interface IStandard, with attributes like meetsstandard and nameofstandard, and then subclass this, e.g. to IAccreditationScheme and INationalCode (where Accreditation Scheme and National Code are the names of two of the standards). But I get a little stuck conceptually at the point where I try to handle, for example, the fact that for some ISharedHouse objects, IAccreditationScheme would be suitable, whilst for others it wouldn't, because of their location. In fact it's likely that in the future we will need to recognise two or more standards for a particular accommodation type (so IAccreditationScheme and IHouseCheck chould both apply to ISharedHouse objects, in differect areas). I recalled reading in Philipp's book about Named Adapters, but looking back I can only find brief references to them. A 'search' through the PDF of Stephan's book reveals no instances of the phrase named adapter (or variations). Are these something I should be looking into, and if so, where can I read up on them? Or does anyone have any other suggestions on handling this? Many thanks, James ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Windows binary psycopgda-1.0.0.tgz
And I created a Zope Home Instance at C:\PyZope\ZopeHome I could NOT find package-includes so I created it at C:\PyZope\ZopeHome\packages-includes and copied psycopg-configure.zcml into it. Did you look for package-includes at: C:\PyZope\ZopeHome\etc I think that's where it should be. package-includes seems to have about 30 *-configure.zcml files in it in a default instance. Hope that helps, James ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: Products
Hi Jean, The Zope 3 documentation page is at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Documentation You can access a PDF of Stephan's Zope 3 Book there, as well as an introductory tutorial from Jim. You could also check out this blog post that points in the direction of a number of beginners tutorials: http://griddlenoise.blogspot.com/2005/10/some-zope-3-quick-starts-and-resources.html Most of those should give you an overview of what ZCML is - in short it's the configuration language for Zope 3, and it's a flavour of XML. As well as Stephan's book, there's currently one other Z3 book in print - Web Component Development in Zope 3 by Philipp von Weitershausen. I've found they complement each other quite well. Hope that helps, James On 27/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, I'm a new user of zope 3. What is the zcml? Where can I find documentation about zope 3? Is there already some books? Best regards. Jean Tinguely. Stephan Richter a écrit : On Thursday 27 October 2005 08:34, [EMAIL PROTECTED] wrote: How to add self made products in ZOPE 3? First I'll note that the Zope 2 products do not work in Zope 3. Secondly, they are not called products anymore; they are just Python packages. Now, you can add any Python package you want anywhere you like, as long as it is in the Python path. In order to hook up the ZCML to the startup process, please look at packages like zope.app.preference to see how they implemented it; the files you are interested in are SETUP.cfg and preference-configure.zcml. Regards, Stephan ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Compound Form Elements
On 04/10/05, James Allwyn [EMAIL PROTECTED] wrote:
Hello,
I wish my users to be able to register various contact details. For
each, I would record the type (e.g. email, landline tel, mobile tel,
fax...), the value (e.g. [EMAIL PROTECTED]) and a True/False value on
whether it is to be visible on the site.
Thinking further about this, it seems to me that the natural data
structure would be dicts within a list. For example, if were doing it
in plain python it might go something like this:
contacts = []
contacts
[]
contact1 = {show:True, type:mobile tel, value: 07123 456 789}
contact2 = {show:False, type:email, value: [EMAIL PROTECTED]}
contact1['type']
'mobile tel'
contact2['type']
'email'
contacts.append(contact1)
contacts.append(contact2)
contacts
[{'type': 'mobile tel', 'value': '07123 456 789', 'show': True}, {'type': 'email
', 'value': '[EMAIL PROTECTED]', 'show': False}]
len(contacts)
2
I've tried to implement this zopeishly, and the stumbling block I've
hit seems to be specifying the key and value_type pairs in the dict.
So, for example:
from zope.interface import Interface
from zope.schema import List, Dict, Bool, TextLine
class IUser(Interface):
... contacts = List(
... title=uContact Details,
... value_type=Dict(
... title=udictionary,
... value_type=Bool(title=ushow)
... value_type=TextLine(title=uvalue)
... value_type=TextLine(title=utype)
... )
... )
This barfs when it hits the second value_type in the dict. Look at the
zope.schema sources it seems I can only specify one value_type and one
key_type. What I want to do is specify three pairs of keys and
value_types - note, specifying the actual keys, not just their types.
Is this possible? Or am I barking up the wrong tree!?
Any hints gratefully received.
Thanks,
James
This seems to me to add up to an amalgamation of one each of Choice,
TextLine and Bool Schema elements. Should I build up a custom Schema
item that combines these three things, or would anyone recommend an
alternative route? It would be nice if I could combine this with a bit
of checking for validity of the value (obviously based on the type
selected).
From a visual perspective, Schema based forms seem to stack each
schema element up on a new line. To make better use of screen 'real
estate' (and to logically group) I think it would be better if my
amalgamation appeared on one line. Does this have any baring on how I
should approach the issue?
Alternatively, I'd be open to any suggestions on completely different
ways of handling this - the 'custom schema element' way does have the
problem that if I wanted to allow up to, say, six contact details to
be provided I would have to put six sets of three control elements on
screen, which would be wasteful for users who only want to specify one
contact detail.
Thanks,
James
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Compound Form Elements
Hello, I wish my users to be able to register various contact details. For each, I would record the type (e.g. email, landline tel, mobile tel, fax...), the value (e.g. [EMAIL PROTECTED]) and a True/False value on whether it is to be visible on the site. This seems to me to add up to an amalgamation of one each of Choice, TextLine and Bool Schema elements. Should I build up a custom Schema item that combines these three things, or would anyone recommend an alternative route? It would be nice if I could combine this with a bit of checking for validity of the value (obviously based on the type selected). From a visual perspective, Schema based forms seem to stack each schema element up on a new line. To make better use of screen 'real estate' (and to logically group) I think it would be better if my amalgamation appeared on one line. Does this have any baring on how I should approach the issue? Alternatively, I'd be open to any suggestions on completely different ways of handling this - the 'custom schema element' way does have the problem that if I wanted to allow up to, say, six contact details to be provided I would have to put six sets of three control elements on screen, which would be wasteful for users who only want to specify one contact detail. Thanks, James ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] User data / metadata
You could do it directly. In fact, you could even have 'members' as regular content objects in the site and write an authentication utility which looks up those members and builds a security Principal object off of that. I believe this is what Schoolbell does. This sounds interesting - are you suggesting building a Principal object 'on the fly' when someone logs in (and throwing it away when they log out again)? What would be the advantages of having them as a regular content object, rather than working with Principals? Thanks, James ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Users and the Ownership of Objects
Dear list, I have a number of questions. I've split them up over a number of emails, to keep them 'bite sized', and hopefully make any replies more useful in the archive. Apologies if this is not considered correct 'etiquette' on this list. Is there any recommended method for indicating ownership of objects by a user? There is potentially a 'many-many' mapping of objects to users, so I don't want to use containment to indicate this relationship. Would it be sensible to use Annotations to store a list of principals that are associated with the object on the object? I need to be able to call up the objects related to a user, and I'm intending to use a Catalog to call the list of objects up. Is this compatible with an annotations-based approach - i.e., would I face any difficulties getting the Catalog to read data from annotations? Also, we will need to combine this with our security system - each user will be able to edit objects that they are registered as the owner of (probably with workflow constraints...). Is this possible within the default zope security policy, or will I have to write a new one (which is a daunting prospect!) There will also be system administrators who will have the rights to edit any of the objects, so the concept of roles will work well for them, but I've not been able to see how/if I would be able to grant a principal permission to edit only those objects that she is registered as an 'owner' of using the standard zcml declarations (which, as I understand it, grant permission on, say, a whole class of objects). Thanks, James ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] User data / metadata
Hello list, A small 'conceptual' question... Both Stephan and Philipp's books recommend using principal metadata to store users' email addresses etc. If I intend to use the email addresses (and other contact information I want to store for the user) within the application (i.e., other objects will want to present it on screen), has it crossed the border from metadata to data, and would it consequently make sense to define principals with these attributes directly? Thanks, James ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Users and the Ownership of Objects
Thanks for the quick responses. Is there anywhere I can read up on what the Sharing policy mentioned will be like? Thanks, James On 28/09/05, Gary Poster [EMAIL PROTECTED] wrote: On Sep 28, 2005, at 9:16 AM, Jim Fulton wrote: Note that in the Sharing policy that we'll be releasing (soon, I hope), the sharing privilege is pretty darn close to ownership, as we've discussed. Oh, yeah. :-) Cool. Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] To Subclass, or to Adapt?
Hi, Thanks for the quick response. I think I get this - because the real world objects that my Zope objects are representing really are sub classes of 'Accommodation', it makes sense to use sub-classes to represent them. This is the in any system part of your categorisation - they really are sub-classes, so it would make sense to represent them as such in any system. Now, I think our rating scheme fits more into the second category: if the additional feature you try to implement has to do with the object's behavior in the system, it should be in an adapter. This rating scheme will be a specific feature of this system. Here we might want to calculate a 'marks out of ten' rating for accommodation, but if the objects were re-used in another system, that system may want to look at them and give them a five-star rating, or a percentage rating (or whatever). Does this make sense? If so, I guess we will be building an adapter along similar lines to the size adapter both Stephan and Phillip use as an example in their books - maybe create an IRating interface, and create adapters for each of the sub-classes to adapt those to IRating? Thanks for the help, James --- Stephan Richter [EMAIL PROTECTED] wrote: On Wednesday 10 August 2005 14:01, James Allwyn wrote: I would appreciate any guidance on what the recommended Zope3-ish way of handling this would be. I feel the options are either to create a generic IProperty object, and subclass it to IHouse, ICateredHall, ISelfCateredHall, IHomeStay, or whatever, which each add extra features or constraints; or to go down some sort of adapter route. In this particular case I would go with sub-classing, though usually I recommend the use of adapters. Basically, if the additional feature you try to implement has to do with the object's behavior in the system, it should be in an adapter. If the feature is characteristic of the object inside any system, it should be directly provided by the object. Regarding the Adapters route, in his book Phillip gives an analogy of Interfaces as a contract that an object uses to promise its functionality. If an Interface promises that an object will have a given method, does it have to provide it directly, or can it use an adapter to provide it? If an object promises it provides an interface it has to do so directly, not via an adapter. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] To Subclass, or to Adapt?
Hello list, We are in the process of building a web service for the local University, to allow accommodation to be listed, and students to search for it. Ive hit a conceptual stumbling block about how we should be proceeding with arranging this. So far we have built a system with IProperty and IPropertyFolder to contain the Property objects. Property objects themselves can contain various items (such as images, Advert objects, and AttributeSets, which define various sets of information you might want to store about a property). The stumbling block I have hit is how to generalise this to different types of accommodation? Whilst, for example, it may be relevant to describe whether a house has a washing machine or microwave in its kitchen, for a catered hall of residence it would be more suitable to describe whether it has an on site bar or gym. We are also creating an amenity-based rating system, which I would like to be consistent across all sorts of accommodation naturally, different types of accommodation will have to be judged against different criteria, but I would like to be able to call the same method for whatever type and get a valid result, just calculated in different ways. There are three or four quite distinct types of accommodation, which will have differences, but there will also be similarities (e.g., able to store images for each, able to rate each, able to add adverts for each). I would appreciate any guidance on what the recommended Zope3-ish way of handling this would be. I feel the options are either to create a generic IProperty object, and subclass it to IHouse, ICateredHall, ISelfCateredHall, IHomeStay, or whatever, which each add extra features or constraints; or to go down some sort of adapter route. Regarding the Adapters route, in his book Phillip gives an analogy of Interfaces as a contract that an object uses to promise its functionality. If an Interface promises that an object will have a given method, does it have to provide it directly, or can it use an adapter to provide it? Thanks in advance, James ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
