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 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 because it's a
lot more work, and second because, if we do come up with a good UI, I bet
it'll be fine across all formats.
To illustrate my point for both, I put together a mockup of what a simple
interface, using the parameter declarations, could look like. Using
Javascript, the form would change the set of parameters available for the
user to fill out every time they re-selected a format from the dropdown.
Here's what it would look like if the user selected the 'list' format:
http://discoursedb.org/new-special-ask.png
-Yaron
On Mon, Apr 6, 2009 at 10:57 AM, Sergey Chernyshev <
sergey.chernys...@gmail.com> wrote:
> 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 build their own forms
> and parse their own parameters, similar to how extending MW preferences
> interface is done.
>
> This is a way to avoid new constants and constraints on input UI parameters
> for specific query printers, more over, since all of this functionality is
> implemented in PHP and not reading user-generated content within the pages,
> I think it makes the most sense to just leave it to subclassing approach
> which will allow more flexibility for SRF implementors.
>
> Thank you,
>
> Sergey
>
>
> --
> Sergey Chernyshev
> http://www.sergeychernyshev.com/
>
>
> On Mon, Apr 6, 2009 at 10:01 AM, Markus Krötzsch <
> mar...@semantic-mediawiki.org> wrote:
>
>> 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". Should
>> we
>> introduce yet another system of type constants?
>>
>> -- Markus
>>
>> On Montag, 6. April 2009, Yaron Koren wrote:
>> > 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 started
>> > with Semantic MediaWiki and inline queries. Actually, the more I think
>> > about it, the more I think this is a big step forward in turning SMW
>> into a
>> > real consumer application, since it will mean that people can run (and
>> > administrators can save) queries on the data without needing to read
>> > through a lot of documentation.
>> >
>> > To that end, I would say that yes, there should be descriptive labels
>> for
>> > each printer, retrieved from message files - just as there should be
>> labels
>> > for each parameter. Having good inline help is very common among mature
>> > software applications - it's considerably easier to use than a user
>> > handbook. Obviously, it becomes an issue if someone wants to put whole
>> > paragraphs or even pages into the application, but a simple one-sentence
>> > description of each concept is, I think, completely reasonable. And I
>> > should note another veery important reason to put such information into
>> the
>> > application - to enable translation; which should make creating inline
>> > queries quite a bit easier for those who can't speak English.
>> >
>> > Finally, if you're at all considering adding more meta-data to each
>> > printer, let me suggest another field: a "default limit" value, which
>> would
>> > override the wiki's value for $smwgQDefaultLimit (though not a "limit="
>> > parameter set in the query). This would allow the "math" formats in SRF
>> > (sum, average, min, max) to considerably raise the number of values
>> passed
>> > in to them by default, since all of them, especially 'sum', require all
>> > values to be passed in to produce a meaningful result. It would
>> similarly
>> > be helpful for 'calendar'. A default limit value could also be helpful
>> for
>> > the export formats (csv, json, icalendar, rss), although for them
>> there's
>> > already a workaround because they create, essentially, a link to
>> > themselves, with that link setting the correct limit.
>> >
>> > -Yaron
>> >
>> >
>> > On Sun, Apr 5, 2009 at 12:24 PM, Markus Krötzsch <
>> >
>> > mar...@semantic-mediawiki.org> wrote:
>> > > 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().
>> > >
>> > > The new functions are documented in the code (or see the API docs).
>> > >
>> > > The format selector for Special:Ask has been improved to use these
>> > > features.
>> > > Note that not all SRF formats provide localised names yet; examples on
>> > > how to
>> > > add translations are found in all SMW result printers and in some of
>> the
>> > > SRF
>> > > printers.
>> > >
>> > > There was also another change: printers that only show download links
>> > > when used inline can indicate to SMW that no query needs to be
>> executed
>> > > in this case. To do this, simply implement the method getQueryMode()
>> as
>> > > e.g. in SMW_QP_CSV.php. If you do not do this, SMW will always compute
>> > > all query results, even if the printer ignores them anyway.
>> > >
>> > > Besides Name and QueryMode, no further meta-data has been added.
>> > > Especially, I
>> > > do not know yet how to provide information about available parameters.
>> > > There
>> > > is a list of parameter identifiers, but what else should be there for
>> > > each of
>> > > them: localised labels, expected type of input, anything else? Also, I
>> > > was unsure whether longer descriptions besides the names should be
>> > > available for
>> > > printers -- doing this feels like moving the user handbook to the
>> message
>> > > file.
>> > >
>> > > Cheers,
>> > >
>> > > Markus
>> > >
>> > > On Donnerstag, 2. April 2009, Markus Krötzsch wrote:
>> > > > 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 maybe the better solution is,
>> as
>> > > > > you suggest, to add methods like getDescription() and
>> > > > > getAllowedParams() to the SMWResultPrinter class, and allow any
>> > > > > format class to override
>> > >
>> > > these
>> > >
>> > > > > methods.
>> > > >
>> > > > I also agree with Jörg's observation. I strongly favour Yaron's
>> second
>> > > > proposal: extending the printer class instead of extending the
>> static
>> > > > array. A related solution has been in my mind for some time, but I
>> did
>> > >
>> > > not
>> > >
>> > > > find time to implement it yet:
>> > > >
>> > > > * In order to keep the information that is available for each result
>> > > > printer flexible and extendible, it would be best if the printer
>> > > > objects would implement access methods for this information. Two
>> main
>> > > > advantages are:
>> > > >
>> > > > (1) The meta information is kept with the code of the printer class,
>> so
>> > > > printer format extensions like SRF are still easy to implement in
>> one
>> > >
>> > > file.
>> > >
>> > > > (2) The abstract result printer parent class can always implement
>> > >
>> > > fallback
>> > >
>> > > > methods, so that non-core printers are compatible to new SMW
>> versions
>> > >
>> > > even
>> > >
>> > > > if they do not support this meta-data yet.
>> > > >
>> > > > * The task then boils down to getting a printer object for a given
>> > >
>> > > printer
>> > >
>> > > > identifier (like "ul"). In order to be perfectly compatible with
>> SMW,
>> > >
>> > > this
>> > >
>> > > > should be done by calling SMWQueryProcessor::getResultPrinter(). The
>> > > > problem is that this function currently requires further parameters:
>> > > > especially it depends on the query result. This is not really needed
>> > > > and can be avoided with some extra coding from my side.
>> > > >
>> > > > * What remains to discuss is what meta information it is that each
>> > >
>> > > printer
>> > >
>> > > > should provide. A human readable name would be a good start, I
>> guess.
>> > > > Another useful feature might be a function that returns the list of
>> > > > supported additional parameters with a short "signature" to indicate
>> > >
>> > > their
>> > >
>> > > > input type (How should this look? How do you get labels/descriptions
>> > > > for these parameters?). Anything else?
>> > > >
>> > > > I think I can provide the implementation over the weekend then.
>> > > >
>> > > > -- Markus
>> > > >
>> > > > > -Yaron
>> > > > >
>> > > > > On Wed, Apr 1, 2009 at 4:25 AM, Jörg Heizmann <
>> heizm...@ontoprise.de>
>> > >
>> > > wrote:
>> > > > > > 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
>> > > > > > found the array holding name and class of each available result
>> > > > > > printer ($smwgResultFormats). That's pretty cool but I cannot
>> get
>> > > > > > additional meta information for each printer.
>> > > > > >
>> > > > > > I doubt that users understand that "ul" stands for "unordered
>> list"
>> > >
>> > > so
>> > >
>> > > > > > I would love to have a short description (maybe also a longer
>> one)
>> > > > > > method for each result printer.
>> > > > > > Also, some printers support additional parameters which are
>> > > > > > necessary for the frontend to know about. Here, a second method
>> > > > > > would be nice
>> > >
>> > > to
>> > >
>> > > > > > have in order to not hard-code this information.
>> > > > > >
>> > > > > > What do you think about these additions?
>> > > > > >
>> > > > > > cheers,
>> > > > > > Jörg
>> > >
>> > >
>> -----------------------------------------------------------------------
>> > >
>> > > > > >-- ----- _______________________________________________
>> > > > > > Semediawiki-devel mailing list
>> > > > > > Semediawiki-devel@lists.sourceforge.net
>> > > > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>> > >
>> > > --
>> > > Markus Krötzsch
>> > > Semantic MediaWiki http://semantic-mediawiki.org
>> > > http://korrekt.org mar...@semantic-mediawiki.org
>>
>>
>> --
>> Markus Krötzsch
>> Semantic MediaWiki http://semantic-mediawiki.org
>> http://korrekt.org mar...@semantic-mediawiki.org
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>>
>>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
