[Lift] Re: How forms work (the life cycle of request)
On Sun, May 10, 2009 at 1:35 PM, erik.karls...@iki.fi <
erik.b.karls...@gmail.com> wrote:
>
> Hi,
>
> I'm asking some questions again :) This time it is about form
> handling. I tried to get the idea from source code but I think it
> would be easier if some one wiser could open it a bit.
>
> Here is my understanding, please correct me if it is incorrect:
>
> 1. I have snippet (TeamSnippet) with "add" function that creates new
> teams. Inside "add" there is following bind statement:
>
> bind(...
> "name" -> SHtml.text(name, name = _),
> ...,
> "submit" -> SHtml.submit("Add", processTeamAdd))
>
> 2. When the snippet is requested the functions name.= and
> processTeamAdd are stored into session with generated name.
>
> 3. Snippet returns a node sequence where the input elements are listed
> with the name values generated for them. These generated names are the
> same that are used to identify the functions in session
>
> Now comes the big question for me. When user has inputed the name of
> the team and hits the submit button: By whom are the functions (name.=
> and processTeamAdd) called.
>
Scala supports true closures which means that variables in scope (including
"this") are bound to the function.
Lift associates the function passed to SHtml.text(defaultValue,
passedFunction) with a GUID and returns places that GUID in the name
attribute of the generated HTML element. When the form is
submitted, Lift looks up the GUID in the function table and calls the
function with the passed parameter.
So, the "by whom" answer is the "runParams" method in LiftSession. This is
done early in the request cycle.
Does this help?
Thanks,
David
> I would like to understand this so that I could create tests for it.
>
> br,
> - Erik
>
> >
>
--
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
-~--~~~~--~~--~--~---
[Lift] Re: Write access to the id field of ProtoUser (for testing)
On Sun, May 10, 2009 at 3:17 AM, erik.karls...@iki.fi < erik.b.karls...@gmail.com> wrote: > > Hi, > > It may happen that this post appears twice to this forum - in that > case sorry for the double posting ;) New users are moderated to avoid spam... on weekends, it may take up to a day for postings to appear on list. > > > Anyhow, I have following case. For unit test case I would need to be > able to define what is the value the id field in ProtoUser returns. I > know that I could handle this by just creating a mock object of the > ProtoUser but is there a way to actually get a write access to the id > field in the real class to change it? You should be able to do: myUserInstance.id(55L) That should set it to 55. Please give that a try. Thanks, David > > > Thanks beforehand, > > - Erik > > > > -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Tail merge?
Been thinking about this more, just trying to explore where this idea leads: - Where tail merge would really shine is that a snippet could be embedded inside a div tag, for example, but still have a tail pushed to the end of the page body. - Script entries in the head and tail blocks could be quickly analysed and duplicate scripts removed. - Possibly some additional elements/attributes on scripts inside head and tail blocks could ultimately evolve into part of a richer dependency management framework. On May 10, 9:39 pm, "marius d." wrote: > On May 10, 10:08 pm, Viktor Klang wrote: > > > What I've been noodling about for some time is to have dependency management > > as a part of the framework. That could be easily obtained by having widgets > > etc register their dependencies in a SessionVar[List[Dependency]] and then > > simply add a DispatchPF to serve those dependencies as one package with the > > separate GET. > > So what would this solve? ... I mean there is the ResourceServer used > currently by widgets so that widget's dependencies to be served ... > perhaps I'm missing something? > > > > > > > The downsides I've come up with are: > > > * Adds a reasonable amount of complexity > > * The order of the dependencies is hard to get right > > * Premature optimization > > * Moves away from idea to have JS libraries served by third party hosts > > * Kind of defeats the purpose of caching JS > > > Just my 2 cents, > > Viktor > > > On Sun, May 10, 2009 at 8:35 PM, Timothy Perrett > > wrote: > > > > Yeah google analytics is a good use case. I think talking about > > > smashing static files is off topic, but there is some value in having > > > a tail merge for when you want to put stuff in just before the body > > > tag. My only thinking right now is that why do we need a specific > > > snippet to do this? Right now, and > > param> would work perfectly for this right? > > > > Cheers, Tim > > > > On May 10, 3:21 pm, "Bryan." wrote: > > > > A nice use for this "tail merge" would be for the Google Analytics > > > > tracking code, especially the ecommerce tracking code. > > > > > Here's something to keep an eye on as well: http://blog.digg.com/?p=621 > > > > -- still very new and in development. > > > > > --Bryan > > > > > On May 10, 9:57 am, David Pollak > > > > wrote: > > > > > > On Sun, May 10, 2009 at 6:55 AM, marius d. > > > wrote: > > > > > > > People can choose to "smash" multiple js/css files into a single > > > > > > one, > > > > > > in fact it is a common practice. However for scripts that can be > > > > > > deferred putting them at the bottom of the page can improve > > > rendering. > > > > > > Okay.. so we're not actually putting the scripts on the page, we're > > > just > > > > > putting them right about the tag? > > > > > > > Br's, > > > > > > Marius > > > > > > > On May 10, 4:42 pm, David Pollak > > > > > > wrote: > > > > > > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > > > > > > > > >wrote: > > > > > > > > > Sounds like this could be a neat addition. Looking forward to > > > > > > > > see > > > what > > > > > > you > > > > > > > > come up with :-) > > > > > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML > > > > > > > page > > > > > > (rather > > > > > > > than having stuff cached by the browser) makes for larger page > > > sizes. > > > > > > I'd > > > > > > > much rather see a tool that would analyze the scripts and css that > > > was > > > > > > > included across lots of pages and recommending to the developer to > > > make > > > > > > 10 > > > > > > > CSS files or 20 script files into 1. But that's just me. > > > > > > > > > Cheers, Tim > > > > > > > > > On 08/05/2009 20:19, "marius d." > > > wrote: > > > > > > > > > > A built in snippet might me a good addition. I > > > could > > > > > > > > > probably allocate some time to noodle on it. > > > > > > > > > > Br's, > > > > > > > > > Marius > > > > > > > > > > On May 8, 5:05 pm, KWright > > > wrote: > > > > > > > > >> It's becoming an established best practice that scripts > > > > > > > > >> should > > > be > > > > > > put > > > > > > > > >> at the END of a page, where possible, in order to speed up > > > download > > > > > > > > >> times > > > > > > > > > >> Good article here: > > >http://developer.yahoo.com/performance/rules.html > > > > > > > > > >> It would be nice if Lift could help encourage and support > > > > > > > > >> this > > > by > > > > > > > > >> allowing a (or ?) element that could be > > > merged in > > > > > > > > >> the same fashion as the head element, perhaps also removing > > > > > > > > >> duplicates, etc. > > > > > > > > > >> This element would then disappear and expose only its content > > > when > > > > > > the > > > > > > > > >> page is ultimately sent to the browser. > > > > > > > > -- > > > > > > > Lift, the simply functional web frameworkhttp://liftweb.net > > > > > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > > > > > Follow me:http://twitter.
[Lift] How forms work (the life cycle of request)
Hi,
I'm asking some questions again :) This time it is about form
handling. I tried to get the idea from source code but I think it
would be easier if some one wiser could open it a bit.
Here is my understanding, please correct me if it is incorrect:
1. I have snippet (TeamSnippet) with "add" function that creates new
teams. Inside "add" there is following bind statement:
bind(...
"name" -> SHtml.text(name, name = _),
...,
"submit" -> SHtml.submit("Add", processTeamAdd))
2. When the snippet is requested the functions name.= and
processTeamAdd are stored into session with generated name.
3. Snippet returns a node sequence where the input elements are listed
with the name values generated for them. These generated names are the
same that are used to identify the functions in session
Now comes the big question for me. When user has inputed the name of
the team and hits the submit button: By whom are the functions (name.=
and processTeamAdd) called.
I would like to understand this so that I could create tests for it.
br,
- Erik
--~--~-~--~~~---~--~~
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: Tail merge?
On May 10, 10:08 pm, Viktor Klang wrote: > What I've been noodling about for some time is to have dependency management > as a part of the framework. That could be easily obtained by having widgets > etc register their dependencies in a SessionVar[List[Dependency]] and then > simply add a DispatchPF to serve those dependencies as one package with the > separate GET. So what would this solve? ... I mean there is the ResourceServer used currently by widgets so that widget's dependencies to be served ... perhaps I'm missing something? > > The downsides I've come up with are: > > * Adds a reasonable amount of complexity > * The order of the dependencies is hard to get right > * Premature optimization > * Moves away from idea to have JS libraries served by third party hosts > * Kind of defeats the purpose of caching JS > > Just my 2 cents, > Viktor > > On Sun, May 10, 2009 at 8:35 PM, Timothy Perrett > wrote: > > > > > > > Yeah google analytics is a good use case. I think talking about > > smashing static files is off topic, but there is some value in having > > a tail merge for when you want to put stuff in just before the body > > tag. My only thinking right now is that why do we need a specific > > snippet to do this? Right now, and > param> would work perfectly for this right? > > > Cheers, Tim > > > On May 10, 3:21 pm, "Bryan." wrote: > > > A nice use for this "tail merge" would be for the Google Analytics > > > tracking code, especially the ecommerce tracking code. > > > > Here's something to keep an eye on as well: http://blog.digg.com/?p=621 > > > -- still very new and in development. > > > > --Bryan > > > > On May 10, 9:57 am, David Pollak > > > wrote: > > > > > On Sun, May 10, 2009 at 6:55 AM, marius d. > > wrote: > > > > > > People can choose to "smash" multiple js/css files into a single one, > > > > > in fact it is a common practice. However for scripts that can be > > > > > deferred putting them at the bottom of the page can improve > > rendering. > > > > > Okay.. so we're not actually putting the scripts on the page, we're > > just > > > > putting them right about the tag? > > > > > > Br's, > > > > > Marius > > > > > > On May 10, 4:42 pm, David Pollak > > > > > wrote: > > > > > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > > > > > > >wrote: > > > > > > > > Sounds like this could be a neat addition. Looking forward to see > > what > > > > > you > > > > > > > come up with :-) > > > > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page > > > > > (rather > > > > > > than having stuff cached by the browser) makes for larger page > > sizes. > > > > > I'd > > > > > > much rather see a tool that would analyze the scripts and css that > > was > > > > > > included across lots of pages and recommending to the developer to > > make > > > > > 10 > > > > > > CSS files or 20 script files into 1. But that's just me. > > > > > > > > Cheers, Tim > > > > > > > > On 08/05/2009 20:19, "marius d." > > wrote: > > > > > > > > > A built in snippet might me a good addition. I > > could > > > > > > > > probably allocate some time to noodle on it. > > > > > > > > > Br's, > > > > > > > > Marius > > > > > > > > > On May 8, 5:05 pm, KWright > > wrote: > > > > > > > >> It's becoming an established best practice that scripts should > > be > > > > > put > > > > > > > >> at the END of a page, where possible, in order to speed up > > download > > > > > > > >> times > > > > > > > > >> Good article here: > >http://developer.yahoo.com/performance/rules.html > > > > > > > > >> It would be nice if Lift could help encourage and support this > > by > > > > > > > >> allowing a (or ?) element that could be > > merged in > > > > > > > >> the same fashion as the head element, perhaps also removing > > > > > > > >> duplicates, etc. > > > > > > > > >> This element would then disappear and expose only its content > > when > > > > > the > > > > > > > >> page is ultimately sent to the browser. > > > > > > > -- > > > > > > 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 frameworkhttp://liftweb.net > > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > > Follow me:http://twitter.com/dpp > > > > Git some:http://github.com/dpp > > -- > Viktor Klang > Senior Systems Analyst --~--~-~--~~~---~--~~ 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: LoanWrapper
It will after I review some stuff about types and look through some more
source code. Thanks!
Chas.
Timothy Perrett wrote:
> Here's an example:
>
> S.addAround(List(new LoanWrapper {
> def apply[T](f: => T): T = {
> val (time,result) = TimeHelpers.calcTime(f)
> def logTime = Log.info("test took "+time+" Milliseconds")
> result match {
> case (_,Full(_)) => logTime
> case Full(_) => logTime
> case _ =>
> }
> result
>}}))
>
> Does that help?
>
> Cheers, Tim
>
> On May 10, 6:52 pm, "Charles F. Munat" wrote:
>> Hmmm. Very interesting. I get the gist of it, but I'm going to have to
>> play with it a bit before I understand how it really works.
>>
>> Thanks! I figured there was a good reason for the name, but didn't think
>> to look for a design pattern.
>>
>> Chas.
>>
>>
>>
>> Timothy Perrett wrote:
>>> I think you'll find it's called that because it's a part of a pattern.
>>> If you google "loan pattern" you'll get a scala wiki answer that
>>> should help you :-)
>>> Cheers, Tim
>>> Sent from my iPhone
>>> On 10 May 2009, at 07:59, "Charles F. Munat" wrote:
Why is it called "LoanWrapper"?
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
-~--~~~~--~~--~--~---
[Lift] Re: joao invites you to try out FriendFeed
Folks, Messages to join social networking sites are not acceptable on this list. The person who sent this message will find all of his future posts to the Lift list moderated. A very cranky David On Sun, May 10, 2009 at 9:22 AM, joao wrote: > > Message from joao: > > I've been using FriendFeed, a great way to share things with my > friends and family. I thought you might like to try it out, too. > Check out my feed here: ... > -- 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 -~--~~~~--~~--~--~---
[Lift] Re: error tickets?
On Sun, May 10, 2009 at 8:05 AM, g-man wrote: > > The idea is that the user never sees any internal errors -- if one > does happen, it gets ticketed to '/templates-hidden', a redirect > occurs, and stuff like this: > > XML Parsing Error: prefix not bound to a namespace > Location: http://localhost:8080/ > Line Number 29, Column 15: > Note that this is a browser raised error (the page was rendered correctly, but contains content that the browser doesn't like). There is no practical way to detect this kind of problem. However, in the latest 1.1-SNAPSHOT, I've cleaned up what happens when a snippet is not found in development and production modes. > > ---^ > > ...is never seen in public. > > I realize testing will catch most of these, but there are also > database errors to be handled, and other unforseen events as well. > > > On May 7, 9:26 am, Timothy Perrett wrote: > > lol - now i see that also! been out of the loop today > > > > Examples wise, it would probally be a good idea for us to do an > > example implementation of each of the LiftRules PF's as they do tend > > to provoke a lot of questions on list. > > > > Cheers, Tim > > > > > Yep... this is much like the other exception handling question that > came up > > > this morning. > > > > > If you guys need an example of a handler, please let me know and I'll > work > > > something up. > > > > -- 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 -~--~~~~--~~--~--~---
[Lift] Re: Tail merge?
What I've been noodling about for some time is to have dependency management as a part of the framework. That could be easily obtained by having widgets etc register their dependencies in a SessionVar[List[Dependency]] and then simply add a DispatchPF to serve those dependencies as one package with the separate GET. The downsides I've come up with are: * Adds a reasonable amount of complexity * The order of the dependencies is hard to get right * Premature optimization * Moves away from idea to have JS libraries served by third party hosts * Kind of defeats the purpose of caching JS Just my 2 cents, Viktor On Sun, May 10, 2009 at 8:35 PM, Timothy Perrett wrote: > > Yeah google analytics is a good use case. I think talking about > smashing static files is off topic, but there is some value in having > a tail merge for when you want to put stuff in just before the body > tag. My only thinking right now is that why do we need a specific > snippet to do this? Right now, and param> would work perfectly for this right? > > Cheers, Tim > > > > On May 10, 3:21 pm, "Bryan." wrote: > > A nice use for this "tail merge" would be for the Google Analytics > > tracking code, especially the ecommerce tracking code. > > > > Here's something to keep an eye on as well: http://blog.digg.com/?p=621 > > -- still very new and in development. > > > > --Bryan > > > > On May 10, 9:57 am, David Pollak > > wrote: > > > > > > > > > On Sun, May 10, 2009 at 6:55 AM, marius d. > wrote: > > > > > > People can choose to "smash" multiple js/css files into a single one, > > > > in fact it is a common practice. However for scripts that can be > > > > deferred putting them at the bottom of the page can improve > rendering. > > > > > Okay.. so we're not actually putting the scripts on the page, we're > just > > > putting them right about the tag? > > > > > > Br's, > > > > Marius > > > > > > On May 10, 4:42 pm, David Pollak > > > > wrote: > > > > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > > > > >wrote: > > > > > > > > Sounds like this could be a neat addition. Looking forward to see > what > > > > you > > > > > > come up with :-) > > > > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page > > > > (rather > > > > > than having stuff cached by the browser) makes for larger page > sizes. > > > > I'd > > > > > much rather see a tool that would analyze the scripts and css that > was > > > > > included across lots of pages and recommending to the developer to > make > > > > 10 > > > > > CSS files or 20 script files into 1. But that's just me. > > > > > > > > Cheers, Tim > > > > > > > > On 08/05/2009 20:19, "marius d." > wrote: > > > > > > > > > A built in snippet might me a good addition. I > could > > > > > > > probably allocate some time to noodle on it. > > > > > > > > > Br's, > > > > > > > Marius > > > > > > > > > On May 8, 5:05 pm, KWright > wrote: > > > > > > >> It's becoming an established best practice that scripts should > be > > > > put > > > > > > >> at the END of a page, where possible, in order to speed up > download > > > > > > >> times > > > > > > > > >> Good article here: > http://developer.yahoo.com/performance/rules.html > > > > > > > > >> It would be nice if Lift could help encourage and support this > by > > > > > > >> allowing a (or ?) element that could be > merged in > > > > > > >> the same fashion as the head element, perhaps also removing > > > > > > >> duplicates, etc. > > > > > > > > >> This element would then disappear and expose only its content > when > > > > the > > > > > > >> page is ultimately sent to the browser. > > > > > > > -- > > > > > 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 frameworkhttp://liftweb.net > > > Beginning Scalahttp://www.apress.com/book/view/1430219890 > > > Follow me:http://twitter.com/dpp > > > Git some:http://github.com/dpp > > > -- Viktor Klang Senior Systems Analyst --~--~-~--~~~---~--~~ 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: Tail merge?
On Sun, May 10, 2009 at 7:02 AM, marius d. wrote: > > > > On May 10, 4:57 pm, David Pollak > wrote: > > On Sun, May 10, 2009 at 6:55 AM, marius d. > wrote: > > > > > People can choose to "smash" multiple js/css files into a single one, > > > in fact it is a common practice. However for scripts that can be > > > deferred putting them at the bottom of the page can improve rendering. > > > > Okay.. so we're not actually putting the scripts on the page, we're just > > putting them right about the tag? > > Yes ... for instance: > > > > > > > would yield: > > > > > > > > > > > > > At least this is what I'm referring to. Okay.. that sounds good to me. > > > > > > > > > > > > > > > Br's, > > > Marius > > > > > On May 10, 4:42 pm, David Pollak > > > wrote: > > > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > > > >wrote: > > > > > > > Sounds like this could be a neat addition. Looking forward to see > what > > > you > > > > > come up with :-) > > > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page > > > (rather > > > > than having stuff cached by the browser) makes for larger page sizes. > > > I'd > > > > much rather see a tool that would analyze the scripts and css that > was > > > > included across lots of pages and recommending to the developer to > make > > > 10 > > > > CSS files or 20 script files into 1. But that's just me. > > > > > > > Cheers, Tim > > > > > > > On 08/05/2009 20:19, "marius d." wrote: > > > > > > > > A built in snippet might me a good addition. I could > > > > > > probably allocate some time to noodle on it. > > > > > > > > Br's, > > > > > > Marius > > > > > > > > On May 8, 5:05 pm, KWright > wrote: > > > > > >> It's becoming an established best practice that scripts should > be > > > put > > > > > >> at the END of a page, where possible, in order to speed up > download > > > > > >> times > > > > > > > >> Good article here: > http://developer.yahoo.com/performance/rules.html > > > > > > > >> It would be nice if Lift could help encourage and support this > by > > > > > >> allowing a (or ?) element that could be merged > in > > > > > >> the same fashion as the head element, perhaps also removing > > > > > >> duplicates, etc. > > > > > > > >> This element would then disappear and expose only its content > when > > > the > > > > > >> page is ultimately sent to the browser. > > > > > > -- > > > > 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 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 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: Tail merge?
Yeah google analytics is a good use case. I think talking about smashing static files is off topic, but there is some value in having a tail merge for when you want to put stuff in just before the body tag. My only thinking right now is that why do we need a specific snippet to do this? Right now, and would work perfectly for this right? Cheers, Tim On May 10, 3:21 pm, "Bryan." wrote: > A nice use for this "tail merge" would be for the Google Analytics > tracking code, especially the ecommerce tracking code. > > Here's something to keep an eye on as well: http://blog.digg.com/?p=621 > -- still very new and in development. > > --Bryan > > On May 10, 9:57 am, David Pollak > wrote: > > > > > On Sun, May 10, 2009 at 6:55 AM, marius d. wrote: > > > > People can choose to "smash" multiple js/css files into a single one, > > > in fact it is a common practice. However for scripts that can be > > > deferred putting them at the bottom of the page can improve rendering. > > > Okay.. so we're not actually putting the scripts on the page, we're just > > putting them right about the tag? > > > > Br's, > > > Marius > > > > On May 10, 4:42 pm, David Pollak > > > wrote: > > > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > > >wrote: > > > > > > Sounds like this could be a neat addition. Looking forward to see what > > > you > > > > > come up with :-) > > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page > > > (rather > > > > than having stuff cached by the browser) makes for larger page sizes. > > > I'd > > > > much rather see a tool that would analyze the scripts and css that was > > > > included across lots of pages and recommending to the developer to make > > > 10 > > > > CSS files or 20 script files into 1. But that's just me. > > > > > > Cheers, Tim > > > > > > On 08/05/2009 20:19, "marius d." wrote: > > > > > > > A built in snippet might me a good addition. I could > > > > > > probably allocate some time to noodle on it. > > > > > > > Br's, > > > > > > Marius > > > > > > > On May 8, 5:05 pm, KWright wrote: > > > > > >> It's becoming an established best practice that scripts should be > > > put > > > > > >> at the END of a page, where possible, in order to speed up download > > > > > >> times > > > > > > >> Good article here:http://developer.yahoo.com/performance/rules.html > > > > > > >> It would be nice if Lift could help encourage and support this by > > > > > >> allowing a (or ?) element that could be merged in > > > > > >> the same fashion as the head element, perhaps also removing > > > > > >> duplicates, etc. > > > > > > >> This element would then disappear and expose only its content when > > > the > > > > > >> page is ultimately sent to the browser. > > > > > -- > > > > 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 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 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: error tickets?
Are you needing clarification on this? This should get you started:
LiftRules.exceptionHandler.prepend {
case (_, _, exception) => {
Log.error(exception.getStackTrace.toString)
RedirectResponse("/")
}
}
Cheers, Tim
On May 10, 4:05 pm, g-man wrote:
> The idea is that the user never sees any internal errors -- if one
> does happen, it gets ticketed to '/templates-hidden', a redirect
> occurs, and stuff like this:
>
> XML Parsing Error: prefix not bound to a namespace
> Location:http://localhost:8080/
> Line Number 29, Column 15:
>
> ---^
>
> ...is never seen in public.
>
> I realize testing will catch most of these, but there are also
> database errors to be handled, and other unforseen events as well.
>
> On May 7, 9:26 am, Timothy Perrett wrote:
>
>
>
> > lol - now i see that also! been out of the loop today
>
> > Examples wise, it would probally be a good idea for us to do an
> > example implementation of each of the LiftRules PF's as they do tend
> > to provoke a lot of questions on list.
>
> > Cheers, Tim
>
> > > Yep... this is much like the other exception handling question that came
> > > up
> > > this morning.
>
> > > If you guys need an example of a handler, please let me know and I'll work
> > > something up.
--~--~-~--~~~---~--~~
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: LoanWrapper
Here's an example:
S.addAround(List(new LoanWrapper {
def apply[T](f: => T): T = {
val (time,result) = TimeHelpers.calcTime(f)
def logTime = Log.info("test took "+time+" Milliseconds")
result match {
case (_,Full(_)) => logTime
case Full(_) => logTime
case _ =>
}
result
}}))
Does that help?
Cheers, Tim
On May 10, 6:52 pm, "Charles F. Munat" wrote:
> Hmmm. Very interesting. I get the gist of it, but I'm going to have to
> play with it a bit before I understand how it really works.
>
> Thanks! I figured there was a good reason for the name, but didn't think
> to look for a design pattern.
>
> Chas.
>
>
>
> Timothy Perrett wrote:
> > I think you'll find it's called that because it's a part of a pattern.
> > If you google "loan pattern" you'll get a scala wiki answer that
> > should help you :-)
>
> > Cheers, Tim
>
> > Sent from my iPhone
>
> > On 10 May 2009, at 07:59, "Charles F. Munat" wrote:
>
> >> Why is it called "LoanWrapper"?
>
> >> 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
-~--~~~~--~~--~--~---
[Lift] Re: LoanWrapper
Hmmm. Very interesting. I get the gist of it, but I'm going to have to play with it a bit before I understand how it really works. Thanks! I figured there was a good reason for the name, but didn't think to look for a design pattern. Chas. Timothy Perrett wrote: > I think you'll find it's called that because it's a part of a pattern. > If you google "loan pattern" you'll get a scala wiki answer that > should help you :-) > > Cheers, Tim > > Sent from my iPhone > > On 10 May 2009, at 07:59, "Charles F. Munat" wrote: > >> Why is it called "LoanWrapper"? >> >> 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 -~--~~~~--~~--~--~---
[Lift] Re: Confusion about Lift-Core
So really there is no lift core, it's just a combination of other modules? Chas. Timothy Perrett wrote: > You would use lift core if you wanted to include all this jars in your > project. It in itself does not "do" anything and it's just a pom module. > > Does that help? > > Cheers, Tim > > Sent from my iPhone > > On 10 May 2009, at 07:49, "Charles F. Munat" wrote: > >> What exactly is Lift-Core. When I read Chapter 7 of the Lift book, it >> says that Lift-Core is >> >> "The engine of the framework responsible for the request/response >> lifecycle, the rendering pipeline, invoking the user's functions, etc. >> We don't directly cover the core in this book because essentially >> all of >> the functionality that we do cover sits on top of the core." >> >> But when I look in the source code under lift-core, there's nothing >> there except a pom.xml file that appears to pull a bunch of >> dependencies, namely, lift-util, lift-webkit, lift-mapper, lift- >> machine, >> lift-record, lift-textile, lift-facebook, lift-amqp, lift-xmpp, and >> lift-widgets. >> >> So does "lift-core" comprise these widgets? Or is the lift-core >> something else? (The diagram in the book shows the Mapper, for >> example, >> as being separate from the Core.) >> >> Thanks for any help. >> >> 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 -~--~~~~--~~--~--~---
[Lift] Re: error tickets?
The idea is that the user never sees any internal errors -- if one does happen, it gets ticketed to '/templates-hidden', a redirect occurs, and stuff like this: XML Parsing Error: prefix not bound to a namespace Location: http://localhost:8080/ Line Number 29, Column 15: ---^ ...is never seen in public. I realize testing will catch most of these, but there are also database errors to be handled, and other unforseen events as well. On May 7, 9:26 am, Timothy Perrett wrote: > lol - now i see that also! been out of the loop today > > Examples wise, it would probally be a good idea for us to do an > example implementation of each of the LiftRules PF's as they do tend > to provoke a lot of questions on list. > > Cheers, Tim > > > Yep... this is much like the other exception handling question that came up > > this morning. > > > If you guys need an example of a handler, please let me know and I'll work > > something up. --~--~-~--~~~---~--~~ 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: Tail merge?
A nice use for this "tail merge" would be for the Google Analytics tracking code, especially the ecommerce tracking code. Here's something to keep an eye on as well: http://blog.digg.com/?p=621 -- still very new and in development. --Bryan On May 10, 9:57 am, David Pollak wrote: > On Sun, May 10, 2009 at 6:55 AM, marius d. wrote: > > > People can choose to "smash" multiple js/css files into a single one, > > in fact it is a common practice. However for scripts that can be > > deferred putting them at the bottom of the page can improve rendering. > > Okay.. so we're not actually putting the scripts on the page, we're just > putting them right about the tag? > > > > > > > Br's, > > Marius > > > On May 10, 4:42 pm, David Pollak > > wrote: > > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > >wrote: > > > > > Sounds like this could be a neat addition. Looking forward to see what > > you > > > > come up with :-) > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page > > (rather > > > than having stuff cached by the browser) makes for larger page sizes. > > I'd > > > much rather see a tool that would analyze the scripts and css that was > > > included across lots of pages and recommending to the developer to make > > 10 > > > CSS files or 20 script files into 1. But that's just me. > > > > > Cheers, Tim > > > > > On 08/05/2009 20:19, "marius d." wrote: > > > > > > A built in snippet might me a good addition. I could > > > > > probably allocate some time to noodle on it. > > > > > > Br's, > > > > > Marius > > > > > > On May 8, 5:05 pm, KWright wrote: > > > > >> It's becoming an established best practice that scripts should be > > put > > > > >> at the END of a page, where possible, in order to speed up download > > > > >> times > > > > > >> Good article here:http://developer.yahoo.com/performance/rules.html > > > > > >> It would be nice if Lift could help encourage and support this by > > > > >> allowing a (or ?) element that could be merged in > > > > >> the same fashion as the head element, perhaps also removing > > > > >> duplicates, etc. > > > > > >> This element would then disappear and expose only its content when > > the > > > > >> page is ultimately sent to the browser. > > > > -- > > > 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 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 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] joao invites you to try out FriendFeed
Message from joao: I've been using FriendFeed, a great way to share things with my friends and family. I thought you might like to try it out, too. Check out my feed here: http://friendfeed.com/joaopereira -- To give FriendFeed a try, visit http://friendfeed.com/invite?code=6COvuEHBLL To see FriendFeed in action, check out http://friendfeed.com/. If you have any questions, please contact feedb...@friendfeed.com. Thanks, Your friends at FriendFeed If you no longer wish to receive any email from FriendFeed, visit https://friendfeed.com/account/optout?code=6COvuEHBLL --~--~-~--~~~---~--~~ 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: Confusion about Lift-Core
Lift Bloat: LOL!!! 2009/5/10 David Pollak > A long time ago, I insisted that Lift was everything that we had in all the > Lift packages. When DavidB split Lift into different packages, he called > the "whole thing that includes all Lift packages" Lift Core. It would > probably be better named "Lift Bloat" (this is a joke), but it is what it > is. > > On Sat, May 9, 2009 at 11:49 PM, Charles F. Munat wrote: > >> >> What exactly is Lift-Core. When I read Chapter 7 of the Lift book, it >> says that Lift-Core is >> >> "The engine of the framework responsible for the request/response >> lifecycle, the rendering pipeline, invoking the user's functions, etc. >> We don't directly cover the core in this book because essentially all of >> the functionality that we do cover sits on top of the core." >> >> But when I look in the source code under lift-core, there's nothing >> there except a pom.xml file that appears to pull a bunch of >> dependencies, namely, lift-util, lift-webkit, lift-mapper, lift-machine, >> lift-record, lift-textile, lift-facebook, lift-amqp, lift-xmpp, and >> lift-widgets. >> >> So does "lift-core" comprise these widgets? Or is the lift-core >> something else? (The diagram in the book shows the Mapper, for example, >> as being separate from the Core.) >> >> Thanks for any help. >> >> 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 > > > > > -- My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: www.scalamodules.org Lift, the simply functional web framework: liftweb.net --~--~-~--~~~---~--~~ 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: Tail merge?
fyi. if you smash css into a single file but continue using relative urls in the css you'll end up with a slower page in the case that you're using asset hosts to work around the browsers http connection limit. when smashing into one file make sure to also apply the asset host trick to any url() statements in the css by rewriting them to be absolute urls rather than merely paths. commonly made mistake in the ruby world at least, saddens me. On Sun, May 10, 2009 at 3:55 PM, marius d. wrote: > > People can choose to "smash" multiple js/css files into a single one, > in fact it is a common practice. However for scripts that can be > deferred putting them at the bottom of the page can improve rendering. > > Br's, > Marius > > On May 10, 4:42 pm, David Pollak > wrote: >> On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett >> wrote: >> >> >> >> > Sounds like this could be a neat addition. Looking forward to see what you >> > come up with :-) >> >> I'm not 100% keen on it. Loading a ton of stuff into the HTML page (rather >> than having stuff cached by the browser) makes for larger page sizes. I'd >> much rather see a tool that would analyze the scripts and css that was >> included across lots of pages and recommending to the developer to make 10 >> CSS files or 20 script files into 1. But that's just me. >> >> >> >> >> >> > Cheers, Tim >> >> > On 08/05/2009 20:19, "marius d." wrote: >> >> > > A built in snippet might me a good addition. I could >> > > probably allocate some time to noodle on it. >> >> > > Br's, >> > > Marius >> >> > > On May 8, 5:05 pm, KWright wrote: >> > >> It's becoming an established best practice that scripts should be put >> > >> at the END of a page, where possible, in order to speed up download >> > >> times >> >> > >> Good article here:http://developer.yahoo.com/performance/rules.html >> >> > >> It would be nice if Lift could help encourage and support this by >> > >> allowing a (or ?) element that could be merged in >> > >> the same fashion as the head element, perhaps also removing >> > >> duplicates, etc. >> >> > >> This element would then disappear and expose only its content when the >> > >> page is ultimately sent to the browser. >> >> -- >> 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 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: Tail merge?
On May 10, 4:57 pm, David Pollak wrote: > On Sun, May 10, 2009 at 6:55 AM, marius d. wrote: > > > People can choose to "smash" multiple js/css files into a single one, > > in fact it is a common practice. However for scripts that can be > > deferred putting them at the bottom of the page can improve rendering. > > Okay.. so we're not actually putting the scripts on the page, we're just > putting them right about the tag? Yes ... for instance: would yield: At least this is what I'm referring to. > > > > > > > Br's, > > Marius > > > On May 10, 4:42 pm, David Pollak > > wrote: > > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > >wrote: > > > > > Sounds like this could be a neat addition. Looking forward to see what > > you > > > > come up with :-) > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page > > (rather > > > than having stuff cached by the browser) makes for larger page sizes. > > I'd > > > much rather see a tool that would analyze the scripts and css that was > > > included across lots of pages and recommending to the developer to make > > 10 > > > CSS files or 20 script files into 1. But that's just me. > > > > > Cheers, Tim > > > > > On 08/05/2009 20:19, "marius d." wrote: > > > > > > A built in snippet might me a good addition. I could > > > > > probably allocate some time to noodle on it. > > > > > > Br's, > > > > > Marius > > > > > > On May 8, 5:05 pm, KWright wrote: > > > > >> It's becoming an established best practice that scripts should be > > put > > > > >> at the END of a page, where possible, in order to speed up download > > > > >> times > > > > > >> Good article here:http://developer.yahoo.com/performance/rules.html > > > > > >> It would be nice if Lift could help encourage and support this by > > > > >> allowing a (or ?) element that could be merged in > > > > >> the same fashion as the head element, perhaps also removing > > > > >> duplicates, etc. > > > > > >> This element would then disappear and expose only its content when > > the > > > > >> page is ultimately sent to the browser. > > > > -- > > > 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 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 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: Tail merge?
On Sun, May 10, 2009 at 6:55 AM, marius d. wrote: > > People can choose to "smash" multiple js/css files into a single one, > in fact it is a common practice. However for scripts that can be > deferred putting them at the bottom of the page can improve rendering. Okay.. so we're not actually putting the scripts on the page, we're just putting them right about the tag? > > > Br's, > Marius > > On May 10, 4:42 pm, David Pollak > wrote: > > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett >wrote: > > > > > > > > > Sounds like this could be a neat addition. Looking forward to see what > you > > > come up with :-) > > > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page > (rather > > than having stuff cached by the browser) makes for larger page sizes. > I'd > > much rather see a tool that would analyze the scripts and css that was > > included across lots of pages and recommending to the developer to make > 10 > > CSS files or 20 script files into 1. But that's just me. > > > > > > > > > > > > > Cheers, Tim > > > > > On 08/05/2009 20:19, "marius d." wrote: > > > > > > A built in snippet might me a good addition. I could > > > > probably allocate some time to noodle on it. > > > > > > Br's, > > > > Marius > > > > > > On May 8, 5:05 pm, KWright wrote: > > > >> It's becoming an established best practice that scripts should be > put > > > >> at the END of a page, where possible, in order to speed up download > > > >> times > > > > > >> Good article here:http://developer.yahoo.com/performance/rules.html > > > > > >> It would be nice if Lift could help encourage and support this by > > > >> allowing a (or ?) element that could be merged in > > > >> the same fashion as the head element, perhaps also removing > > > >> duplicates, etc. > > > > > >> This element would then disappear and expose only its content when > the > > > >> page is ultimately sent to the browser. > > > > -- > > 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 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: Tail merge?
People can choose to "smash" multiple js/css files into a single one, in fact it is a common practice. However for scripts that can be deferred putting them at the bottom of the page can improve rendering. Br's, Marius On May 10, 4:42 pm, David Pollak wrote: > On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett > wrote: > > > > > Sounds like this could be a neat addition. Looking forward to see what you > > come up with :-) > > I'm not 100% keen on it. Loading a ton of stuff into the HTML page (rather > than having stuff cached by the browser) makes for larger page sizes. I'd > much rather see a tool that would analyze the scripts and css that was > included across lots of pages and recommending to the developer to make 10 > CSS files or 20 script files into 1. But that's just me. > > > > > > > Cheers, Tim > > > On 08/05/2009 20:19, "marius d." wrote: > > > > A built in snippet might me a good addition. I could > > > probably allocate some time to noodle on it. > > > > Br's, > > > Marius > > > > On May 8, 5:05 pm, KWright wrote: > > >> It's becoming an established best practice that scripts should be put > > >> at the END of a page, where possible, in order to speed up download > > >> times > > > >> Good article here:http://developer.yahoo.com/performance/rules.html > > > >> It would be nice if Lift could help encourage and support this by > > >> allowing a (or ?) element that could be merged in > > >> the same fashion as the head element, perhaps also removing > > >> duplicates, etc. > > > >> This element would then disappear and expose only its content when the > > >> page is ultimately sent to the browser. > > -- > 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 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: Tail merge?
On Fri, May 8, 2009 at 5:26 PM, Timothy Perrett wrote: > > > Sounds like this could be a neat addition. Looking forward to see what you > come up with :-) > I'm not 100% keen on it. Loading a ton of stuff into the HTML page (rather than having stuff cached by the browser) makes for larger page sizes. I'd much rather see a tool that would analyze the scripts and css that was included across lots of pages and recommending to the developer to make 10 CSS files or 20 script files into 1. But that's just me. > > Cheers, Tim > > On 08/05/2009 20:19, "marius d." wrote: > > > > > A built in snippet might me a good addition. I could > > probably allocate some time to noodle on it. > > > > Br's, > > Marius > > > > On May 8, 5:05 pm, KWright wrote: > >> It's becoming an established best practice that scripts should be put > >> at the END of a page, where possible, in order to speed up download > >> times > >> > >> Good article here:http://developer.yahoo.com/performance/rules.html > >> > >> It would be nice if Lift could help encourage and support this by > >> allowing a (or ?) element that could be merged in > >> the same fashion as the head element, perhaps also removing > >> duplicates, etc. > >> > >> This element would then disappear and expose only its content when the > >> page is ultimately sent to the browser. > > > > > > > > > > > -- 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 -~--~~~~--~~--~--~---
[Lift] Re: How to log exceptions?
It's in LiftRules at line 694:
/**
* The sequence of partial functions (pattern matching) for handling
converting an exception to something to
* be sent to the browser depending on the current RunMode (development,
etc.)
*
* By default it returns an XhtmlResponse containing a predefined markup.
You can overwrite this by calling
* LiftRules.exceptionHandler.prepend(...). If you are calling append then
your code will not be calle since
* a default implementation is already appended.
*
*/
var exceptionHandler = RulesSeq[ExceptionHandlerPF].append {
case (Props.RunModes.Development, r, e) =>
XhtmlResponse((Exception occured while processing {r.uri}
{
showException(e)
}),ResponseInfo.docType(r),
List("Content-Type" -> "text/html"), Nil, 500, S.ieMode)
case (_, r, e) =>
Log.error("Exception being returned to browser when processing "+r, e)
XhtmlResponse((Something unexpected happened while serving
the page at {r.uri}
),ResponseInfo.docType(r),
List("Content-Type" -> "text/html"), Nil, 500, S.ieMode)
}
On Sat, May 9, 2009 at 6:07 PM, sailormoo...@gmail.com <
sailormoo...@gmail.com> wrote:
>
> Hi:
>
> Where can I find the code of the default ExceptionHandler??
> Thanks.
>
>
> >
>
--
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
-~--~~~~--~~--~--~---
[Lift] Re: Confusion about Lift-Core
A long time ago, I insisted that Lift was everything that we had in all the Lift packages. When DavidB split Lift into different packages, he called the "whole thing that includes all Lift packages" Lift Core. It would probably be better named "Lift Bloat" (this is a joke), but it is what it is. On Sat, May 9, 2009 at 11:49 PM, Charles F. Munat wrote: > > What exactly is Lift-Core. When I read Chapter 7 of the Lift book, it > says that Lift-Core is > > "The engine of the framework responsible for the request/response > lifecycle, the rendering pipeline, invoking the user's functions, etc. > We don't directly cover the core in this book because essentially all of > the functionality that we do cover sits on top of the core." > > But when I look in the source code under lift-core, there's nothing > there except a pom.xml file that appears to pull a bunch of > dependencies, namely, lift-util, lift-webkit, lift-mapper, lift-machine, > lift-record, lift-textile, lift-facebook, lift-amqp, lift-xmpp, and > lift-widgets. > > So does "lift-core" comprise these widgets? Or is the lift-core > something else? (The diagram in the book shows the Mapper, for example, > as being separate from the Core.) > > Thanks for any help. > > 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 -~--~~~~--~~--~--~---
[Lift] Re: Html compress
On Sun, May 10, 2009 at 5:38 AM, sailormoo...@gmail.com < sailormoo...@gmail.com> wrote: > > Hi : > > I would like to know if there is a way as a filter to compress html > files to make html file smaller? Do you mean "remove comments" as the HTML is being converted into a byte-stream or do you mean gzip the HTML before it's sent over the pipe? If it's the latter, I'd suggest that you'd be best served having your native web server (Nginx, Apache, etc.) do this work for you. > > Thanks. > > > > -- 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 -~--~~~~--~~--~--~---
[Lift] Html compress
Hi : I would like to know if there is a way as a filter to compress html files to make html file smaller? Thanks. --~--~-~--~~~---~--~~ 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] Write access to the id field of ProtoUser (for testing)
Hi, It may happen that this post appears twice to this forum - in that case sorry for the double posting ;) Anyhow, I have following case. For unit test case I would need to be able to define what is the value the id field in ProtoUser returns. I know that I could handle this by just creating a mock object of the ProtoUser but is there a way to actually get a write access to the id field in the real class to change it? Thanks beforehand, - Erik --~--~-~--~~~---~--~~ 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: How to log exceptions?
Hi: Where can I find the code of the default ExceptionHandler?? Thanks. --~--~-~--~~~---~--~~ 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] Write access to the id field of ProtoUser (for testing)
Hi, I would like to use ProtoUser in my unit test so that I could set it's id's value. One way to do this is that I would create a mock object of the ProtoUser and then define what the id returns. However, I would rather like to use just the real class as it is. Is there a possibility to give the write permission to the id field of the ProtoUser? thanks for any help! br, - Erik --~--~-~--~~~---~--~~ 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: Tail merge?
Me or marius? Personally, I'm full of ideas :) On May 9, 1:26 am, Timothy Perrett wrote: > Sounds like this could be a neat addition. Looking forward to see what you > come up with :-) > > Cheers, Tim > > On 08/05/2009 20:19, "marius d." wrote: > > > > > > > A built in snippet might me a good addition. I could > > probably allocate some time to noodle on it. > > > Br's, > > Marius > > > On May 8, 5:05 pm, KWright wrote: > >> It's becoming an established best practice that scripts should be put > >> at the END of a page, where possible, in order to speed up download > >> times > > >> Good article here:http://developer.yahoo.com/performance/rules.html > > >> It would be nice if Lift could help encourage and support this by > >> allowing a (or ?) element that could be merged in > >> the same fashion as the head element, perhaps also removing > >> duplicates, etc. > > >> This element would then disappear and expose only its content when the > >> page is ultimately sent to the browser. --~--~-~--~~~---~--~~ 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: LoanWrapper
For completeness: http://scala.sygneca.com/patterns/loan Cheers, Tim On May 10, 10:41 am, Timothy Perrett wrote: > I think you'll find it's called that because it's a part of a pattern. > If you google "loan pattern" you'll get a scala wiki answer that > should help you :-) > > Cheers, Tim > > Sent from my iPhone > > On 10 May 2009, at 07:59, "Charles F. Munat" wrote: > > > > > > > Why is it called "LoanWrapper"? > > > 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 -~--~~~~--~~--~--~---
[Lift] Re: LoanWrapper
I think you'll find it's called that because it's a part of a pattern. If you google "loan pattern" you'll get a scala wiki answer that should help you :-) Cheers, Tim Sent from my iPhone On 10 May 2009, at 07:59, "Charles F. Munat" wrote: > > Why is it called "LoanWrapper"? > > 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 -~--~~~~--~~--~--~---
[Lift] Re: Confusion about Lift-Core
You would use lift core if you wanted to include all this jars in your project. It in itself does not "do" anything and it's just a pom module. Does that help? Cheers, Tim Sent from my iPhone On 10 May 2009, at 07:49, "Charles F. Munat" wrote: > > What exactly is Lift-Core. When I read Chapter 7 of the Lift book, it > says that Lift-Core is > > "The engine of the framework responsible for the request/response > lifecycle, the rendering pipeline, invoking the user's functions, etc. > We don't directly cover the core in this book because essentially > all of > the functionality that we do cover sits on top of the core." > > But when I look in the source code under lift-core, there's nothing > there except a pom.xml file that appears to pull a bunch of > dependencies, namely, lift-util, lift-webkit, lift-mapper, lift- > machine, > lift-record, lift-textile, lift-facebook, lift-amqp, lift-xmpp, and > lift-widgets. > > So does "lift-core" comprise these widgets? Or is the lift-core > something else? (The diagram in the book shows the Mapper, for > example, > as being separate from the Core.) > > Thanks for any help. > > 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 -~--~~~~--~~--~--~---
