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
-~----------~----~----~----~------~----~------~--~---
