On 21/05/12 11:06, Markus Krötzsch wrote:
> On 20/05/12 22:45, Jeroen De Dauw wrote:
>> This mail is mainly directed at Markus, but sending it to the list for
>> transparency sake.
>> I started working on making the link generation (ie for the "further
>> results" links) in SMWResultPrinter more generic so we can get rid of
>> the buggy and inconsistent code currently adding arguments to these
>> links. Turns out that right now the result printers do not have
>> sufficient information to do this. They need to know if a parameter was
>> set by the user or not, so they can add only those values in the link.
>> The SMWResultPrinters are only getting an array with param names
>> pointing to param values though, which needs to change to include the
>> full parameter objects as returned by Validator, which do hold the
>> information if the value was set by the user or not. This list of param
>> values is also passed around in SMWQueryProcessor at several places, and
>> would also need to be changed there. And this would break compat with
>> existing code extending SMWResultPrinter and overriding it's entry point
>> (getResult) and using the relevant SMWQueryProcessor methods. Making
>> such code work with the new version is relatively simple.
>> Any thoughts on this, in particular the loss of compatibility?
> Sounds like a good idea to me, and I can see that the required update in
> existing code would be minimal. The change of compatibility will require
> fairly synchronized update of SRF and SMW (and maybe other extensions
> with custom formats).
P.S.: Ignore this line: toString() for parameter objects would be a b/c
option in a saner programming language, but the change to take advantage
of this in PHP is about as big as the change for accessing parameters in
the usual way.
>> Jeroen De Dauw
>> Don't panic. Don't be evil.