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