Sorry, I didn't understand this: you need multiple forms per page in order to enable example pages? What are those pages examples of? :)
-Yaron On Tue, Mar 24, 2009 at 4:26 PM, Ad Strack van Schijndel < [email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
