I don't agree that it should be interpreted as an error condition. So the chooser would be my choice. My case is the following. I've got pages that have a single category and form. No problem. But then some of the pages are an example to people who are creating pages for that category, so the page gets an extra category: Example. The two don't have anything to do with each other and the two 'beings' of the page have their own properties. And it would be nice if there could be two forms. Now I have to edit the 'Example' properties in the wiki-text. No big deal, but I prefer forms:-).
2009/3/24 John McClure <[email protected]>: > 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 -~----------~----~----~----~------~----~------~--~---
