Hi, Well, if the goal is just to hide that field/data from users, another possibility is to make it a template field and then a hidden field in the form, so that administrators would just edit it in the source code; it seems like a simpler solution than having multiple forms, at least.
-Yaron On Wed, Mar 25, 2009 at 3:20 AM, Ad Strack van Schijndel < [email protected]> wrote: > > For each category I have some pages that are good examples of pages of > that category. So what I do is add some properties to the page to mark > it as an example. That way it appears automatically as Example on the > category page and then it can be selected for export to a new similar > wiki and appear there as examples for new users. > So it is typically a moderator task and not a task for the people that > create pages of that category. Therefore adding an optional 'Example' > area in the form for the category is not a good option. > > > 2009/3/25 Yaron Koren <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
