[Dev] Re: mixinAClass vs Query

[Katie Capps Parlante]

I've been assuming all along that we will want at least some piece of 
the ui to inspect the kind/attribute of the item and pick a 
block/renderer based on the type of attribute. I wasn't imagining we'd 
need a query for this, but that one could navigate to the Enumeration 
from the attribute -- indeed one should already be able to do this, that 
is the point of having all of this meta data around. :)

We have talked about blocks having a "contentSpec" (which we want to 
change to "contents"). In the case of a high level View, the "contents" 
attribute usually contains an ItemCollection, which often uses a query 
to populate its contents. In the case of an "attributeBlock", perhaps 
the value of the block's "contents" should be an Attribute, which the 
block could inspect for the type, cardinality, etc. If the type is an 
Enumeration, we should be able to ask the Enumeration for its values.

Cheers,
Katie

Ted Leung wrote:
> 
> On Jun 14, 2004, at 2:47 PM, Donn Denman wrote:
> 
>> Ted,
>>
>> In my example I'm actaully looking for the set of possible values that 
>> an enumeration can have.
>> Here's an example: various people want to add their own attributes to 
>> the Contacts list.  Sara wants to add "golf handicap", Wayne wants to 
>> add "bridge partner", and I want to add "eye color", etc.  We want to 
>> be able to use an "Attribute Block" that presents an editor that's 
>> appropriate for the Kind of the newly added attribute.  The golf 
>> handicap is a number, so it could present an edit text field.  Maybe 
>> bridge partner would support dragging another contact and dropping it 
>> onto the attribute.  For eye color, we want a ComboBox that shows the 
>> possible values for eye color: blue, green, grey, brown, etc.
>> For "eye color" we'd need to query the schema and ask it the vaules 
>> defined by the enumeration.   It was unclear to me that queries would 
>> support this, or that you would want them to.  I think of queries as 
>> always returning Items, but that's probably not right.
>> Anyway this "Chamelian Block" seems like a useful thing because it 
>> would be so general purpose.  Do you think a query would handle these 
>> cases?
> 
> 
> Okay, your example helps.  Two points -- 1) it's probably possible to 
> have a query return a set of things that are not items, but that's 
> probably down the road if we decide to do it at all. 2) I agree that we 
> probably don't want o use a query to ask for the possible values of an 
> enumeration.  But it may make sense to have some reasonable API for 
> doing that.
> 
>>
>> - Donn
>>
>>
>> Ted Leung wrote:
>>
>>> As far as the query part of the discussion goes, I'm not sure what 
>>> Donn is saying that queries don't return enumeration values.  The 
>>> Query class that we have today doesn't, but there's no reason why a 
>>> query shouldn't be able to return any attribute value of an item, 
>>> even if the type of the attribute is Enum.   That aside, I'm not sure 
>>> that you'd necessarily want to use a query to do what you are 
>>> discussing here.  If you could imagine writing a query that returns 
>>> all Blocks that have a particular (Enumeration) attribute value, then 
>>> that would be (in my opinion) an appropriate use of a query.
>>>
>>> Ted
>>>
>>> On Jun 11, 2004, at 12:53 PM, John Anderson wrote:
>>>
>>>> Very interesting.
>>>>
>>>> I think it would be quite useful to have an AttributeBlock that just 
>>>> displays any attribute and presents the appropriate U/I for whatever 
>>>> type the attribute happens to be. I think that's what I'm going to 
>>>> want for editing elements of the summary view. I like the idea 
>>>> getting away from specific kinds of blocks and replacing them with a 
>>>> more general purpose block, which might choose a natural default 
>>>> based on the type of attribute, but also have a style attribute 
>>>> which forces how the data is presented. This sounds so cool it makes 
>>>> me want to go write it :-)
>>>>
>>>> John
>>>>
>>>> Donn Denman wrote:
>>>>
>>>>> John,
>>>>>
>>>>> It occurs to me that the mixinAClass/Attribute approach of 
>>>>> attaching behavior to Blocks acts a little like a query, in that it 
>>>>> populates the block, but appears to be much more flexible.  For 
>>>>> instance, I'd like to make a ComboBoxAttribute block that points to 
>>>>> an Attribute whose value is an Enum.  It would populate the 
>>>>> ComboBox from the different values available in the Enumeration, 
>>>>> and select the current value held by the Attribute.  I don't think 
>>>>> you can do this with a query, since Enumeration values are not 
>>>>> returned by queries.
>>>>> I think in the long run we want a more general AttirbuteBlock that 
>>>>> looks at the type of the attibute to be displayed, and then takes 
>>>>> on the actual block kind appropriate for that attribute.  If the 
>>>>> attribute was a boolean, it would present a check box.  String 
>>>>> attributes would be displayed in static or edit text blocks.  
>>>>> Comboboxes for Enumerations, etc.
>>>>>
>>>>> Just food for thought.  I think I'm going to plow ahead with the 
>>>>> MarkupBar while we ponder AttributeBlocks.
>>>>>
>>>>> - Donn
>>>>
>>>>
>>>>
>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>
>>>> Open Source Applications Foundation "Dev" mailing list
>>>> http://lists.osafoundation.org/mailman/listinfo/dev
>>>>
>>>
>>>
>>> ----
>>> Ted Leung                 Open Source Applications Foundation (OSAF)
>>> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
>>>
>>
>>
> ----
> Ted Leung                 Open Source Applications Foundation (OSAF)
> PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev