The thing is, it seems to me very hard to combine forms in an intelligent
way. In the case of bars and restaurants, how does the system know to use
the "address" field from just one, instead of both? And if both are
available, how does the user know which one to choose?

-Yaron


On Mon, Mar 23, 2009 at 3:13 PM, Sergey Chernyshev <
[email protected]> wrote:

> Speaking of UI, another solution is to have tabs for non-default forms
> similar how large forms can be split to tabs using Header Tabs now.
>
>         Sergey
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
>
>
> On Mon, Mar 23, 2009 at 3:10 PM, Brendan Crosser-McGay 
> <[email protected]>wrote:
>
>> Maybe this is oversimplifying, but what if the default behavior in the
>> case of a page belonging to multiple categories both with their own form is
>> that the form itself contains a "chooser" with the template form from both
>> contained within it?  I know that might not work under all circumstances,
>> but wouldn't that at least allow people to add the data as needed from
>> either category, and not require any pages or properties to be set anywhere
>> that makes that page special, in regards to it being in multiple-form-land?
>>
>> It appears as though other people had this same idea, as I was typing
>> this. (thanks gmail) ;)
>>
>> -Brendan
>>
>>
>> On Mon, Mar 23, 2009 at 12:07 PM, Sergey Chernyshev <
>> [email protected]> wrote:
>>
>>> I actually have another specific example if it helps - TechPresentations
>>> has a notion of Topic for presentations:
>>> http://www.techpresentations.org/Category:Topic
>>>
>>> And as you can imagine it's quite generic thing so Topics are not always
>>> just some abstract things like Performance:
>>> http://www.techpresentations.org/Performance
>>>
>>> But also more specific ones like JavaScript (
>>> http://www.techpresentations.org/JavaScript) which is also a Programming
>>> Language (will need it's own form) or YSlow (
>>> http://www.techpresentations.org/YSlow) which is also a Tool (will need
>>> it's own form). I understand that in this case, it might be useful to have
>>> "Topic" form simply copied to "Programming Language" and "Tool" form, but I
>>> wonder if using these subforms would be easier if they got somehow
>>> abstracted out.
>>>
>>> Thank you,
>>>
>>>         Sergey
>>>
>>>
>>> --
>>> Sergey Chernyshev
>>> http://www.sergeychernyshev.com/
>>>
>>>
>>>
>>> On Mon, Mar 23, 2009 at 3:48 PM, John McClure 
>>> <[email protected]>wrote:
>>>
>>>>  *A combo bar/restaurant sounds reasonable as a primary category (in
>>>> order to capture the fields applicable to both). Of course this particular
>>>> calisthentic is necessary because the SF model does not accommodate 
>>>> multiple
>>>> forms, aka multiple types aka multiple categories. And, I hasten to add,
>>>> that that's not a big surprise in itself -- pretty much all form managers
>>>> are designed with only one form associated with each object.*
>>>> **
>>>> *The objective of this "Has Primary Category" proposal is
>>>> merely to permit control of which particular (single) form is indirectly
>>>> associated with a page. It is to make visible the currently opaque process
>>>> of form selection for a page. I think it would help end-users and 
>>>> developers
>>>> who NORMALLY, I would say, assign multiple categories to a page.*
>>>> **
>>>> *Permitting multiple forms for a page is surely something that can
>>>> be worked another day. For now, it seems a small step that developers and
>>>> users have explicit control over which (single) form is associated with a
>>>> page. Even in a multiple-form scenario, specifying the primary category, ie
>>>> the primary form, I'd think would still be useful/relevant.*
>>>> **
>>>> *Thanks -*
>>>> **
>>>>   -----Original Message-----
>>>> *From:* [email protected] [mailto:
>>>> [email protected]]*on Behalf Of *Yaron Koren
>>>> *Sent:* Sunday, March 22, 2009 6:49 PM
>>>> *To:* [email protected]
>>>> *Subject:* [Semantic Forms] Re: Form Selection (Multiple Inheritance)
>>>>
>>>> Well, I'm glad you brought out a concrete example, because I can use it
>>>> to hopefully illustrate the misgivings I have about multiple categories in 
>>>> a
>>>> page. You have a page, "Ristorante Muro vino e cucina", for a place that's
>>>> both a bar and a restaurant (certainly a common combination). Here's that
>>>> page being edited with both the form for bars and the one for restaurants:
>>>>
>>>>
>>>> http://www.venicewiki.org/wiki/Speciale:EditData/Bar/Ristorante_Muro_vino_e_cucina
>>>>
>>>> http://www.venicewiki.org/wiki/Speciale:EditData/Ristorante/Ristorante_Muro_vino_e_cucina
>>>>
>>>> Some of the fields are shared by both forms, like location and telephone
>>>> number. But the form for bars has fields for the price of coffee, wine,
>>>> etc., while the restaurant form doesn't; and the form for the restaurant 
>>>> has
>>>> an "average dinner price" field, while the bar form doesn't. But for a 
>>>> place
>>>> that's both a bar and a restaurant, wouldn't you want all of those fields?
>>>> Using one form or the other leads to less than the ideal amount of
>>>> information.
>>>>
>>>> There are a few options I could suggest instead: one is to make a third
>>>> category/form combination, for "Bar restaurants"; and make that category a
>>>> sub-category of both "Bars" and "Restaurants". Another possibility is to
>>>> have either the "bar" or "restaurant" forms (or both) contain the fields
>>>> necessary for the other one, that users could optionally fill in; then have
>>>> an #if call within each template, so that if the user fills out one or more
>>>> of those optional fields, the page gets added to the category "Bar
>>>> restaurants", which, as before, is a sub-category of the other two. A third
>>>> possibility is to have a single form and category for both bars and
>>>> resturants, with just a set of checkboxes for users to specify what kind of
>>>> place it is.
>>>>
>>>> -Yaron
>>>>
>>>>
>>>> On Fri, Mar 20, 2009 at 5:20 PM, Venicewiki.org 
>>>> <[email protected]>wrote:
>>>>
>>>>>
>>>>> We also like to have a "Has primary category" property.
>>>>>
>>>>> Our problem: in our site a restaurant page is inserted through
>>>>> Template:Restaurants in the Category:Restaurants. But if
>>>>> [[Category:Bars]] is added in the "other categories" field, then the
>>>>> Form:Bar is selected when editing the page with form instead of the
>>>>> original Form:Restaurant (because "B"<"R").
>>>>>
>>>>> Example: http://www.venicewiki.org/wiki/Ristorante_Muro_vino_e_cucina
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Semantic Forms" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to