Combining two (or more?) sets of forms together would get complicated
because the display and layout of each field is tied to a large text
associated with a form, so what if the display of each field was set as a
subproperty on all the properties displayed in both forms, and the forms
simply referenced that code on either form. Yes designing forms would be
more complicated- but is that reasonable? Example:
The page for the definition of property A has some code in it called
Display, like so:
{{{display}}}<tr><td>My
Field:</td><td>{{{field|a|size=10}}}</td></tr>{{{display}}}
SMF could then run through a form field by field with the means to display
each field. If there happens to be more then one form for the fields. Of
course this glosses over the fact that for two forms the same field could
have different kinds of values and means of layout, but I figure that might
be a case of bad design.
-Brendan
On Mon, Mar 23, 2009 at 12: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
-~----------~----~----~----~------~----~------~--~---
