Slash and burn

[Charles F. Munat]

It would be advantageous for me, given the way I organize my sites, if
requests for /page were served the same way as requests for /page/, or
at least /page redirected to /page/.

Is there an easy way to do this?

Thanks,
Chas.

[Derek Chen-Becker]

Hmmm. I thought that this was what normally happened with most web servers (Jetty included). Are you using SiteMap, by any chance? What is the difference that you see between a response for /page and /page/ ?

Derek

[David Pollak]

Derek,

/page is parsed to List("page") and /page/ is parsed to List("page", "index").

Unfortunately, the rewrites are applied before the sitemap is in scope, so we can't consult the sitemap during rewrite, but I think there may be a way to write a DispatchPF to intercept List(xxx) and redirect to List(xxx, "index") if that is a legal page.

But, my editor will kill me if I don't get Chapter 5, draft 2 done, so I must stop yack shaving/helping people on this list and get back to work. :-)

Thanks,

David

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

[Timothy Perrett]

Within Lift, /page does what it says on the tin, whilst /page/ actually works out as:

/page/index

IMO, this is good. If you want them to be the same, I think you could either do a rewrite to the same content (if memory serves there is also a boolean option for defining if your using the slash or not?)

I'm pretty sure it matters not of you are or are not using site map at this process is part of lifts request handling.

Does that help?

Cheers, Tim

Sent from my iPhone

[Derek Chen-Becker]

I think I was confusing this with some other behavior of SiteMap, hence my question. I think it would be good to allow some really pre-processing of the URL. Would it useful to allow the user to control it, or do you think it would be better to just make it implicit? Something like

LiftRules.pathRewrite.append {
  case List("parse") => List("parse", "index")
  ...
}

I'm doing a lot of wand-waving there, but does that seem like a reasonable approach from the user side of things? Or maybe make a subclass of RewriteResponse that just tells Lift to modify the path but change nothing else?

case class ModifiedPath (path : List[String]) extends RewriteResponse(...)

Derek

[Timothy Perrett]

Im pretty sure you could just do this with the existing infrastructure
(RewritePF and DispatchPF)

For instance, if Chas doesnt mind having two seperate resources, then
he can easily use RewritePF to get the same content at two resource
locations. Alternatively, he could just use a 301 redirect response in
a dispatch call to get the appropriate resource - I've posted code to
one of his questions about that before If memory serves.

I think that should all be cool? Cant think of a good reason why this
wouldnt work anyway :-)

Cheers, Tim

On Mar 13, 4:57 pm, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> I think I was confusing this with some other behavior of SiteMap, hence my
> question. I think it would be good to allow some really pre-processing of
> the URL. Would it useful to allow the user to control it, or do you think it
> would be better to just make it implicit? Something like
>
> LiftRules.pathRewrite.append {
>   case List("parse") => List("parse", "index")
>   ...
>
> }
>
> I'm doing a lot of wand-waving there, but does that seem like a reasonable
> approach from the user side of things? Or maybe make a subclass of
> RewriteResponse that just tells Lift to modify the path but change nothing
> else?
>
> case class ModifiedPath (path : List[String]) extends RewriteResponse(...)
>
> Derek
>
> On Fri, Mar 13, 2009 at 10:51 AM, Timothy Perrett

> <timo...@getintheloop.eu>wrote:

>
> > Within Lift, /page does what it says on the tin, whilst /page/ actually
> > works out as:
>
> > /page/index
>
> > IMO, this is good. If you want them to be the same, I think you could
> > either do a rewrite to the same content (if memory serves there is also a
> > boolean option for defining if your using the slash or not?)
>
> > I'm pretty sure it matters not of you are or are not using site map at this
> > process is part of lifts request handling.
>
> > Does that help?
>
> > Cheers, Tim
>
> > Sent from my iPhone
>

> > On 13 Mar 2009, at 14:27, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
>
> > Hmmm. I thought that this was what normally happened with most web servers
> > (Jetty included). Are you using SiteMap, by any chance? What is the
> > difference that you see between a response for /page and /page/ ?
>
> > Derek
>

[Derek Chen-Becker]

Well, treating a directory without a trailing slash (/path) as the directory + index (/path/index) is pretty standard behavior in web servers (Apache returns a 301 from the former to the latter), so I think something that requires less user intervention would be good. Perhaps at most we would want a boolean var on LiftRules to control the behavior.

Derek

[Timothy Perrett]

Hmmm, I see your point.

Will have a noodle at the weekend and see what would be the best route.

Cheers, Tim

[Charles F. Munat]

Sorry, I've missed most of this discussion, but thank you for your
responses. Hopefully, I'll be able to figure out what they mean after I
get some coffee (I had a very late night working).

I organize all my sites the same way. Names of items are expressed as
directories. All pages are called index. So instead of this:

/folks
bob.html
bill.html
brent.html

I have this:

/folks
/bob
index.html
/bill
index.html
/brent
index.html

One big advantage is that this works even if I later switch to a static
HTML site, or a ruby site, or god-knows-what. And I can change
index.html to index.php or index.xml or whatever and the URLs don't
change. I learned this system ten years ago and it has served me very well.

It seems that Lift used to serve /folks/ when /folks was called, but
recently it stopped. It would be nice if it looked for a *file* with
that name first, but then tried directories if no file was found. Is
there a downside to that?

Sorry about the subject line. Couldn't resist.

Chas.

> > <timo...@getintheloop.eu>wrote <timo...@getintheloop.eu>wrote>:

[Timothy Perrett]

> It seems that Lift used to serve /folks/ when /folks was called, but
> recently it stopped. It would be nice if it looked for a *file* with
> that name first, but then tried directories if no file was found. Is
> there a downside to that?

Im afraid your mistaken about it previously having different behavior
- its always behaved in the same way it does now :-)

As per mine and Derek's convo above, there is rational for needing the
trailing slash, and perhaps it should be a configurable option in
LiftRules. Off the top of my head, i'm not sure how deeply rooted the
current behavior is. Anywho, i'll have a dig around this weekend and
see what the options are.

Cheers, Tim

[Charles F. Munat]

Sorry I didn't reply to this sooner. With /page/ I see the page I want.
With /page I get a "page not found" error.

Chas.

[David Pollak]

Yes, there's a huge downside.  Files are only one place that Lift looks when it tries to resolve a list of path elements into the view to render.  Please see my recommendation of using a DispatchPF in conjunction with SiteMap to determine if a request for /folks should be redirected to /folks/.  That is the optimal way to solve the problem.  We may choose to add this kind of thing into Lift.  We will not add an alternate mechanism to achieving this goal.

 

Sorry about the subject line. Couldn't resist.

Made me laugh.

[bradford]

Hi Guys,

I too would like to access /foo and /foo/. Any updates on this?

Second, I have /foo.html that surrounds default at content. I have a
situation where / should look exactly like /foo. I don't want to
redirect to foo. How else can I achieve this without copying the
contents of /foo.html to /index.html?

Thanks,
Bradford

On Mar 14, 4:02 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> > > On 13/03/2009 17:45, "Derek Chen-Becker" <dchenbec...@gmail.com> wrote:
>
> > >     Well, treating a directory without a trailing slash (/path) as the
> > >     directory + index (/path/index) is pretty standard behavior in web
> > >     servers (Apache returns a 301 from the former to the latter), so I
> > >     think something that requires less user intervention would be good.
> > >     Perhaps at most we would want a boolean var on LiftRules to control
> > >     the behavior.
>
> > >     Derek
>
> > >     On Fri, Mar 13, 2009 at 12:15 PM, Timothy Perrett

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

[David Pollak]

On Mon, Mar 23, 2009 at 5:03 PM, bradford <finge...@gmail.com> wrote:

Hi Guys,

I too would like to access /foo and /foo/.  Any updates on this?

/foo maps to /foo.html

/foo/ maps to /foo/index.html

This has not and will not change.

 

If you are using SiteMap, make sure there are SiteMap entried for both: List("foo") and List("foo", "index")

Second, I have /foo.html that surrounds default at content.  I have a
situation where / should look exactly like /foo.  I don't want to
redirect to foo.  How else can I achieve this without copying the
contents of /foo.html to /index.html?

in index.html:

<lift:embed what="/foo"/> 

--

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

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

[Derek Chen-Becker]

You could use the <lift:embed> tag to put the common content in a hidden template.

Derek