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 <[email protected]> wrote: > On Fri, Mar 13, 2009 at 10:21 PM, Charles F. Munat <[email protected]> wrote: > > > > > > > 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? > > 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. > > > > > > > Chas. > > > Timothy Perrett wrote: > > > > Hmmm, I see your point. > > > > Will have a noodle at the weekend and see what would be the best route. > > > > Cheers, Tim > > > > On 13/03/2009 17:45, "Derek Chen-Becker" <[email protected]> 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 > > > <[email protected]> wrote: > > > > 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 <[email protected]> > > 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 > > > > <[email protected]>wrote <[email protected] > > >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 > > > <[email protected]> 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 > > > > > > On Fri, Mar 13, 2009 at 4:33 AM, Charles F. Munat < > > > <[email protected]> > > > > > [email protected]> wrote: > > > > > >> 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. > > -- > Lift, the simply functional web frameworkhttp://liftweb.net > Beginning Scalahttp://www.apress.com/book/view/1430219890 > Follow me:http://twitter.com/dpp > Git some:http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
