On Jun 7, 2010, at 12:58 PM, Marcos Romero wrote:

>> 
>> As an aside, have you seen the post to the zopeskel list about this?  After 
>> playing with the branch a bit today, I'm finding myself uneasy about the 
>> fact that as it stands, the interface for a content type ends up with a zope 
>> schema defined that is possibly quite different from the AT Schema.  It only 
>> gets fields of the file, image and text type, so a lot of the fields one 
>> might set up on a custom type end up defined in the AT Schema but not in the 
>> zope schema in interfaces/<content-type-name>.py.  
>> 
>> I'm wondering if you have any opinion about that?
> You're right. I don't remember right now where we got this idea of not 
> updating the interface for other fields than image, file and text.
> 
I can see a reason for it, in that any field whose storage is still attribute 
storage cannot have a direct python accessor without an ATFieldProperty bridge 
property whose name is something different than the AT Schema field.  One gets 
trapped in infinite loops otherwise.  

I've solved the problem in projects where having a zope schema with access to 
AT Schema properties with attribute storage was important by creating prefixed 
ATFiledProperties and using those names in the zope schema.  For example, if I 
had an AT Schema field called 'myfield' and it has attribute storage, i create 
an ATFieldProperty for that field that I call something like 'zschema_myfield', 
and then in the interface definition, I use 'zschema_myfield' as the name of 
the corresponding field.  This works, but is clearly pretty hacktastic.

I'm open to any suggestions you all might have about a better way.

c

> Juan Pablo: any thoughts about this?
> 
> Regards
> 
> Marcos F. Romero
> Responsable de Desarrollo
> Inter-Cultura
> 
> marcos.rom...@inter-cultura.com
> www.inter-cultura.com
> +54 11 4542-8299
> 
> 
> On 07/06/2010 15:34, Cristopher Ewing wrote:
>> 
>> 
>> On Jun 7, 2010, at 11:09 AM, Marcos Romero wrote:
>> 
>>> Hi Cris
>>> 
>>>> going over the field storage repair branch you and Juan Pablo cut, I have 
>>>> only one question.  Can you explain the justification for keeping 
>>>> annotation storage and ATFieldProperty bridges for File, Image and Text 
>>>> field types but not for other field types?  I am not challenging this 
>>>> decision, I just want to understand the thinking behind the choice so that 
>>>> I can properly document the change going forward.
>>>> 
>>> Changing AttributeStorage for AnnotationStorage in Text, Image and File 
>>> fields was requested here:
>>> http://plone.org/products/atcontenttypes/roadmap/5
>>> 
>>> And was incorporated in ATContentTypes here:
>>> http://pypi.python.org/pypi/Products.ATContentTypes#alpha2
>>> 
>>> Thus, the right storage for this kind of fields (in ZopeSkel) should have 
>>> always been the ones above.
>>> 
>>> Regarding the ATFieldProperty bridges, they are for these fields to be 
>>> accessible like direct attributes instead of re-defining the 
>>> __bobo__traverse__ method.
>>> 
>>> Is this OK?
>>> 
>> Absolutely.  I know the purpose of the ATFieldProperty bridges.  I just 
>> wanted to know the reason for setting the storage for these three fields in 
>> this fashion.
>> 
>> As an aside, have you seen the post to the zopeskel list about this?  After 
>> playing with the branch a bit today, I'm finding myself uneasy about the 
>> fact that as it stands, the interface for a content type ends up with a zope 
>> schema defined that is possibly quite different from the AT Schema.  It only 
>> gets fields of the file, image and text type, so a lot of the fields one 
>> might set up on a custom type end up defined in the AT Schema but not in the 
>> zope schema in interfaces/<content-type-name>.py.  
>> 
>> I'm wondering if you have any opinion about that?
>> 
>> Thanks again,
>> 
>> c
>> 
>>> Regards
>>> 
>>> Marcos F. Romero
>>> Responsable de Desarrollo
>>> Inter-Cultura
>>> 
>>> marcos.rom...@inter-cultura.com
>>> www.inter-cultura.com
>>> +54 11 4542-8299
>>> 
>>> 
>>> On 07/06/2010 3:04, Cristopher Ewing wrote:
>>>> 
>>>> Marcos,
>>>> 
>>>> going over the field storage repair branch you and Juan Pablo cut, I have 
>>>> only one question.  Can you explain the justification for keeping 
>>>> annotation storage and ATFieldProperty bridges for File, Image and Text 
>>>> field types but not for other field types?  I am not challenging this 
>>>> decision, I just want to understand the thinking behind the choice so that 
>>>> I can properly document the change going forward.
>>>> 
>>>> One other thing, I noticed when merging the browserlayer localcommands 
>>>> branch that you somehow cut the branch with many of the changes you had 
>>>> created in place.  This led to some problems trying to merge your branch 
>>>> as the trunk was somehow unaware of the addition of a 'browserlayer' 
>>>> template directory and barfed on me a bit.  I've fixed the problem, but 
>>>> looking at the branch for the field storage changes, I see that it is also 
>>>> a one-changeset branch with all allterations apparently in place when the 
>>>> branch is cut.  In the future, would you mind cutting branches directly 
>>>> from trunk and only making changes to them _afterwards_?  This eases the 
>>>> merging process a bit on my end.
>>>> 
>>>> Thanks again for your work, and deliver my thanks also to Juan Pablo.  You 
>>>> two have been a great help over the last month :)
>>>> 
>>>> c
>>>> 
>>>> 
>>>> 
>>>> On Jun 1, 2010, at 9:14 AM, Marcos Romero wrote:
>>>> 
>>>>> Hi Cris
>>>>> 
>>>>> That would be great!
>>>>> 
>>>>> Regards
>>>>> Marcos F. Romero
>>>>> Responsable de Desarrollo
>>>>> Inter-Cultura
>>>>> 
>>>>> marcos.rom...@inter-cultura.com
>>>>> www.inter-cultura.com
>>>>> +54 11 4542-8299
>>>>> 
>>>>> 
>>>>> On 01/06/2010 13:03, Cristopher Ewing wrote:
>>>>>> 
>>>>>> I'm working on them this week.  I do not think it is too late to get 
>>>>>> them in.  In fact I had intended to do so.  
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> c
>>>>>> 
>>>>>> On Jun 1, 2010, at 9:02 AM, Marcos Romero wrote:
>>>>>> 
>>>>>>> Hi Cris
>>>>>>> 
>>>>>>> What do you think about the other two branches we submitted? Are we 
>>>>>>> short of time to include them in the next release?
>>>>>>> Do you think that the developers might want to try and test them?
>>>>>>> 
>>>>>>> Regards
>>>>>>> Marcos F. Romero
>>>>>>> Responsable de Desarrollo
>>>>>>> Inter-Cultura
>>>>>>> 
>>>>>>> marcos.rom...@inter-cultura.com
>>>>>>> www.inter-cultura.com
>>>>>>> +54 11 4542-8299
>>>>>>> 
>>>>>>> 
>>>>>>> On 01/06/2010 12:42, Cristopher Ewing wrote:
>>>>>>>> 
>>>>>>>> There's been some good recent work done adding a browserlayer local 
>>>>>>>> command, cleaning up a few of the templates and even adding a new 
>>>>>>>> hosting template (done this weekend at the sprint at PSE2010).  My 
>>>>>>>> plan is to merge those branches back to trunk and cut 2.17 within the 
>>>>>>>> next week or so.
>>>>>>>> 
>>>>>>>> c
>>>>>>>> 
>>>>>>>>   
>>>>>> 
>>>>>> ********************************
>>>>>> Cris Ewing
>>>>>> Webmaster, Lead Developer
>>>>>> Department of Radiology Web Services
>>>>>> University of Washington
>>>>>> School of Medicine
>>>>>> Work Phone: (206) 616-1288
>>>>>> Cell Phone: (206) 708-9083
>>>>>> E-mail: cew...@u.washington.edu
>>>>>> Web: http://www.rad.washington.edu
>>>>>> *******************************
>>>>>> 
>>>> 
>>>> ********************************
>>>> Cris Ewing
>>>> Webmaster, Lead Developer
>>>> Department of Radiology Web Services
>>>> University of Washington
>>>> School of Medicine
>>>> Work Phone: (206) 616-1288
>>>> Cell Phone: (206) 708-9083
>>>> E-mail: cew...@u.washington.edu
>>>> Web: http://www.rad.washington.edu
>>>> *******************************
>>>> 
>> 
>> ********************************
>> Cris Ewing
>> Webmaster, Lead Developer
>> Department of Radiology Web Services
>> University of Washington
>> School of Medicine
>> Work Phone: (206) 616-1288
>> Cell Phone: (206) 708-9083
>> E-mail: cew...@u.washington.edu
>> Web: http://www.rad.washington.edu
>> *******************************
>> 

********************************
Cris Ewing
Webmaster, Lead Developer
Department of Radiology Web Services
University of Washington
School of Medicine
Work Phone: (206) 616-1288
Cell Phone: (206) 708-9083
E-mail: cew...@u.washington.edu
Web: http://www.rad.washington.edu
*******************************

_______________________________________________
ZopeSkel mailing list
ZopeSkel@lists.plone.org
http://lists.plone.org/mailman/listinfo/zopeskel

Reply via email to