Hey,
(Full replied to message can be found here:
http://pastebin.com/J0aLk2t9)
Please respond to appropriate mail list -- either
WikiTech-L
Might be interesting to people here :)
But I found terminology used in Validator frustrating
and misleading.
Well yeah, I agree, the names parameter and argument are used pretty
loosely through the extension.
However, it will break compatibility with existing
Validator… What do you
think? It is possible? How manage compatibility? Create
incompatible
Validator2?
In general I agree with your remarks, but it's not really possible to just
change this on the fly, as it would break a lot of compatibility. I suggest
creating a new alternate system while keeping the old one, so things can
gradually be migrated, and then have the old thing go when it's no longer
used.
In particular, I'd like to split the param definition from the parameter
(with value) handling functionality. Since the Parameter class is used all
over the place to define parameters, changing this one would be hard. I
also thing it's not that bad of a name, and clearer then Descriptor. So
maybe it's better to find an alternate name for the "parameter with value"
class, which is only used in Validator itself anyway. And I'd like to have
a more lightwight way of defining parameters, rather then creating a
Parameter object for each. In most cases an associative array suffices,
which can then be turned into an object later on.
And I think the current way parameter criteria and manipulations are
defined sort of sucks. You need a class for each, while often you want to
do very simple stuff. Passing in a function should also work. In PHP 5.3+,
anon functions would make a lot of sense here. If a separate parameter
definition class is cerated, it might actually make a lot of sense to have
doValidation and doManipulation methods in there. This does not allow to
share criteria and manipulation objects like the current system, but is
probably less of a hassle and less over engineered.
Also, I'd like to get rid of the evil LSB hack in the ParserHook class, but
guess it's still to early to do that (since you'd need PHP 5.3+).
Any such changes would contribute to a new mayor release, version 0.5. The
last big changes, those for 0.4, where made over a year ago, and although I
see a bunch of stuff that could be made better architecture wise, the
current system works. So I'm not that keen on making these changes now and
deal with all the compatibility issues. (Maybe after SMW 1.7 has been
released.) But if you feel like poking at it or writing up a proposal for a
new architecture, please do, I'll happily provide feedback.
BTW, in many languages positional arguments are
allowed before the first
named argument. Validator allows:
{{ #func: pos1… | namedA=… | pos2… | namedB=… }}
Yeah, it does allow this. Originally it did not, but I figured some users
might not understand or think about the difference, so I just added this
because it works. I don't see what your issue with this is. I don't know
how this is called, but don't see how that matters :)
I am sure Validator is a great idea and really helps.
I used it in few my
extensions. I also wrote parser function `#validate' to
validate template
arguments and use it in almost all my templates!
Well, please share your code - sounds like this could be useful to other
people as well ;)
Although the current architecture might need some tweaking to become really
nice, I think having a declarative system for parameters is very powerful
as it allows for a whole range of cool things, which is why I created the
extension in the first place. Since then I've only become more convinced of
this, and would really like to see such functionality get put into core at
some point, in one form or another. Any comments on this are appreciated.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--