On Friday 10 January 2003 16:16, J�rg Walter wrote:
> > Conceptually, it might be argued it would be nicer to seperate the
> > input stuff (encrypted and clear) from the output stuff (true,
> > false), but I don't feel too strongly about that.
>
> Yeah, that's why I don't like it.
Good to hear there are more purists around! :-)
> OTOH, this is indeed the shortest
> way if you want true and false.
Yup. Of course, you could put the true and false elements within a tag,
like
<auth:password-matches>
[...]
<auth:output>
<auth:false>Password is invalid</auth:false>
<auth:true><strong><xsp:content>Password is
valid</xsp:content></strong></auth:true>
</auth:output>
</auth:password-matches>
that would hurt anybody, but I can't see a way to do the same with the
input parameters without braking backwards compatibility. But then, I
can't see the _big_ advantage, it is obviously good to separate
elements that are conceptually similar and different in blocks, but
considering the length of the code and the backwards compatibility
issue, I think it is a reasonable trade-off to forget about such
blocks... :-)
>Here's how to do this:
>
> sub password_matches__true___open {
> return 'if (crypt($attr_clear,$attr_encrypted) eq $attr_encrypted)
> {' }
> sub password_matches__true {
> return '}'
> }
> sub password_matches : expr child(encrypted,clear) {
> ...
> }
>
> I hope you get the idea.
I think so! I'll play with it.
>$attr_foo is in scope for the child elements
> as well unless there's some other element in between which overrides
> it. We depend on auth:clear and auth:encrypted to occur before
> auth:true, obviously.
OK!
> Btw, in "password_matches__true___open" that's
> one underscore for the "-" in "password-matches", two underscores for
> matching auth:true only below auth:password-matches, and then three
> to specify the open-event.
Yup, that I've learnt from the docs...! :-)
> > How about
> > <auth:single-access-ok type="user" name="guest"/>
> > <auth:true><p>sorry, only for registered users</p></auth:true>
> > </auth:single-access-ok>
>
> hmm... there is auth:has-permission.
Yep, I just threw something forward.
> Actually, I begin to like your idea.
Great!
> I only wished there was something I could do to generalize
> this, as it is obviously fot for many places. Perhaps some additional
> SimpleTaglib feature...
Yeah, I think that would be very cool!
>From my perspective (as one who is just trying to use it), if you could
make another result attribute, for example 'boolean', that would imply
that if either or both of child elements true or false existed, the
return value of the element would be that which is determined to be
true or false by the sub, which is free to use the input attributes to
determine this. If neither true or false are present, the return value
is 1 or 0. So, I imagine a new result attribute to use for this kind of
tags. Does that sound sensible?
I looked at TaglibHelper as Matt suggested. There is clearly some
important functionality there. I found this post by Steve by googling:
http://maclux-rz.uibk.ac.at/~maillists/axkit-users/msg00938.shtml
(search for "conditional"). You can declare a tag "conditional" and the
contents of the tag will be displayed based on that condition.
Parts of that is certainly worth looking at, but it has a couple of
limitations too, for one thing, it can't be made backwards-compatible
with the tags now in the Auth module. Then, I find it more appealing to
have two true and false elements as child elements to the tag, than
have only the positive outcome as content in the tag itself. Also you
would have to have two tags AFAICS to account for both outcomes?
Finally, the conditions must be in attributes. So, thinking hard about
a new feature would be great! :-)
(BTW, Steves post may deserve a more prominent display by going into the
Wiki, but where?)
Best,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Homepage: http://www.kjetil.kjernsmo.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
