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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
