With regards to Intercepting Filter execution.
If one *filter* decides it needs to send a client to a different page,
a) Recursively restart the execution to the new page within the same request. (Server side redirect)
b) Redirect (via header()) the client to the other page. (Client side redirect)
With what Im working with, I can go either way.
What bugs me, is that with option a, there is a high possibility,
of *filters* running more than once per request.
Is that a bad thing. Well so far, my *filters* only echo strings
to tell me that its working, but Im not sure if its a good thing with real *filters*.
Currently, in the system I'm developing for project(s) at work, I'm doing it on the server side. My filters follow a filter interface that has PreExecute and PostExecute methods. They return a status such as a redirect node (internal redirect), skip to post filter (for caching, so inner filters and the main Execute method doesn't run), or a resume state which resumes to the next filter or the Execute method of the controller class if no pre condition filters run.
I do not echo anything out what so ever. Instead I setup a view and when all of the post condition filters finish, I will call the render method to echo stuff out.
This way, if I need to, I can use HTTP redirects in my filters without a fear of "echo".
As far as echoing content in my *filters*. Its just visual debugging for me
to know that its running. I'll take them out when Im satisfied with the system.
What I think I'll do, is just keep track of what filters are being executed in the filter manager, and if a server side redirect occur, not reexecute the ones that I
know that has executed already.
I'll sleep on it.
Well in that case, you might want to implement a small global function what works like assert in C and use that in place of "echo".
This would simply be a wrapper for "echo". However you can disable this by usig some constant to disable debugging. Like wise you might want to implement a redirect function. In debugging mode it would echo out the URL that you want to redirect to via the debugger, and make this a hyperlink or something.
Bringing this back up. I forgot about something else.
My filters' execution is dictated by the order they appear in the list.
So that makes them oblivious that they dont know what other *filters*,
are in the list, and what page is currently being executed.
The only thing that dictates what page gets loaded, is a predefined $_GET variable (lets call it "cmd" for now), used by the FC.
What I've been doing to perform a server side redirect, was manually resetting,
this predefined $_GET variable, and restart filter list processing for example ->
$_GET['cmd'] = 'show404error';
Manually setting the $_GET variable, just seems *dirty* to me.
I was thinking, that I should do away with using $_GET to determine execution path, and extract needed information from the query string?
That way, at least
a) The server side redirect would look similar to a client redirect
i.e. header('index.php?cmd=show404error') <=> ssRedirect('index.php?cmd=show404error')
b) I wouldnt be manually setting a $_GET variable to redirect