On Tue, Apr 7, 2009 at 3:40 AM, Markus Krötzsch <
mar...@semantic-mediawiki.org> wrote:
> On Montag, 6. April 2009, Yaron Koren wrote:
> [skip-skip]
> > Sergey - it's true that creating a good UI is hard, but I don't think
> > having each format provide its own forms is the way to go - first becau
On Montag, 6. April 2009, Yaron Koren wrote:
> Markus - I think any info on the type of the parameter can just be part of
> the parameter description; an example would be, for the "zoom" parameter of
> the "googlemap" format, "The zoom level of the map (must be an integer
> between 1 and 18, with '
It's definitely a matter of taste, but there is nothing wrong in going in
both directions where superclass implements parametrized input and
subclasses implement their own forms if they want - this way there is path
for extended solutions in subclasses and still there can be generic
implementations
Markus - I think any info on the type of the parameter can just be part of
the parameter description; an example would be, for the "zoom" parameter of
the "googlemap" format, "The zoom level of the map (must be an integer
between 1 and 18, with '1' being the furthest away)".
Sergey - it's true tha
Hey, I'm back from San Francisco and what I find? the Special:Ask discussion
is getting hot ;)
I have a few things to input - my experience shows that building universal
UI builder is a hard thing to do - Yaron can probably second that. My
approach to this problem before was to have subclasses bui
I am convinced :-). What remains unclear to me is how to report the expected
input type of a parameter to a UI-creating interface. The types are not really
standard things like "integer" and "string" but also things like "some
template name" or "the name of a property printout in the query". Sho
Hi,
This is great - the self-description/"reflection" feature will be allow for
a big improvement to Special:Ask (and evidently Halo as well). This, in
addition to Sergey's previous changes, turns Special:Ask from somewhat of a
hacker interface to an easy-to-use entry point for those getting start
As promised, SMW has now been updated to support some of the requested
functionalities:
* To get the list of all available formats, access $smwgResultFormats.
* To get a result printer object, use SMWQueryProcessor::getResultPrinter().
* To get the name of a printer object, use $printer->getName(
On Mittwoch, 1. April 2009, Yaron Koren wrote:
> I think a way for formats to publish both a description of themselves and
> the set of parameters they take would be very helpful: it could be that the
> easiest way to do it is just to expand the information that
> $smwgResultFormats holds, although
I think a way for formats to publish both a description of themselves and
the set of parameters they take would be very helpful: it could be that the
easiest way to do it is just to expand the information that
$smwgResultFormats holds, although maybe the better solution is, as you
suggest, to add m
10 matches
Mail list logo
