Page 1 of 1
The view component and redirects
Posted: Sun Aug 28, 2005 5:47 pm
by nielsene
I'm trying to think through a few possibilities for how I want my View portion of the MVC triad to work, paticularly the relationship between the URL and the displayed view. I already have the Front Controller that finds a handler for the request. The Handler's currently return a View subclass which the Controller will show().
If the "normal" handler processes the request, then generally speaking, the displayed view will make "sense" relative to the URL in the location bar. If one of the error handlers claims the request, then the handler might not make sense.
In the legacy portion of the application, I alwasy redirect on error various error pages, sticking any required details into the Session before the redirection.
The other method, I've thought of, is just not to care that the two might be out of sync in some error pages, etc.
I normally would prefer the legacy module, but that also means you end up having to have a fiar number of extra Handlers to claim the "correct" error pages to stop endless redirections, etc. I'm a little worried that the configuration would start to get messy, etc.
Are there other methods here? Care to share any experiences with the different methods? These are View Pattern agnostic (don't care if its a Template/Transform or 2-Stage, etc)
Posted: Sun Aug 28, 2005 8:43 pm
by Christopher
I combine View classes with render() methods with a Response class that has setContent(), setHeaders() and setRedirect() methods. So the VIew(s) pass their output to the Response. Any View or Controller can set a redirect and that overrides displaying content.
I am currently using a new Template/Conponent style Response/ResponseChild classes that allow me to attach views as the renderer for a child view as well as set headers and redirects. The tree then all renders up to the root Response object that displays the content with any specificed headers, or redirects.
Posted: Mon Aug 29, 2005 9:15 am
by nielsene
I know that the Response class is one of the canonical methods for this. I was hoping to avoid the need for one. So far I've been able to avoid the need for one; and while my Request/Context parameters might be confusing/overly complicated its acheiving a nice clean seperation of modal/input and so far have been chained only into classes that legimately need access to them. However, a Response definitely does not belong to a Request; adding it to the Context feels like a bad mingling of controller and modal.
Maybe I'll just stick with a simple static Response class. I only have a need for redirects at present.
From a UI perspective, what's your opinion on adding a redirect soley to synchronize the URL with the chosen View, when the two aren't already aligned? (Typically only in error conditions, but there are non-error use-cases)
Posted: Mon Aug 29, 2005 12:19 pm
by sweatje
nielsene wrote:
Maybe I'll just stick with a simple static Response class. I only have a need for redirects at present.
Be careful with this, the problem with static classes being a lack of flexibility. The moment you choose to use a static class instead of passing in an instance you loose polymorphism, the biggest single casualty being the ability to mock is during tests.
Posted: Mon Aug 29, 2005 12:22 pm
by nielsene
sweatje wrote:nielsene wrote:
Maybe I'll just stick with a simple static Response class. I only have a need for redirects at present.
Be careful with this, the problem with static classes being a lack of flexibility. The moment you choose to use a static class instead of passing in an instance you loose polymorphism, the biggest single casualty being the ability to mock is during tests.
Drat....
Yeah, given how much I have to fight at times to get a mock where I need it, I don't want to close that opportunity.
Posted: Mon Aug 29, 2005 2:07 pm
by Christopher
nielsene wrote:I know that the Response class is one of the canonical methods for this. I was hoping to avoid the need for one. So far I've been able to avoid the need for one; and while my Request/Context parameters might be confusing/overly complicated its acheiving a nice clean seperation of modal/input and so far have been chained only into classes that legimately need access to them. However, a Response definitely does not belong to a Request; adding it to the Context feels like a bad mingling of controller and modal.
You seem to be avoiding some standard ways of doing things in order to keep some of your other non-standard ways of doing things. I would recommend doing the hard work of adding the Request and Response to your Context. They are global in nature, but putting them in the context gives you some control over them from both the dependency and testing POVs.
nielsene wrote:Maybe I'll just stick with a simple static Response class. I only have a need for redirects at present.
I agree with Jason on this.
Posted: Mon Aug 29, 2005 2:11 pm
by nielsene
arborint wrote:nielsene wrote:I know that the Response class is one of the canonical methods for this. I was hoping to avoid the need for one. So far I've been able to avoid the need for one; and while my Request/Context parameters might be confusing/overly complicated its acheiving a nice clean seperation of modal/input and so far have been chained only into classes that legimately need access to them. However, a Response definitely does not belong to a Request; adding it to the Context feels like a bad mingling of controller and modal.
You seem to be avoiding some standard ways of doing things in order to keep some of your other non-standard ways of doing things. I would recommend doing the hard work of adding the Request and Response to your Context. They are global in nature, but putting them in the context gives you some control over them from both the dependency and testing POVs.
Its not hard work to add Request/Response to the context. Its rather trivial implementation, but its not clean design as it greatly blurs the role of the Context.
Posted: Mon Aug 29, 2005 2:42 pm
by Christopher
nielsene wrote:Its not hard work to add Request/Response to the context. Its rather trivial implementation, but its not clean design as it greatly blurs the role of the Context.
That because you're using your Context as a View Helper rather than a Context. Use the Context as an acutal application context and clean up your Model <- VIew dependencies with helpers.
Posted: Mon Aug 29, 2005 2:46 pm
by nielsene
arborint wrote:nielsene wrote:Its not hard work to add Request/Response to the context. Its rather trivial implementation, but its not clean design as it greatly blurs the role of the Context.
That because you're using your Context as a View Helper rather than a Context. Use the Context as an acutal application context and clean up your Model <- VIew dependencies with helpers.
Well I've been handwaving a little on the Context. I agree that the view helper probably shouldn't end up there. What is there:
Session
DataMapperFactory
Currently also a DB reference and a PhraseBook factory (But I'm hoping these will get refactored out soon and that the DataMapperFactory can subsume them)
Those feel like an "application context" to me.
Posted: Mon Aug 29, 2005 7:55 pm
by Christopher
nielsene wrote:Well I've been handwaving a little on the Context. I agree that the view helper probably shouldn't end up there. What is there:
Session
DataMapperFactory
Currently also a DB reference and a PhraseBook factory (But I'm hoping these will get refactored out soon and that the DataMapperFactory can subsume them)
Those feel like an "application context" to me.
If those fee like an application context to you, then adding the Request and Response should feel ok too. So add a View Helper in between your View and Model rather than your "second" context and then have the Controller give the output of the View to the Response (or set a redirect).
Posted: Mon Aug 29, 2005 8:10 pm
by nielsene
arborint wrote:nielsene wrote:Well I've been handwaving a little on the Context. I agree that the view helper probably shouldn't end up there. What is there:
Session
DataMapperFactory
Currently also a DB reference and a PhraseBook factory (But I'm hoping these will get refactored out soon and that the DataMapperFactory can subsume them)
Those feel like an "application context" to me.
If those fee like an application context to you, then adding the Request and Response should feel ok too. So add a View Helper in between your View and Model rather than your "second" context and then have the Controller give the output of the View to the Response (or set a redirect).
Well what is an "application context"?
I thought it was the imaginary "application scope" that doen't exist in PHP. Therefore it needs to provide access to the "persistent" data -- either "long-term" Database backed, or short-term Session backed. Its purely Model concerns, unlike either Request or Response.