Yes that's right - a chooser could be shown, but I think that a page with multiple categories (none declared as primary) yielding multiple forms for a page, is best interpreted as an error condition. -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of Yaron Koren Sent: Tuesday, March 24, 2009 6:17 AM To: [email protected] Subject: [Semantic Forms] Re: Form Selection (Multiple Inheritance)
Are you basically just saying that, if there's more than one default form for a page, an error message should be displayed? That certainly seems like a valid action. -Yaron On Mon, Mar 23, 2009 at 8:56 PM, John McClure <[email protected]> wrote: fwiw, I think part of the answer for multiple forms involves examining the emerging data model for the page, that is, the form manager itself provides a 'chooser' for forms associated with *subclasses* by which the page *may* be typed. Of course this would be a major change in emphasis for SF -- tying it ever more closely to the category structure, something that is often of dubious quality for many wikis. Anway, I'd agree that Sergey's tab structure would be an important piece of a multi-form solution. ---------------------------------------------------------------------------- But I'd rather not work out here and now how to do multiple forms -- my concern is that to do so distracts from the immediate issue affecting me and others: there is no control over which form is selected for a page with multiple categories. It appears that the default form for a categorized page is determined solely by the physical ordering of the rows in the table linking pages with categories. Dan B. asks whether this property "pushes the problem back one step" -- a valid point ONLY IF the "Has Primary Category" property had 0+ cardinality. But given that my interest is merely to identify the "first among otherwise equal" forms, the property's cardinality must be zero or one, so I don't see ever a need for a 'primary-primary-category'. Oh, another way Dan's point gets valid occurs when a category -- annointed as Primary -- happens to be deleted from the page, perhaps leading to cries for a 'primary-secondary-category' or something which would be picked up as the a "default" primary category. I'd suggest though that the proper system action is as implemented today, with the exception that if more than one form is indirectly associated with the page then, sure, Brendan's 'chooser' could be displayed by the forms manager, though I'd prefer right now that the system display a "Page is not available" message instead, and get the devil who caused the problem, to come fix it. As a final point, my interest in "first among equals" seems to me to agree with Yaron's basic view that a page should have just one category (hope I got that right, Yaron...). I re-word that, though, to say that a page should have one concrete category, and many qualifying categories that each may attest to an 'object state' relevant to the page. For instance, John is a Person, and John is Educated. One could union the classes and say John is an Educated Person, but that really gets unmanageable quickly. Far better I say to create two separate categories -- Person and Educated -- to classify/type the John page. Each may have a form, I suppose, but right now I only implement Educated as a template that emits [[category:Educated]] for the page. John -----Original Message----- From: [email protected] [mailto:[email protected]]on Behalf Of Yaron Koren Sent: Monday, March 23, 2009 11:30 AM To: [email protected] Subject: [Semantic Forms] Re: Form Selection (Multiple Inheritance) 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 -~----------~----~----~----~------~----~------~--~---
