On Mittwoch, 5. August 2009, Yaron Koren wrote: > I think this is a great idea, both as a concept and in the specific syntax > you've chosen. It certainly is nice to be able to associate addiitional > parameters with each column/field, especially for things like sorting on > multiple columns. For date formatting it could also be very helpful; it > doesn't seem like that much of a stretch to be able to add something like > "|+ format=Y m d hh:mi", to a date property, using the standard PHP > date-formatting syntax.
That feature could actually already be implemented using # (ouptut formats). The reason why it is not there now is that we can no longer use the PHP date formatting functions since our dates can (1) be out of their 32bit range and (2) might be incomplete, so that some components should be empty even if they appear in the format. I think a simpler custom formatting that supports a subset of the PHP features would be possible. > A few questions/comments: > > 1. What would a "limit" parameter on a field accomplish? Why would you want > to limit one field to a different number of results than others? For example: you want to display items with their Property:name value as their label, and for each item you want to show all, say, email addresses. Doing this in a templated-format works, but gives you bad results whenever someone has multiple names (like Denny ;-). But you still don't want to restrict to only one email address in your result. > > 2. Markus sent an email recently talking about a new feature planned for > SMW 1.4.3, where adding "#" to the name of a queried property, like > "?population#", returns an unformatted value, like "1234" instead of > "1,234". That could presumably be handled by this new system as well, and > probably in a less cryptic way, by adding something like "|+format=none". > Given that, maybe it makes sense to just skip that other feature, if it's > only going to be useful for (say) a few months? You are right, but the syntax with "#" is already around for a long time. It could be replaced by the new parameters, but we cannot escape the fact that it is already in use. Maybe # will vanish at some point, but this needs some transition time. > > 3. On that note, are features like setting the column header via > "?population=Pop." also going to get deprecated, since they too could get > replaced by something like the possibly-less-cryptic "|+label=Pop."? Personally, I think that "?population=Pop." is pretty readable and useful. I would like to keep it. It is arguably a very common task to set these labels, so it should be justified to have a more compact syntax for those. -- Markus > > -Yaron > > > On Tue, Aug 4, 2009 at 5:00 PM, Denny Vrandecic > > <d...@aifb.uni-karlsruhe.de>wrote: > > Hi all, > > > > here's a request for comments on a planned feature. > > > > A problem in SMW is that there is no proper syntax to give parameters > > to print requests, with two exceptions that have been there since the > > very first implementation of print requests, = and # (like in ? > > length#miles or ?population=pop.). It often would have been very > > useful to add further parameters, like limit the results to 1, sort > > them alphabetically, align them right, show only three significant > > digits etc. > > > > In order to address this we would like to see implemented for SMW 1.5 > > a feature to add parameters to print requests. After some > > brainstorming and discussion (that has been ongoing for months, to be > > honest) we had a number of possibilities (like "?population=pop > > (align=right)") and we did not like most due to various reasons, but > > now we think we have something workable: > > > > {{#ask: [[Category:City]] > > > > | ?Population | +align=right > > | ?Inhabitant | +limit=3 | +sort=asc > > | limit=10 > > > > }} > > > > i.e. every parameter that starts with a "+" and following a print > > request and before the next print request is considered to be a > > parameter for that print request and not for the query as a whole. > > > > Opinions are welcomed. > > > > Best, > > denny > > > > > > ------------------------------------------------------------------------- > >----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > > 30-Day trial. Simplify your report design, integration and deployment - > > and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > 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.
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel