Overall this feature seems most similar to 'rewriting'. E.g. the url comes in as "http://localhost/foobar";, we don't recognize it, so we'll re-write it to template "404".
What about Either[RewriteResponse, LiftResponse]? E.g. same as what Marius suggested but use RewriteResponse instead of String. On Dec 30, 1:26 pm, Marius <marius.dan...@gmail.com> wrote: > I thought of that but that is problematic because: > > 1. Having a TemplateResponse holding a path without the rendering > logic, people could use that to send a response to the client, which > would be incorrect as having a LiftResponse holding /a/b/c doesn;t > mean anything to a client. And this would alter the semantics of a > LiftResponse. That's why I proposed an Either. > > 2. On the other hand if we have a TemplateResponse holding the logic > of processing a template (similar to the one proposed on this thread) > would mean that we're doing the processing outside of the normal > rendering pipeline which has the downsides discussed. > > Br's, > Marius > > On Dec 30, 8:18 pm, Naftoli Gugenheim <naftoli...@gmail.com> wrote: > > > Would it not be possible to have a LiftResponse that runs through the > > regular plumbing? This way instead of introducing Either you can just use a > > TemplateResponse etc. > > > ------------------------------------- > > > Marius<marius.dan...@gmail.com> wrote: > > > Please open a defect herehttp://github.com/dpp/liftweb/issues... > > whether or not this solution will make it in master will be subject > > for reviewboard. The solution I proposed has a breaking change by the > > introduction of Either[List[String], LiftResponse] instead of > > LiftResponse but I don't think that many people are using uriNotFound > > and it's really quite a small change which regardless needs to be > > announced. > > > Other opinions on this? > > > Br's, > > Marius > > > On Dec 30, 6:20 pm, Alex Black <a...@alexblack.ca> wrote: > > > > > While I totally agree that a plain 404 + markup is much more > > > > straightforward, > > > > "breaks internet" are too big words :) .. sending back a > > > > 302 or 301 tells the UA "you asked me for a resource that I know I > > > > don't have but I wont tell > > > > you explicitely, instead I want you to go to this location as an > > > > alternative resource". Somehow it's like scratching with the wrong > > > > hand and purely from HTTP protocol perspective this is not quite > > > > straightforward as 404 + template, but I don't necessarily see it as a > > > > so bad thing. > > > > Heh, I apologise, definitely "breaking the internet" is a bit > > > dramatic. I do have a different view than you though, I think its > > > incorrect to return a 301 or 302 in these scenarios, the correct > > > response is 404. Not only is it the correct response, but given most > > > sites get 50%-90% of their traffic from Google, and Google thinks its > > > also correct to return 404 (http://www.google.com/url?sa=D&q=http:// > > > googlewebmastercentral.blogspot.com/2008/08/farewell-to- > > > soft-404s.html, its in our best financial interest to play nice with > > > Google. > > > > > Specifically for 404 (when a template is not found we could do > > > > something like: > > > > > 1. In LiftRules instead of: > > > > > type URINotFoundPF = PartialFunction[(Req, Box[Failure]), > > > > LiftResponse] > > > > > use > > > > > type URINotFoundPF = PartialFunction[(Req, Box[Failure]), Either[List > > > > [String], LiftResponse]] > > > > > so that function can return a template path instead of response. > > > > > 2. In LiftSession#processRequest instead of applying the normal > > > > request pipeline only if the addressed template is found, we can use > > > > the path obtained from LiftRules.uriNotFound if Lift fails to find the > > > > normal tempalte. Hence apply the normal rendering pipeline to the > > > > template referenced by uriNotFound. > > > > > This approach allows your 404 case to be handled by the normal > > > > rendering pipeline without other hacks. > > > > > Unless someone thinks this is a bad solution, Alex you could open an > > > > issue and I'll work on it. > > > > Thanks for proposing that solution Marius. I can't really comment on > > > whether or not its the right way to do it from Lift's point of view, > > > but as a user of Lift it sounds like it would work well. > > > > - Alex > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > > To unsubscribe from this group, send email to > > liftweb+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
