On Mon, Mar 23, 2009 at 5:03 PM, bradford <[email protected]> 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"/>
>
>
> 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
>
> >
>
--
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 [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
-~----------~----~----~----~------~----~------~--~---
