Hey,
(This is take 2 on this subject, as the last thread derailed into parser
internals discussions which have rather little to do with the Validator
extension. I also added some dev docs [1] which are likely to provide a
better picture of the extensions function.)
Over the past year I've been wo
Daniel Friesen wrote:
> I think there's a little more difference between setHook and
> setFunctionTagHook than you mention.
> At the very least, extensionSubstitution outputs a function tag hook
> directly, while putting a normal tag hook into the general strip state
> and outputting a marker.
>
On 11-01-31 09:36 AM, Platonides wrote:
> Daniel Friesen wrote:
>> setHook (old style tag hooks), and setFunctionTagHook (new style function
>> tag hooks).
>>
>> setHook and setFunctionTagHook both set style hooks. Originally we
>> just had setHook, it had one short argument list. Later on that a
Daniel Friesen wrote:
> setHook (old style tag hooks), and setFunctionTagHook (new style function tag
> hooks).
>
> setHook and setFunctionTagHook both set style hooks. Originally we
> just had setHook, it had one short argument list. Later on that argument
> list was changed to add $frame to
Hey,
That makes it rather clear I'm not familiar enough with the parser to
implement a wrapper class such as ParserHook. Most extension developers will
likely not know a lot more then me about it, so I think there definitely is
a need to provide some abstraction for the most common use cases, whic
On 11-01-30 02:46 PM, Jeroen De Dauw wrote:
> Hey,
>
>> From the looks of the code, Validator, and various Validator based
> extensions appear to be using parser->parse() inside of hooks where they are
> supposed to be using ->recursiveTagParse with a proper frame.
>
> I was not aware of the corre
Hey,
> From the looks of the code, Validator, and various Validator based
extensions appear to be using parser->parse() inside of hooks where they are
supposed to be using ->recursiveTagParse with a proper frame.
I was not aware of the correct approach here apparently. I had a look at the
docs an
Thanks for pointing this out; I'll fix it soonish.
Please post such issues on the extensions discussion page or bugzilla. They
have nothing to do with the Subject of this thread.
Send from my Android phone.
On 30 Jan 2011 01:30, "Daniel Friesen" wrote:
> While reviewing SubPageList to see if it
While reviewing SubPageList to see if it was good enough quality to
install on a wiki of mine, I came round to Validator double checking it
(since SubPageList uses Validator).
From the looks of the code, Validator, and various Validator based
extensions appear to be using parser->parse() insid
On 01/13/2011 08:38 AM, Robert Leverington wrote:
> On 2011-01-13, Jeroen De Dauw wrote:
>> Hey,
>>
>> Although the tag name issue is a valid point, it has nothing to do with my
>> original email. So please start a separate discussion rather then hijacking
>> this thread.
>
> It is entirely to do w
Hey,
> It is entirely to do with your originl e-mail, as it is a valid reason
> why your original request (inclusion of Validator in core) should not be
> carried out at this time, and discussion of it is important (at least if
> you intend to improve the extension to overcome this issue).
This i
On 2011-01-13, Jeroen De Dauw wrote:
> Hey,
>
> Although the tag name issue is a valid point, it has nothing to do with my
> original email. So please start a separate discussion rather then hijacking
> this thread.
It is entirely to do with your originl e-mail, as it is a valid reason
why your o
Hey,
Although the tag name issue is a valid point, it has nothing to do with my
original email. So please start a separate discussion rather then hijacking
this thread.
Cheers
--
Jeroen De Dauw
http://blog.bn2vs.com
Don't panic. Don't be evil.
--
On 13 January 2011 03:19, Daniel Friesen wrote
On 11-01-12 03:17 PM, Platonides wrote:
> Brion Vibber wrote:
>> On Wed, Jan 12, 2011 at 5:53 PM, Jeroen De Dauwwrote:
>>
>>> Hey,
>>>
I think would be parsed as the tag hook "display" with a
>>> parameter "map"="map". Would this prevent any use of the hook registered as
>>> the tag "display
On Wed, Jan 12, 2011 at 6:13 PM, Jeroen De Dauw wrote:
> > That seems highly contrary to expectations when dealing with tag hooks.
> What if there's a tag hook "display" registered by another plugin, does it
> get overridden? Overridden only if a "map" parameter is supplied?
>
>
> That's a good po
Brion Vibber wrote:
> On Wed, Jan 12, 2011 at 5:53 PM, Jeroen De Dauw wrote:
>
>> Hey,
>>
>>> I think would be parsed as the tag hook "display" with a
>> parameter "map"="map". Would this prevent any use of the hook registered as
>> the tag "display map"...?
>>
>> This code has been there for a f
Hey,
> That seems highly contrary to expectations when dealing with tag hooks.
What if there's a tag hook "display" registered by another plugin, does it
get overridden? Overridden only if a "map" parameter is supplied?
That's a good point, which I did not consider when naming the hook like
this.
On Wed, Jan 12, 2011 at 5:53 PM, Jeroen De Dauw wrote:
> Hey,
>
> > I think would be parsed as the tag hook "display" with a
> parameter "map"="map". Would this prevent any use of the hook registered as
> the tag "display map"...?
>
> This code has been there for a few months now, and appears to
Hey,
> I think would be parsed as the tag hook "display" with a
parameter "map"="map". Would this prevent any use of the hook registered as
the tag "display map"...?
This code has been there for a few months now, and appears to be working as
expected. The tag extension gets handled properly and
On Wed, Jan 12, 2011 at 3:51 PM, Jeroen De Dauw wrote:
> Hey,
>
> > After grepping for setHook, it turns out that an extension like Maps,
> that
> has zero matches, sets parser hooks indirectly via Validator extension.
>
> Indeed. Innovation cannot happen without change. I'd argue that deriving
>
Hey,
> After grepping for setHook, it turns out that an extension like Maps, that
has zero matches, sets parser hooks indirectly via Validator extension.
Indeed. Innovation cannot happen without change. I'd argue that deriving
from the ParserHook class makes it easier to find parser hooks, but th
Well, I just had an issue with Validator, so I am not too sympatatic
with your extension right now ;)
After grepping for setHook, it turns out that an extension like Maps,
that has zero matches, sets parser hooks indirectly via Validator
extension. And not only that, but it also sets a hook for a d
Hey,
Over the past year I've been working on an extension to facilitate parameter
handling in MediaWiki, with a focus on parser hooks. It's titled Validator
[0], which currently is a bit misleading since it enables a lot more then
simple validation. As the only thing this extension does is facilit
23 matches
Mail list logo
