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