On Fri, Mar 13, 2009 at 10:21 PM, Charles F. Munat <c...@munat.com> 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" <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
> > <timo...@getintheloop.eu> 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 <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 <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
> > >
> > > > On Fri, Mar 13, 2009 at 4:33 AM, Charles F. Munat <
> > <c...@munat.com>
> > > > c...@munat.com> 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 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@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
-~----------~----~----~----~------~----~------~--~---
