Thanks for the tip about tooltips :) I'll investigate that. Meanwhile, yes, instructions can be put next to the field -- but that's no assurance that the instructions will be ntocied much less heeded. Further, instructions unnecessarily clog up the display when a value has (already) been entered for the field. Hmm, I mentioned 2 use cases, the other being the prefilled namespace prefix, which I'm sure users would appreciate having alot.
On the arg-less template issue, maybe templates are used differently in a straight mw application, but in a smw application, the template should be enforcing business rules relevant to the category with which the template is associated, prior to either formatting output or prior to performing a series of #set statements. Property cardinalities in particular are enforced there (where else? pray tell). My point is that only a small minority of categories (classes) do *not* require any properties with non-zero cardinality (that small minority consists of classes representing boolean existential facts, e.g., category:Gray Haired Person, a subcategory of category:Person). Hence, it is the exceptional template that does not require at least one non-null arg. Your counter-example -- http://mographwiki.net/London -- unfortunately is a case of a mw application, not a smw application (and an exceptionally poorly performing mw application at that). Yes "London" is categorized as a "Cities" but "Cities" has no form... it is not a 'semantic category' at all. On Mar 12, 10:23 am, Yaron Koren <[email protected]> wrote: > Ah, it's for instructions and such. Well, you can always put them right next > to the form field; many people do that. I should also mention the > heavily-underdocumented SMW parser function #info, which displays a > Javascript tooltip - I don't know if there's documentation for it anywhere, > but you can see it in use near the bottom of this page (the little question > mark icon): > > http://semantic-mediawiki.org/wiki/Help:Configuration > > Actually, I've never heard of an SMW template that's only useful when it has > at least one non-null argument. And I've seen quite a few cases of pages > that contain nothing but an argument-less template call; here's one example: > > http://mographwiki.net/London > > -Yaron > > On Thu, Mar 12, 2009 at 2:07 PM, John McClure <[email protected]>wrote: > > > > > > > For the second one, there are 2 cases that come to mind. > > (1) pre-fills with anticipated prefixes (e.g., namespace:) > > (2) pre-fills with data entry instructions (eg "Enter MM/DD/YYYY") > > > It would also be nice to have a {{{field |name ||tip=text}}} parameter > > also, which is formatted into the title= attribute on the <input> (or > > whatever) widget. > > > For the first one, the use case is that the developer simply doesn't > > want the template called when there are no args to pass to the > > template because, as I mentioned, templates are normally designed as > > dependent on receiving at least one non-null argument. > > > Thanks. > > > On Mar 12, 9:47 am, Yaron Koren <[email protected]> wrote: > > > Okay, now I think I understand. Could you give a use case or two for why > > you > > > think each feature is important? I'm especially curious about the second > > one > > > - why have a default value if it's just going to get ignored? > > > > -Yaron > > > > On Thu, Mar 12, 2009 at 1:24 PM, John McClure <[email protected] > > >wrote: > > > > > On Mar 12, 5:32 am, Yaron Koren <[email protected]> wrote: > > > > > Oh - by "for-template" fields, do you mean fields contained in > > > > > multiple-instance templates, the ones that use "remove" and "add > > > > another"? > > > > > Or are you talking about all templates? > > > > > I'm requesting that all templates should have this switch. As for its > > > > name, I was thinking of > > > > {{for template |templatename |no-null-call}} > > > > where no-null-call = suppresses output of the template call when *all* > > > > args are null > > > > > > The second issue I didn't understand either - what's an argument > > > > formulated > > > > > from a value? > > > > > The value of the input widget is transformed into the value of the > > > > argument passed to the template. > > > > > I'm requesting that all fields should have this switch. As for its > > > > name, I was thinking of > > > > {{field |fieldname |no-default-arg}} > > > > where no-default-arg = suppresses output of arg when user has not > > > > changed the field's default value- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
