Quote Originally Posted by Dr Livingston
Someone suggest that you use Intercepting Filters, so the submitted data is validated before it reaches any sort of controller - makes sense, so in saying that maybe you could redirect directly from the Intercepting Filter in question based on the validation?

So you get to one of two controllers in that event. Another benifit of course would be that the process of form validation is separated from the controller altogether. If for some reason, the means of how you validate your forms changes later, you do not need to refacter any controllers either - you simply swap over to a different Filter.
Ah yes, the Intercepting Filters. This is probably the approach I see it all taking - but there's one big problem IMHO. And it's the fact that atleast I want to be as far as possible from any config-files at all(Some will be needed, as always.. and i think the parse_ini()-path is one of the best atm. Or simple XML configs), is that how do we set it all up. Do we have some type of CoR? Or a normal stack-like approach? For example:

    -- HTTPRequest
    -- Intercepting Filter
    -- Controller
The stack is exectued top-to-bottom(FIFO) and if one fails the next one is not executed, etc. Untill we get some type of response. This "RequestResponse" of some typ is passed to the:

Response Stack:
    -- CommandStack
        -- Login
        -- LoginFailed
        -- LoginSuccess
    -- ModelStack
        -- UserDataModel
    -- ViewStack
        -- Login
        -- LoginFailed
        -- LoginSuccess
This "stack" after getting a valid response returns a "HTTPResponse" object that is sent to the client. (Maybee stack isn't the best name here but it's late and I need to go to sleep ;p).

What do you guys think about this approach?

Quote Originally Posted by BerislavLopac
Personally, I'd prefer the latter -- a kind of Lego blocks you build your app with.
Same here, I'd prefer a more loosleycoupled framework.