I have two personalities here :)
The first personality just wrote a proposed documentation change to
reflect what I understood Sebastian said about the purpose of ok_tables.
I don't care what we decide it means, as long as we're clear! And
indeed, prompting this discussion is already a healthy and useful result.
The second personality does software design :) It seems to me that what
Peter is trying to do revolves entirely around access control. Whether a
user should be able to see a price or change a price or even be aware
that something has a price is something that should be handled by an
authorization component. Once it's decided what a user is entitled to,
display_tables can be populated accordingly (and ok_tables can be
derived automatically as a cache), edit buttons can be provided or not
as appropriate etc. I haven't looked at authorization in Maypole at all,
so I have no idea how much or little of this is provided. Granted the
templates would need an upgrade.
So my long term perspective would be that Peter's requirements would be
better met another way than using ok_tables. But in the short term,
Peter has code that depends on users being allowed to manipulate
ok_tables, and I have no idea whether there's a better way he could use
right now?
Switching back to my first persona ...
On the basis of the information I have right now, I'd suggest saying:
This is a hash of the public tables that is available to templates.
Normally, it is populated automatically by Maypole from the list in
display_tables. Presently, users can instead load a list of tables into
this attribute, which must include at least all those tables in the
display_tables list. This facility is liable to be replaced in some
future release by an authorization-based mechanism.
Cheers, Dave
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT