[Zope] List & Dictionary properties; General property handling thoughts

[Eron Lloyd]

Hello Steve -

Yeah, it seems that lines are stored internally as lists; tokens seem like a 
weird property to me with (kinda like a "tuple array"). Guess they would be 
handy for things like keywords, etc. My only problem with requiring a 
compelling reason to have a mapping property is that I shouldn't need one! If 
more than half of the built-ins are supported already, then why not provide 
for them all? Maybe this is just a general rant about Zope itself. Some very 
basic "Pythonic" concepts seem to be missing (the lack of "one way of doing 
it" being a big culprit); this is why some people move on to things like 
WebWare. Why do we need "lines" and "tokens" instead of traditional "lists" 
and "tuples"? Why a "boolean" property instead of a simple "0/1" integer 
value? "String" & "Text" are understandable, as well as "date", "int", 
"long", and "float". On the other hand, "selection" and "multiple selection" 
seem to mix content and presentation--something it seems the platform is 
trying to avoid.

I think I will poke around in the internals a bit and try to make some sense 
of Zope's property handling infrastructure. It seems to be a "dusty corner" 
of the codebase that hasn't seen much love as of late. As I mentioned before, 
there are several revamps we could probably institutue now to make it more 
sensible. I just hope this doesn't have its roots deep within the dark layer 
of ZODB persistance. I'm about as able as a spelunker with a lighter for a 
torch when it comes to that point.

Taking-a-"beginner's mind"-attitude-towards-Zope-Zen,

Eron

P.S. - Just got your book. Looks great!

On Thursday 27 December 2001 06:01 am, Steve Spicklemire wrote:
> Hi Eron,
>
> 	I believe tokens and lines properties are actually implemented as
> lists in python, so you should be able to use them that way. Maybe if
> you could give a compelling use-case for a dictionary property it would
> help clarify the need? In my own experience it seems that when at first
> I think I need a dictionary property.. what I really need is another
> class. ;-)
>
> -steve
>
> On Wednesday, December 26, 2001, at 05:37 PM, Eron Lloyd wrote:
> > This may seem like a redundant question, but this is the third time
> > I've come
> > across the desire to be able to store values persistantly as lists or
> > dictionaries. I've read all the suggestions in the archives pointing out
> > alternatives (<dtml-return expr="{'id': 'item'}">, TinyTable,
> > string.split('value1|value2|..', '|'), "lines" property, SQL DB, etc.)
> > but I
> > still don't quite get the "Zen" of why this wouldn't make sense in
> > practice.
> > People have mentioned that it seems redundant with existing structures
> > like
> > tokens or lines, but these don't seem to have all the familiar benefits
> > of
> > lists and dicts, like instantly accessible mutability and _methods_,
> > plus no
> > added overhead. I know you can manipulate data within lists & dicts in a
> > Python script, but it's just not why I require.
> >
> > Following this thought, I wonder if it wouldn't be handy to be able to
> > cut,
> > copy, & paste properties between valid objects, and provide a way to
> > convert
> > existing property values to different types? Also, the ability to
> > import/export propertysheets of OFS objects could be useful as well
> > (like in
> > ZClasses). The facilities to do these things already exist, so would it
> > be
> > agreed by others in the community to promote these changes? Is it too
> > late to
> > try and work this into Zope3?
> >
> > Trying-to-help-Zope-grow-10x-ingly yours,
> >
> > Eron
> >
> > _______________________________________________
> > Zope maillist  -  Zope@zope.org
> > http://lists.zope.org/mailman/listinfo/zope
> > **   No cross posts or HTML encoding!  **
> > (Related lists -
> >  http://lists.zope.org/mailman/listinfo/zope-announce
> >  http://lists.zope.org/mailman/listinfo/zope-dev )