Hi,
Am Freitag, 26. Februar 2010 20:34:58 schrieb Jakob Westhoff:
> James PIC wrote:
> > On Fri, Feb 26, 2010 at 4:38 PM, Thomas Nunninger <tho...@nunninger.info>
wrote:
> >> Hi,
> >>
> >> after updating some content in my application, I want to redirect with a
> >> 303 HTTP response code. If I use ezcMvcExternalRedirect it uses a very
> >> unspecific 302 code. In HTTP 1.1 you could use 301 and 307 instead of
> >> 302.
> >>
> >> The German wikipedia (http://de.wikipedia.org/wiki/HTTP-Statuscode) even
> >> states not to use the 302 redirect when redirecting to other sites
> >> because of an search engine error (URL hijacking).
> >>
> >> Finally I think, I should not patch ezcMvcExternalRedirect but extend it
> >> with semantic meanings like "content updated, show normal view",
> >> "content is available on other location" and so on.
> >>
> >> But I even need some patch like:
> >>
> >> --- response_writers/http.php (Revision 94)
> >> +++ response_writers/http.php (Arbeitskopie)
> >> @@ -73,7 +73,14 @@
> >> // write output
> >> foreach ( $this->headers as $header => $value )
> >> {
> >> - header( "$header: $value" );
> >> + if ( !is_array( $value ) )
> >> + {
> >> + header( "$header: $value" );
> >> + }
> >> + else
> >> + {
> >> + header( "$header: {$value[0]}", true, $value[1] );
> >> + }
> >> }
> >> // do cookies
> >> foreach ( $this->response->cookies as $cookie )
> >>
> >> If the value of the header is an array, the second entry is the status
> >> code. Otherwise, everything behaves like before.
> >>
> >> The code seems to be a little bit hackish (because of the semantic in a
> >> simple array struct). But I don't have another idea without breaking BC.
> >>
> >> What do you think?
> >
> > Wouldn't it be nice to add an $httpCode attribute to ezcMvcResponse
> > and use it in ezcMvcHttpResponseWriter?
>
> I think thats exactly what the ezcMvcResultStatusObject interface is for.
>
> The problem in your implementation is, that you assume that each used
> reponse writer (aka. protocol) does use the same errorcodes. Lets assume
> you have a response writer to send a mail. In this case the errorcode
> would need to be handled in a completely different way.
You'd need to handle the status in some abstract way. But you are right and
such an abstraction is not really getting better. :-) The
ezcResultStatusObjects are much nicer
> The ezcMvcResultStatusObject does allow just that. Simple implement a
> status object which signals the special case of redirection you require.
> For example you could implement a TemporaryRedirectStatusObject. This
> status object is simply attached to the ezcMvcResponse->status property.
>
> The implementation of the status object could look something like that:
>
> class TemporaryRedirectStatusObject
> implements ezcMvcResultStatusObject
> {
> public function process( ezcMvcResponseWriter $writer )
> {
> switch( true )
> {
> case $writer instanceof ezcMvcHttpResponseWriter:
> // Send out the 307 header here
> break;
> case $writer instanceof SomeOtherResponseWriter:
> // Handle other response of this status type here
> break;
> // ...
> }
> }
> }
That could work. But as we have a central place of sending the headers in HTTP
via the ezcHttpResponseWriter, I don't like the idea of sending headers at
this place. Because of that, I'd prefer something like my suggested patch of
the http response writer (still not convinced that it is nice to distinguish
between headers containing a string and an array...).
Thomas
> This way the status can be handled by different response writers in one
> place to be a lot more flexible, than confining the handling only to
> http status codes.
>
> HTH.
>
> Cheers,
> Jakob
>
> --
> Jakob Westhoff (GPG 0xCBF7FC6A)
> http://westhoffswelt.de
--
Thomas Nunninger
Steinhalde 108
79117 Freiburg
Tel.: +49 761 1201850
Mobil: +49 163 7115153
http://nunninger.info
USt-IdNr: DE259832548
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
