Well, the primary goal was actually to make life easier to the administrators. Because that's me in this case :-). I have tried by the way to add the 'Example' properties with the corresponding form and that works fine. So you can in fact use multiple forms of which only one is the default form, the one that's behind the 'edit with form' tab. The only thing is that the 'other-form's-template' appears in the free-text box and therefore comes second. So it depends on which form you used last which 'right-hand-side-box' is up. If one of the templates is hidden as you suggest this issue may be solved. I didn't try that yet, but I think I will.
2009/3/25 Yaron Koren <[email protected]>: > 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 -~----------~----~----~----~------~----~------~--~---
