--- Dave Howorth <dhoworth at mrc-lmb.cam.ac.uk> wrote:
>
> 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.
Yes. Access control.
> 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.
No. Not an authorization component. Access control. Access is just worried
about access. Not who is accessing it. I'm not sure how to say it but What
maypole does with ok_tables is perfect except maybe it should have been called
accessible_tables.
Dave, Maypole::Manual::Request has a great example of
authorization/authentication in Maypole. Its a good system. Basically you make
override "sub authenticate{ }" in your Controller. Thats the front door --
check cookie, redirect to login page, and return OK to let them in. Then each
table (model class) can have a sub_authenticate to specify further
authorization. Its cool and easy.
>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?
>
I believe i confused everyone as i was confused til now. My requirements
really are to have a
1. To be able to say what tables i want access to. (ok_tables)
2. To specify which business objects I want on the navigation system.
(display_tables)
Maypole kindly does that perfectly. I keep finding its nicer and nicer all
the time. Now i haven't browsed the code for calls to display tables but i've
only seen it in 2 places: if ok_tables isn't set, it gets called and it gets
called to set config->{display_tables}. AS far as i can tell, its sole purpose
for existing is to provide a configuration for the navigation system.
In conclusion, ok_tables, display_tables are perfect how they are. these
nicities make putting a simple database web app together more fun and faster.
Check out this site i built in a day. I didn't want anything fancy just a
simple tool for my club. www.mtsubiodiesel.org.
Well, thats Probably too much analysis for anyone's good and i'm sorry for
that.
> 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
>
I would say this:
display_tables -- list of tables you may want to put links to in your
navigation system. Usually these are the primary business objects. These are
passed to the templates in the config->{display_tables} elements. An example
of its use is in the factory templates navbar. These tables become the
navigation tabs in that template. This is primarily a nicity to aid in
constructing your navigation system.
ok_tables -- list of accessible tables on our website. If a table is not in
ok_tables and you go to "host/table/whatever" , you will get a not found error.
If this is not specified in your Controller class, then display_tables is used
as a fall back. If you specify this, you must add the tables in display tables
to the list as well.
>
> _______________________________________________
> maypole mailing list
> maypole at lists.netthink.co.uk
> http://lists.netthink.co.uk/listinfo/maypole
>
=====
pjs
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
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