Nice 404s sans Redirect

[Alex Black]

I'd like to handle 404s on my site in such a way that:
- there is no redirect, e.g. if you type in a url like mysite.com/
foobarme, you'll stay at that url, so maybe you can correct it
- the status code returned is 404 (not 200 OK)

See stackoverflow:

http://stackoverflow.com/bob

So I tried something like this:

// Catch 404s
LiftRules.uriNotFound.prepend {
case (req, _) => RewriteResponse("404" :: Nil)
}

But of course RewriteResponse is not a LiftResponse. Whats the best
way to do this? Basically I've got a template called 404.html which
I'd like to display whenever there is a 404.

I Just thought of something, perhaps I could add a RewriteRule that
matches everything?

- Alex

[Timothy Perrett]

To be clear, RewriteResponse is a LiftResponse, and therefore, valid.

If you want to display the contents of your 404.html, checkout NodeResponse... just load up your template using the template helpers (this will give you NodeSeq) and then you can present that back to the user. Job done.

Cheers, Tim

[Alex Black]

> To be clear, RewriteResponse is a LiftResponse, and therefore, valid.

I had tried it, and got a compile error, keep in mind I'm still on
1.0:

http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/http/RewriteResponse.html

> If you want to display the contents of your 404.html, checkout NodeResponse... just load up your template using the template helpers (this will give you NodeSeq) and then you can present that back to the user. Job done.

I'll take a look, that sounds promising, thx. What are the template
helpers? This sounds similar to using S.render, but I wasn't able to
use that since I'm still on 1.0, it looks like it was added later. (I
am considering moving to 1.1-M6).

- Alex

[Ross Mellgren]

Switch to 1.1-M8, if you can.

-Ross

> --
>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
> .
>
>

[Alex Black]

Is M8 pretty stable? A little while back DavidP recommended M6 as being the most stable of the milestones.

--
http://blog.alexblack.ca
http://twitter.com/waterlooalex

[Ross Mellgren]

M8 is pretty stable, yes. M7 was not, and so M6 was recommended before that. I haven't heard of any reason to recommend M6 over M8, but maybe dpp has some reasons.

-Ross

[Alex Black]

> If you want to display the contents of your 404.html, checkout NodeResponse... just load up your template using the template helpers (this will give you NodeSeq) and then you can present that back to the user. Job done.

I am familiar with NodeResponse and its subclasses. I've used them in
our REST api. But, what I can't figure out, is how to use them in
conjuction with the templating engine as you seem to be alluding to
(with the template helpers).

Can you point me in the right direction? I am going to try switching
to M8 and then using S.render like this:

val node404 = <lift:surround with="default" at="content">
<h1>Not Found</h1>
</lift:surround>

LiftRules.uriNotFound.prepend {
case (req, _) => XhtmlResponse(S.render(node404, req), _,
headers, cookies, 404, false)

[Indrajit Raychaudhuri]

Quite so, go for M8. M6 was recommended when M8 hadn't come out.

Cheers, Indrajit

>> <mailto:lif...@googlegroups.com>.

>> > To unsubscribe from this group, send email to
>> liftweb+u...@googlegroups.com

>> <mailto:liftweb%2Bunsu...@googlegroups.com>

>> > .
>> > For more options, visit this group at
>> http://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 lif...@googlegroups.com

>> <mailto:lif...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> liftweb+u...@googlegroups.com

>> <mailto:liftweb%2Bunsu...@googlegroups.com>.

>> For more options, visit this group at

>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>>
>>
>>
>> --
>> http://blog.alexblack.ca <http://blog.alexblack.ca/>

>> http://twitter.com/waterlooalex
>>
>> --
>>
>> You received this message because you are subscribed to the Google
>> Groups "Lift" group.
>> To post to this group, send email to lif...@googlegroups.com

>> <mailto:lif...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> liftweb+u...@googlegroups.com

>> <mailto:liftweb+u...@googlegroups.com>.

[Alex Black]

Ok, I got this working, with 1.1-M8 using S.render.

// A node which embeds our 404 template (e.g. 404.html)
val notFoundNode =
<lift:embed what="404" />

// Catch 404s
LiftRules.uriNotFound.prepend {
case (req, _) => XhtmlTemplateResponse(notFoundNode, 404)
}

// If you're using a sitemap, make sure you have a catch-all item,
e.g
// Menu(Loc("Catchall", Pair(Nil, true), "", Hidden :: Nil)) ::

using this object:

object XhtmlTemplateResponse extends HeaderStuff {
def apply(nodeToRender: Node, statusCode: Int): LiftResponse = {
val renderedNode = S.render(nodeToRender,
S.request.get.request).first
new XhtmlResponse(renderedNode, Empty, headers, cookies,
statusCode, false)
}
}

I think the wiki page: http://wiki.liftweb.net/index.php/Setting_up_a_custom_404_page
should be updated. The current code hides the 404 status code and
changes the url.

I'd offer to write the new wiki page - is there a way for me to get an
account on that wiki - or is it just for contributors?

- Alex

[David Pollak]

On Tue, Dec 29, 2009 at 10:14 AM, Ross Mellgren <dri...@gmail.com> wrote:

M8 is pretty stable, yes. M7 was not, and so M6 was recommended before that. I haven't heard of any reason to recommend M6 over M8, but maybe dpp has some reasons.

Usually, HarryH and others find the lurking issues with a given milestone.  There have not been any core issues with M8 over the last few weeks... so I think it's the blessed version.
 

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

[David Pollak]

Keep in mind that Lift's behavior for 404s differs between development and production mode in Lift 1.1-xxx

To have your app/Lift handle a 404 rather than passing it to your web container, in Boot.scala:

    LiftRules.passNotFoundToChain = false

    LiftRules.uriNotFound.prepend {
      case _ =>  XhtmlResponse((<html> <body>Silly goose</body> </html>),
                               Empty, List("Content-Type" -> "text/html; charset=utf-8"), Nil, 404, S.ieMode)
    }

In development mode, Lift will tell you about SiteMap as this was a common confusion point among new developers.  In production mode, Lift will use that code.  To put Lift in production mode:

mvn -Drun.mode=production jetty:run

I would strongly recommend against a "catch-all" entry in SiteMap as it will expose every page on your site to access.

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Alex Black]

Thanks for pointing that out, the catch-all sounds dangerous.

I tried your suggestion, and it works well except I'm encountering one
issue, my sitemap renders as "No Navigation Defined." for urls that
are not found. I'm using 1.1-M8, I launched jetty in production mode
as you indicated, and added the passNotFoundToChain = false.

Did you expect that - or is the passNotFoundToChain meant to solve the
sitemap issue?

- Alex

On Dec 29, 6:10 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[Ross Mellgren]

This is the production run mode thing dpp talked about. Try your app with -Drun.mode=production

-Ross

> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

[Alex Black]

I emailed Ross directly and said I did run with -Drun.mode=production.

Here's what I'm seeing:
1. If I run with -Drun.mode=production, and I access a not found url,
say mysite.com/foobar, then, I *do* see the custom 404 page as
expected, but, where I normally see my sitemap I see "No Navigation
Defined".
2. If I run *without* that production flag, and I access a not found
url, I get a blank white screen that says "The requested page was not
defined in your SiteMap, so access was blocked. (This message is
displayed in development mode only)".

So #2 is expected, #1 is not.

Ross, when you emailed me you said you tried to reproduce this, but I
think one difference between your scenario and mine is that on my 404
page I have a sitemap rendered.

So instead of what dpp had:

LiftRules.uriNotFound.prepend {
case _ => XhtmlResponse((<html> <body>Silly goose</body> </
html>),
Empty, List("Content-Type" -> "text/
html;
charset=utf-8"), Nil, 404, S.ieMode)
}

I have:

// Catch 404s
LiftRules.uriNotFound.prepend {
case (req, _) => XhtmlTemplateResponse(notFoundNode, 404)
}

with

object XhtmlTemplateResponse extends HeaderStuff {
def apply(nodeToRender: Node, statusCode: Int): LiftResponse = {
val renderedNode = S.render(nodeToRender,
S.request.get.request).first
new XhtmlResponse(renderedNode, Empty, headers, cookies,
statusCode, false)
}
}

- Alex

[Alex Black]

One more detail:

notFoundNode is defined like this:

val notFoundNode = <lift:embed what="404" />

and 404.html like this:

<lift:surround with="default" at="content">

<head>
<title>Page Not Found</title>
</head>
<h1>Page Not Found</h1>
<p>We couldn't find the page you were looking for.</p>
</lift:surround>

And my default.html hidden template has a site map tag in it, and the
sitemap contains a number of entries.

[Alex Black]

I noticed another problem: the head merge is not working in this
scenario, the resulting page is not valid XHTML because it has two
head tags :) So, this makes me think I'm going about things the wrong
way.

I'm hoping you can suggest the right way, to create a custom 404 page,
correctly (without a redirect, with 404 status code), and processed by
the template engine so it uses our default template with sitemap etc.

- Alex

[Ross Mellgren]

I think the problem with the site map is that the request you have is for a page that doesn't exist so it can't build the current-page-relative sitemap.

Here's a version that works:

In Boot:

val notFoundNode = <lift:embed what="404" />

LiftRules.uriNotFound.prepend {
case _ => XhtmlTemplateResponse(notFoundNode, 404)
}

And the other part:

object XhtmlTemplateResponse extends HeaderStuff {
def apply(nodeToRender: NodeSeq, statusCode: Int): LiftResponse = {
val renderedNode = {
val forceToRoot: LiftRules.RewritePF = { case _ => RewriteResponse(Req.parsePath("/"), TreeMap.empty, true) }
for (req <- S.request; session <- S.session) yield
S.init(Req(req, forceToRoot::Nil), session) {
session.processSurroundAndInclude("/", nodeToRender)
}
} openOr {
error("No session")
}

new XhtmlResponse(Group(renderedNode), Empty, headers, cookies, statusCode, false)
}
}

The secret sauce is reiniting S with a new request that has been rewritten to seem as if it were a hit to /

I'm not sure if this is a good idea, but it seems to work for the site map thing.

However, I can't find a way to make the head merge work properly. It looks like the head merging lies in the code path inside LiftSession that is private to Lift. You could rearrange your template to make only one head I guess, or wait until someone more wise than I can direct you as far as that goes.

-Ross

[Marius]

Re init-ing S is a very risky thing to do. You loose all your context
information. uriNotFound is called by Lift from several key points.
From those key points, Lift uses the S context and updates the
function Map. With your example if your template is binding Scala
functions, those function will be written to a function map that will
not be seen by Lift as you're writing to a different S context.

I would advice no doing such things or if you do, then expect side
effects. In general avoid bypassing Lift's rendering pipeline. Lift
does a lot of things some of them internal and missing those you can
get into nasty hidden problems.

For head merge you could use HeadHelper.scala but note that internally
Lift doesn't use this ... it uses a more sophisticated head merge ...
see LiftMerge.scala. HeadHelper holds the old merge. IMO it should be
removed.

I'm not really sure why you guys don't like redirects, probably to
avoid traffic, but IMO this is not very relevant. But regardless, you
guys have your own reasons.

Br's,
Marius

> ...
>
> read more »

[Alex Black]

I'll try out that solution Russ, thanks. Although as the solution
gets a bit more complex, and taking into account Marius's advice, it
sounds like this might not be the right direction to go in.

Stepping back a moment, conceptually what I'd like to do is: create a
nice 404.html template (using lift features like head merge and
surround tags and sitemap), and then tell Lift to show this page to my
users when it can't find a handler for the url requested.

Conceptually a nice solution might be:

LiftRules.uriNotFound.prepend {
case _ => RewriteResponse("404.html")
}

Any other opinions on Russ's solution? Is it the right way to go? Or
is there another way? Or perhaps could we propose an enhancement to
Lift to handle this well?

To Marius's question about why I (and perhaps others) don't want to
use a redirect:

It breaks the internet. The way its meant to work is: a user-agent
(either browser, or crawler etc) asks a web server for a resource by
url, the web server should respond with code 404 if it can't find the
resource. Your proposal would have it respond with code 301 which
tells the user-agent that the resource was located but its moved.

LIft is generally very good I've found at making it easy to build good
internet applications the *right* way. Examples include: its easy to
build rest-ful APIs and return the correct response codes, its easy to
re-write urls to have friendly urls for users, its easy to build XHTML
compliant pages etc.

This is one of those areas where we (the lift community) should make
sure that Lift makes it easy to do things the right way. Unlike say
Microsoft of the past where they continually broke internet standards
and made it easy to do things the wrong way!

- Alex

> ...
>
> read more »

[Alex Black]

Google's opinion:

http://googlewebmastercentral.blogspot.com/2008/08/farewell-to-soft-404s.html

> ...
>
> read more »

[Marius]

On Dec 30, 5:05 pm, Alex Black <a...@alexblack.ca> wrote:
> I'll try out that solution Russ, thanks.  Although as the solution
> gets a bit more complex, and taking into account Marius's advice, it
> sounds like this might not be the right direction to go in.
>
> Stepping back a moment, conceptually what I'd like to do is: create a
> nice 404.html template (using lift features like head merge and
> surround tags and sitemap), and then tell Lift to show this page to my
> users when it can't find a handler for the url requested.
>
> Conceptually a nice solution might be:
>
> LiftRules.uriNotFound.prepend {
>             case _ => RewriteResponse("404.html")
>         }
>
> Any other opinions on Russ's solution? Is it the right way to go? Or
> is there another way? Or perhaps could we propose an enhancement to
> Lift to handle this well?
>
> To Marius's question about why I (and perhaps others) don't want to
> use a redirect:
>
> It breaks the internet.  The way its meant to work is: a user-agent
> (either browser, or crawler etc) asks a web server for a resource by
> url, the web server should respond with code 404 if it can't find the
> resource.  Your proposal would have it respond with code 301 which
> tells the user-agent that the resource was located but its moved.

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.

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.

Br's,
Marius

Br's,
Marius

> ...
>
> read more »

[Ross Mellgren]

Ouch, it does sound ugly. Is there some alternative way to change the
currently requested URI, for the purposes of sitemap generation and so
on? It seems like the alternative is spinning one's own SiteMap menu
snippet that knows to do this work?

Also, it seems odd there's no way to invoke the normal template flow
even barring the re-init of S. The closest you can get that I know of
is LiftSession.processSurroundAndInclude or S.render, but neither of
those do head merge which seems to be a very key part of the rendering
pipeline. Perhaps I'm misreading the code? It looks like
LiftMerge.merge is called from LiftSession.processRequest which is
called from LiftServlet.dispatchStatefulRequest, and so on, all
private to net.liftweb.http.

At any rate, I'm just trying to help Alex, I'm not invested in any
reason other than it's informative to try and solve. Is there any way
to get a templated 404 response?

-Ross

>>> --
>>
>>> You received this message because you are subscribed to the Google
>>
>> ...
>>
>> read more »
>

> --
>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com

[Marius]

Please see my previous reply and the proposed solution.

Br's,
Marius

> ...
>
> read more »

[Alex Black]

> 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

[Alex Black]

> At any rate, I'm just trying to help Alex, I'm not invested in any  
> reason other than it's informative to try and solve. Is there any way  
> to get a templated 404 response?

Sorry Ross, perhaps my response didn't convey my appreciation for your
help, or maybe it came off sounding negative, I didn't mean that.

What I meant was: thanks for offering that solution, it looks like a
step forward, I appreciate your help, but based on my gut feeling
looking at that code and based on Marius's opinon, I don't think we're
yet at an elegant robust solution, so lets keep coming up with more
ideas.

- Alex

> ...
>
> read more »

[Marius]

Please open a defect here http://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

[Ross Mellgren]

Oh no problem, I was intending this as a reply to the "you guys"
Marius used, to make it clear that I don't have a particular use case,
though I do agree about the soft 404s.

-Ross

[Alex Black]

I opened a ticket: http://github.com/dpp/liftweb/issues/#issue/265

I hope I wrote it in a reasonable/acceptable way, its my first ticket.

- Alex

On Dec 30, 11:26 am, Marius <marius.dan...@gmail.com> wrote:
> Please open a defect herehttp://github.com/dpp/liftweb/issues...

[Marius]

perfect, thanks.

[Naftoli Gugenheim]

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...@gmail.com> wrote:

Other opinions on this?

Br's,
Marius

--

[Marius]

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.
>
> -------------------------------------
>

[David Pollak]

On Wed, Dec 30, 2009 at 8:26 AM, Marius <marius...@gmail.com> wrote:

Please open a defect here http://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?

 Right now Req.defaultCreateNotFound has hard-coded markup.

I'd much rather have this method reference a LiftRule that returns () => Box[NodeSeq] which if populated (e.g., LiftRules.default404Template = () => TemplateFinder.findAnyTemplate(List("404"))

We can change Req.defaultCreateNotFound to use the template returned by this method or the one currently hardcoded.

We should also add a flag in LiftRules to disable the dev-mode hardcoded 404 response.
 

Br's,
Marius

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Alex Black]

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.

[David Pollak]

On Wed, Dec 30, 2009 at 10:30 AM, Alex Black <al...@alexblack.ca> wrote:

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".

It's not rewriting.  Rewriting is the change of the URI of the incoming request.  Rewriting happens very early in the Request/Response cycle and determines that value of the Req() instance that's used to determine the logic for rendering a given page.

A 404 indicates that there is no logic that could be found for the given page.

Trying to mix the two will muddy the concept of rewriting and when it happens.

The existing mechanism gives you all that you need to generate a 404 page.

As far as I can tell, the two problems you are facing are:

1. There's a non-trivial amount of your code that needs to run to render the 404 error page.  This would be corrected by the suggestion that I posted regarding a LiftRule that generates the default 404 template.
2. Putting navigation on the page.  I'm still noodling how to address this particular issue.

If there are issues other than 1 and 2, please enumerate them.
 

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

[Alex Black]

> It's not rewriting.

I didn't say it was. I just said it seemed most similar to re-writing.

> Trying to mix the two will muddy the concept of rewriting and when it
> happens.

Makes sense.

> As far as I can tell, the two problems you are facing are:
>

>    1. There's a non-trivial amount of your code that needs to run to render

>    the 404 error page.  This would be corrected by the suggestion that I posted
>    regarding a LiftRule that generates the default 404 template.

>    2. Putting navigation on the page.  I'm still noodling how to address

>    this particular issue.
>
> If there are issues other than 1 and 2, please enumerate them.
>

Those do sound like the issues. Just to reflect it back to you from
my perspective (in case one of us is missing something), the issue as
I see it is that I've designed a nice 404 template using lift features
(like surround, sitemap, headmerge), and I'd like to display it to the
user when no handler can be found

Whats preventing me from doing this is: the current notfound mechanism
takes a liftResponse, not a template to render, and as such forces me
to render the template itself, and although Russ proposed a way to do
that Marius indicated this could have side effects and feels like the
wrong approach.

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@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 lif...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[David Pollak]

In Boot.scala (the boot method):

    LiftRules.passNotFoundToChain = false

    LiftRules.uriNotFound.prepend {
      case _ => generate404()
    }

In the Boot class:

  def generate404(): LiftResponse = {
    import scala.xml.Node

    val resp: Box[Node] =  S.setVars("expandAll" -> "true")  {
      for {
        rendered <- S.runTemplate("404" :: Nil)
      } yield rendered(0)
    }

    XhtmlResponse(resp openOr <html><body>Got a 404</body></html>,

                  Empty, List("Content-Type" -> "text/html; charset=utf-8"), Nil, 404, S.ieMode)
  }

And a 404.html file (which can be localized):

<lift:surround with="default" at="content">

Couldn't find your page... sorry
</lift:surround>

The uriNotFound code is executed within the S scope, so you've got all the goodness of knowing who the current user is, etc.

The reason that the menu was not being rendered in your example is that menu rendering is based on the location property in the Req(uest).  If there is no location (as defined in the SiteMap), then no menu can be rendered.  There's an option for displaying the entire sitemap by setting the expandAll="true" attribute when invoking the Menu.builder snippet.  But you don't really want to show the entire menu on all pages, so the S.setVars("expandAll" -> "true") {...} method (which is a good candidate for renaming for all you renamers out there) allows us to set the expandAll attribute for the duration of the code block.

Then we use S.runTemplate() to locate and run the 404.html template.

Finally, we create the XhtmlResponse with the 404 error code.

So, you can put whatever you want in the 404.html template (including snippets) and all will work as expected.

Thanks,

David

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Alex Black]

Ok, I tried this, it gets closer.

I noticed one issue: the head merge didn't get done, so I have two
<head> tags in the result. I'm attempting to set the title in the
404.html template, maybe there is a way I can set the title without
using head merge?

- Alex

On Dec 30, 2:54 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> > <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@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 lif...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>

> > <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@googlegroups.com>

[Marius]

You could put a Script tag and inside set the title via JavaScript?

But I'm still working on the solution I proposed which treats 404 as a
normal page. Not sure if Dave will like it (probably not) but I'll
send him a diff.

Br's,
Marius

> ...
>
> read more »

[David Pollak]

On Wed, Dec 30, 2009 at 7:43 PM, Alex Black <al...@alexblack.ca> wrote:

Ok, I tried this, it gets closer.

I noticed one issue: the head merge didn't get done, so I have two
<head> tags in the result.  I'm attempting to set the title in the
404.html template, maybe there is a way I can set the title without
using head merge?

I'm opening up the merge method, so once the code is in master, you'll be able to do:

  def generate404(): LiftResponse = {
    import scala.xml.Node
   
    val resp: Box[Node] =  S.setVars("expandAll" -> "true")  {
      for {

    session <- S.session
    req <- S.request

        rendered <- S.runTemplate("404" :: Nil)

      } yield session.performHeadMerge(rendered, req)

    }
   
    XhtmlResponse(resp openOr <html><body>Got a 404</body></html>,
                  Empty, List("Content-Type" -> "text/html; charset=utf-8"),
          Nil, 404, S.ieMode)
  }

This will do the head merge and give you the ability to do anything Lift does.


 

To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Alex Black]

That sounds great.

Just curious though, is there any chance runTemplate should just do
the head merge?

On Dec 31, 3:12 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> > > > <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@googlegroups.com>
> > <liftweb%252Buns...@googlegroups.com<liftweb%25252Bun...@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 lif...@googlegroups.com.
> > > > > > To unsubscribe from this group, send email to
> > > > > > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>
> > <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@googlegroups.com>
>

> > > > <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@googlegroups.com>
> > <liftweb%252Buns...@googlegroups.com<liftweb%25252Bun...@googlegroups.com>

[Marius]

It probably should ... but personally I still believe in equal rights
of 404 pages with any other template.

David's solution is great and definitely works. But this thread made
me realize that a higher/easier level of addressing this is helpful.
From user perspective saying something like ".. .if a template cannot
be found, just use the template denominated by this path (i.e.
"foo" :: "bar" :: "404" :: Nil) instead.". Lift then would process
this template as the regular one with the difference that it will use
404 status code automatically.

Currently I have a prototype implementation and an offline discussion
with David about other more internal implications. We'll see where it
goes.

Br's,
Marius

> ...
>
> read more »

[Alex Black]

That sounds like a great approach to me Marius!

> ...
>
> read more »