Well, it might be worth adding to Semantic Forms the Javascript-enabled "starting text that goes away when you click inside the box" inputs that you see a lot on the web a lot; though that's a different feature from the one you're asking about. For namespaces, if a field should always have a certain namespace, I think it's better to not have the field contain that namespace at all, but instead have the template automatically add it.
I don't know what property cardinalities mean, but, as I noted before, you can always make certain fields mandatory. The whole idea of requiring at least one non-empty field seems odd. Let's say you have a template (and form) for countries that contains, say, two fields: a population and a capital. What's the use of requiring the user to enter at least one of them? If you can live without one or the other, why not live without both? MographWiki in fact uses SMW (that's where the data comes from), and its performance seems fine to me. I don't see how the lack of a form is relevant. -Yaron On Thu, Mar 12, 2009 at 3:08 PM, John McClure <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
