|
|
Posted by Peter Fox on 11/13/05 12:18
Following on from Greg Scharlemann's message. . .
>I thought I had a workable approach to specifing which pages required a
>redirect in a config file, but it appears the way I'm attempting to do
>it is not going to work.
Bad approach in general. Horrible to maintain and as I understand your
logic a page not in the list gets away scot-free and so fails unsafe.
The better approach is to have a 'should I be here' function at the top
of any page where you want any control over 'should I be here'.
Obviously this goes into a single call of a function with all the other
standard top of page stuff.
You may notice the test is 'should I be here' not 'should we jump
elsewhere' that is focussing on the reasons that drive the logic rather
than the results. There are all sorts of reasons for jumping pages
elsewhere:-
* Not logged in
* Insufficient permission
* You have arrived at a record detail page without going through a
'select record' screen.
* You have arrived at a screen out of sequence where the sequence is
important
* News flash
* You have finished an excursion (eg a generic pick a date screen called
from anywhere) and want to return to where you left off.
Also, and 'hey you must login first - here we go' is the classic
example, you might be wanting to handle the situation in-line as far as
your page logic is concerned. ie.
o Test-Jump elsewhere-Continue
o Test-Jump elsewhere (then come back here)-Continue.
o Test-Set flags-Continue (constrained by flags)
So for example in a menu we might test to see if the user has
administrator's rights and if so switch on additional menu items.
Although this doesn't involve a jump it is handy to be able to class it
together with those sort of tests at the top of the page and then all
that sort of stuff has been got out of the way and anyone coming to look
at a the code can quickly grasp what it is about.
I implement a HaveWeComeFrom function which takes a list of possible
pages we might have just left as an argument (only where it is important
of course) which if it fails goes back to a configured main menu page
and 'can't do that there 'ere' message.
I hope this ramble through checking logic illustrates why it's best to
put the test parameters in the pages themselves.
--
PETER FOX Not the same since the bottom fell out of the bucket business
peterfox@eminent.demon.co.uk.not.this.bit.no.html
2 Tees Close, Witham, Essex.
Gravity beer in Essex <http://www.eminent.demon.co.uk>
Navigation:
[Reply to this message]
|