[Lift] Re: Slash and burn
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.euwrote 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,
[Lift] Re: Why does HelloWorld index.html contain a snippet rather than a complete XHTML page?
Apologies for the poor wording, but David got the right interpretation Marc On 14/03/2009, at 6:57 PM, David Pollak wrote: index.html is well formed XML... in fact all the html files that Lift reads must be well formed. You may choose to include XML header information in your document, however, that header information will be used by the code that reads the document (e.g., defining the encoding as something other than UTF-8), but the internal representation is normalized XML and the way that the XML is rendered will always be UTF-8 encoded with proper headers. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Upgrading from lift 0.8 to lift 1.0
Hi lift community! I'm ugprading a lift application that I was not the
author of and am trying to figure out what changes I need to make. here's
my current state of brokenness (all in boot.scala)-
S.addAround(User.requestLoans)
LiftRules.rewrite.prepend {
case Req(login :: Nil,_,_) =
Login.login //This is the only Req
pattern match I've fixed so far, I still don't know what happened to the
Login object
case Req(_, ParsePath(logout :: Nil, _, _), _, _) = Login.logout
case Req(r, _, _, _) if r.uri.endsWith(/home/index) =
ignore = Full(RedirectResponse(/))
case Req(r, ParsePath(attendees.txt :: Nil, _, _), _, _) if
User.superUser_? =
ignore = Full(User.attendees)
case Req(r, ParsePath(redirect_to :: edit :: which :: page :: _,
_, _), _, _) =
ignore = Full(RedirectResponse(/+which+/edit/+page))
case Req(r, ParsePath(go :: home :: _, _, _), _, _) =
ignore = Full(RedirectResponse(/))
}
The application appears to not be using the menu system (but I haven't dug
in too thoroughly). My question is, where did all this Login/User stuff
go? I'm using the MetaMegaProtoUser magic, so I'm a bit out of my element
here.
Anyway, if someone could help me out with what happened User.requestLoans
and the Login object, I would highly appreciate!
-Josh
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: Upgrading from lift 0.8 to lift 1.0
In out PocketChange app:
http://github.com/tjweir/pocketchangeapp/tree/master
The only thing we do in Boot is append the user Menus (User.siteMap) for
SiteMap:
LiftRules.setSiteMap(SiteMap(MenuInfo.menu :_*))
...
object MenuInfo {
import Loc._
val IfLoggedIn = If(() = User.currentUser.isDefined, You must be logged in)
def menu: List[Menu] = Menu(Loc(home, List(index), Home)) ::
Menu(Loc(manageAccts, List(manage), Manage Accounts, IfLoggedIn)) ::
Menu(Loc(addAcct, List(editAcct), Add Account, Hidden, IfLoggedIn)) ::
Menu(Loc(viewAcct, List(viewAcct) - true, View Account,
Hidden, IfLoggedIn)) ::
User.sitemap
}
IIRC, the User sitemap stuff is new and handles the rewrite stuff.
Derek
On Sat, Mar 14, 2009 at 8:09 AM, Josh Suereth joshua.suer...@gmail.comwrote:
Hi lift community! I'm ugprading a lift application that I was not the
author of and am trying to figure out what changes I need to make. here's
my current state of brokenness (all in boot.scala)-
S.addAround(User.requestLoans)
LiftRules.rewrite.prepend {
case Req(login :: Nil,_,_) =
Login.login //This is the only Req
pattern match I've fixed so far, I still don't know what happened to the
Login object
case Req(_, ParsePath(logout :: Nil, _, _), _, _) = Login.logout
case Req(r, _, _, _) if r.uri.endsWith(/home/index) =
ignore = Full(RedirectResponse(/))
case Req(r, ParsePath(attendees.txt :: Nil, _, _), _, _) if
User.superUser_? =
ignore = Full(User.attendees)
case Req(r, ParsePath(redirect_to :: edit :: which :: page :: _,
_, _), _, _) =
ignore = Full(RedirectResponse(/+which+/edit/+page))
case Req(r, ParsePath(go :: home :: _, _, _), _, _) =
ignore = Full(RedirectResponse(/))
}
The application appears to not be using the menu system (but I haven't dug
in too thoroughly). My question is, where did all this Login/User stuff
go? I'm using the MetaMegaProtoUser magic, so I'm a bit out of my element
here.
Anyway, if someone could help me out with what happened User.requestLoans
and the Login object, I would highly appreciate!
-Josh
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: xml parser, utf-8, special characters... kill me now
Which parser are you using? Quick tests with PCDataXmlParser seems to indicate all ccedil; get mapped to the unicode character. In fact it does that for all entities in object HtmlEntities (line 26 onwards in lift-util/src/main/scala/ net/liftweb/util/PCDataMarkupParser.scala) If I enter the ç into a form it gets stored as the unicode character \u00E7 ... and also returns as that unicode character. Regards, Marc On 15/03/2009, at 11:36 AM, Charles F. Munat wrote: I have a site that uses a lot of special characters (a remarkably biased description, since there is nothing special about accented characters to the people who use them daily). In particular, I need the c with cedilla and the n with the tilde. These characters are being input to a database (UTF-8) via an online form, then spit back out onto the page. It's a fucking disaster. Apparently, everything goes through the xml parser, which is great, except when I try to enter these as entity references, such as ccedil;, the parser changes to amp; and I get the literal ccedil; back out again. When I type ç using the keyboard (or copy and paste it from a page or a text editor), I get gibberish. Anyone know the trick to getting around this? I need everything from e acute to e grave to trademark and registered trademark symbols, and I need to enter them this way. Thanks for any help. If I can get this to work, I'll add an explanation to the wiki. Chas. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
