Last modified: 2009-08-02 14:37:15 UTC
See detailed message "special [[Property:Has format]] (was Re: [SMW-devel] [News] Plans for SMW 1.4)" in response to the "Plans for 1.4" thread. I pasted the whole thing in here I want to be able to specify the appearance of values using a new special [[Property:Has format]]. Here are some wishes and use cases: * I want numeric IDs to appear without commas! "Build 4,231" or "Bug 12,345" isn't right. * I should be able to make something appear as a link everywhere, e.g.. ** I want a bug to appear as [http://bugzilla.wikimedia.org/show_bug.cgi?id=14426 bug 14426] everywhere. ** I want coordinates to appear as a link to Google Maps everywhere. * I should be able to "reach in" and adjust the appearance of a Type:Page link, e.g. specify |55px for an Image. * Bring back the date formatting that was in SMW 0.7 (bug 11853) * Type:Code seems like overkill just to tell MediaWiki to display something in <pre> tag. Currently there are three different ways that you control the appearance of values: * In the original annotation you use alt text, possibly using a template, * In the factbox and "Pages using the property foo" list you have no control! but you can tack on service links * In inline queries you can use format=template but it's implemented differently than service links. I think a lot of this can be handled by a special property [[Has format::]]. You give it a complicated formatting string. Maybe you have to indicate whether the result is HTML or wiki text. SMW makes available to your formatting string all the different values it already computes for its datatypes (value, xsd, shortwiki text, etc.), possibly similar to the way service links are passed different values. You would still be able to override the format in queries by specifying a different format using the ?Name#Some_format, just as you can currently specify the units for a column. If service links are going to die, then maybe their idea can be preserved by supercharging [[Has format]] to let you specify the entire "look" for a value, including * the visible display, including the formatting of numbers and dates * the hyperlink for the value * the contents of the hover pop-up (like the one you get over a quantity with several units) * the contents of the service links "(?)" pop-up. That's a lot of work but it could lead to code simplification because instead of all the hardcoding of showing unit conversions and coordinates in brown and making special wiki links for Type:email, these would be driven by a default Has_format for each datatype, that user code could override.
This is exactly what I need, too. To be honest, I didn't believe this *not* to be possible with SMW when I started playing around with it, gathering the basics for the last few weeks (see [1] and [2]). I think anyone actually really *using* SMW will be in need of this. Default (but unchangable) formatted output can only be useful in a handful of cases. Once I stored all my precious information in properties, I need to get it out again in the form it's supposed to be shown. [1] http://www.nabble.com/Displaying-a-sortable-table-with-custom-date-format-in-columns-td19425042.html [2] http://www.nabble.com/Output-number-type-property-with-different-precision--to19551191.html
I can see that this could be a useful feature, but the above description already would make it very complex. In the end, you essentially want templates to be used for formatting the output (essentially a wiki-ized "formatting string"). I fear that this could lead to rather bad performance since you could easily have hundreds of template calls for some long list of query results. Also, the problem is what to pass to the template. As for service links, one might need many different basic forms in order to ensure that a template can achieve the desired formatting. Again this is not going to speed up things. An alternative that I see is to use the "output formats" that SMW already has for #ask printouts of various types, extending them for individual datatypes and using such a default format for all displays. Of course, this would be less powerful, but it might be less complex and easier to compute with. Maybe this was even in the spirit of your initial request.
