Hey,
> and for recording errors, i.e. we would still use SMW's error reporting
mechanisms
Yes, Validator keeps track of errors, but does not display them, which is up
to whatever code that's using it. (However, it does have a parser hook
which can be used to display all errors on a page, but thi
On 16/03/11 10:38, Jeroen De Dauw wrote:
> Hey,
>
> > Is it worth giving it another chance at the MediaWiki "Hackathon" in
> Berlin in May, though, assuming you're going to that? Perhaps in person
> people will be less likely to just ignore the issue? It's only two
> months away, so maybe it's wor
Hey,
> Is it worth giving it another chance at the MediaWiki "Hackathon" in
Berlin in May, though, assuming you're going to that? Perhaps in person
people will be less likely to just ignore the issue? It's only two months
away, so maybe it's worth waiting.
I'm going yes, but am not to positive ab
On 15/03/11 18:34, Jeroen De Dauw wrote:
> Hey,
>
> > Before we approach this from scratch
>
> Well, since Validator already exists (and IMO has proven very well how
> useful it is in some of my extensions), it's only building the second
> half of the bridge, not staring from scratch.
>
> > Would
Hi,
I'm tentatively in favor of adding Validator as a requirement to SMW, given
all the benefits it would provide - then it could be used by all the
SMW-based extensions, as well.
The better option would be if the Validator functionality could be included
directly in MediaWiki, though who knows w
Hey,
> Before we approach this from scratch
Well, since Validator already exists (and IMO has proven very well how
useful it is in some of my extensions), it's only building the second half
of the bridge, not staring from scratch.
> Would it make sense for SMW to use Validator?
I'd not be sugge
On 15/03/11 17:39, Jeroen De Dauw wrote:
> Hey,
>
> Instead of extending the array-based parameter definitions used now, I
> think it makes a lot of sense to use the Validator extension for that.
> Originally it also had an array-based approach, but this gets really
> messy, complex and hard to und
Hey,
Instead of extending the array-based parameter definitions used now, I think
it makes a lot of sense to use the Validator extension for that. Originally
it also had an array-based approach, but this gets really messy, complex and
hard to understand as you add more things to it. Now each param
Hi,
Right - although "limit=" does get used in regular #ask queries (pretty
often, actually), so I think it makes sense to define it as a real parameter
with its own input.
The idea of having defined parameters that don't get displayed in the
Special:Ask form is an interesting one. I guess the re
On 15/03/11 16:39, Benjamin Langguth wrote:
> Hi,
>
> that's a bit confusing for me because 'offset' is just working fine for
> my standalone inline queries.
> E.g. for 4 existing instances of 'Category:Test'
>
> {{#ask:[[Category:Test]]
> |offset=3
> }}
>
> displays only one result.
> So i think
Hi,
that's a bit confusing for me because 'offset' is just working fine for
my standalone inline queries.
E.g. for 4 existing instances of 'Category:Test'
{{#ask:[[Category:Test]]
|offset=3
}}
displays only one result.
So i think it is (or maybe evolved in the meantime to) more than just a
"h
Hi,
I believe that was my decision - when I populated that getParameters() call,
I decided not to include 'offset', even though it's an allowed parameter,
because it seemed to only get used by Special:Ask, to do pagination, and not
within standalone #ask queries. So it didn't seem like a true para
Hello at all,
i was just working with different result printers and one question came
up for me.
The abstract class SMWResultPrinter [1] is implemented by each (new)
result printer and contains a function called getParameters to offer the
supported parameters.
I found the parameter 'limit' in
13 matches
Mail list logo
