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
Hi,
I am working on our query front-end for inline ask queries which, in the
next version, immediately shows your result set while you are creating
your query.
In order to (dynamically) support all available result printers and to
not hardcode all this stuff which might change in the future I f
11 matches
Mail list logo
