I think it's not about combining fields, but combining templates as a whole.
And what you're saying is that this combining can only be done by human
being?
Hmm. It probably makes sense - separate question though is editing by
smaller form that only edits one template, for example...
Hmm...
Sergey
On Mon, Mar 23, 2009 at 3:30 PM, Yaron Koren <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
