I think you're confusing two issues here, H.
- One is whether you deal with Groups or with
Permissions.
- The other is whether you hard-code
things.
Now I can certainly deal with the fuse that you have
described. It expects a Boolean variable, and, as I have explained, I
can create and use variables of that form using my model. There's no
incompatibility.
But your fuse specification is equivalent to
mine:
<in>
<list
name="groupsThatCanDeleteDocument">
</in>
I don't need to re-code my fuse
when the rules change. (We are trying
the complete set of fallacious rhetorical devices - we can tick off "the Straw
Man Attack" now.)
See, the one thing you haven't yet told us (I think) is
how you go about determining what permissions the current user actually
has. You have to do it somewhere, I'm sure. Most likely you
do it in much the same way that I do, eg:
<cfif isMember("administrators")>
<cfset canChangeThings = true>
</cfif>
...or some BitWise equivalent.
So your point about hard-coding is perfectly true. I
agree. I don't hard-code. You don't hard-code. You avoid
hard-coding by passing around Permissions as bit flags in a bit array. I
avoid hard-coding by passing around lists of Groups in a string. I can
go further if I like and create bit arrays of Permissions or bit arrays of
Group memberships, but I don't usually have a need.
(I do use Bit arrays for passing around
other sets of flags, though. Have a look at the wireframetool. I
have nothing against bits or against flags. In terms of authorisation
and customisation, though, it's an extra level of reductionism that seems to
serve no significant purpose, while entailing an extra level of complexity for
those who have to do the work.)
See ya later, matey
LeeBB
----- Original Message -----
Lee, here's a Fusedoc showing a permission needed by a fuse. For
maximal reusability and maintainability, the fuse makes no assumptions about
HOW someone got a permission, whether by belonging to group A or group B or
whether granted the permission without belonging to any group.
<in>
<Boolean name="canDeleteDocument" />
</in>
Here we have a concept of a permission that has no explicit
connection with a user group. Any application that wants to use this
fuse can do so, simply by setting a value of TRUE or FALSE for this
permission. How's the value set? The fuse doesn't care. Maybe the user
belongs to a privileged user group; maybe the user is the uncle of the chief
programmer; maybe this is a game and the values for
canDeleteDocument are generated randomly (stranger things have
happened).
Or
say we use the fuse in two applications. In one application, group A HAS
permission to delete a document, but in another application, group A does
NOT have permission to delete a document. Now, you have to go into the code
and start making changes to the fuse. We used to hardcode fuseactions into
fuses, but we found the introduction of XFAs made our code more
adaptable and reusable. The concept of permissions as distinct from groups
does the same thing for security.
==^================================================================
This email was sent to: [EMAIL PROTECTED]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bU4xFm
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
