[Lift] Re: The quality of the Lift list [was: Don't shoot the non-XML messenger ...]
Reading the thread in question I was quite surprised about the attitude shown on the list by the person in question. I wholeheartedly agree that the right decision has been made. Br's, Marius On Oct 14, 6:49 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, It is not lightly that I ban someone from the group... this is only the second time I've banned a substantive poster. I'm going to discuss some of the process and then touch on some of the substance of the questions that the poster was getting at. The Lift community, reflected on this list, is an inquisitive, friendly place where people who have a passion for building great web apps converge and contribute to making Lift a really great open source framework. Newbies are the lifeblood of the group because they come with fresh perspectives and new ways of looking at things. Questions from newbies help us refine and enhance Lift and the associated documentation. Folks who are building production apps on Lift receive the fastest turn-around because these folks are betting their careers and their enterprises (even enterprises of one) on Lift and they deserve the best support in the industry for taking this risk. A big part of why this community is successful (in terms of size, quality of discussion, and quality of results) is because we keep the quality of discussion high. How do we do this? The folks who have been on the list generally keep the level of discussion to the Lift ideals. We reward newbies with quick answers and encourage friendly discourse. We are generally slower to respond to those that are less reflective of the list ideals. I warn folks who are pushing boundaries (usually privately, but every once in a while publicly) and where the line is. In this case, nothing worked. The poster was neither asking questions, giving usable feedback, or being polite in his engagement with the folks on the list. I received a substantial number of private communications about this poster (which is pretty rare), and I took action. In terms of the substance, let me address to threat issue first. I threatened to ban the poster from the list. Perhaps DHH or Martin would not make such a threat. I am very sure that the quality of discussion on the Lift list is higher than that on the Rails list (one of the reasons I started Lift was to be part of a nicer community.) One cost of having a nicer place is excluding those who do not fit. The second threat I made was to relay a tongue-in-cheek private communication I received about the poster to the list (after receiving the okay from the guy that made the communication to me.) This threat was obvious, using video game rating language http://www.esrb.org/ratings/ratings_guide.jsp, Comic mischief and Cartoon violence. It was something that even a 6 year old can distinguish from reality. Put another way, the poster was talking about Kafkaesque experiences with using Lift and I responded with Jonesianhttp://www.youtube.com/watch?v=CrupqdGvsocfeature=PlayListp=62FED00...language. In terms of the broader issue of Lift's HTML templating system being XHTML only, yes, that's true. Lift treats HTML templates as XML. Lift's templating system is not a String templating system but an XML templating system. This satisfies the needs to render content to HTML browsers. If there are needs for generating other kinds of content, Lift is not as good, but in many cases there are better libraries for doing so. Lift makes it very simple to integrate other rendering/templating engines into Lift, usually with a single line of code the dispatches the HTTP request to an alternate provider of a LiftResponse. If the poster had simply said, I want to template non-HTML output, can you show me how? he would have gotten a nice example (and I might have even rolled it into demo.liftweb.net or maybe Tim might have blogged about it. Keeping things in XML has a number of advantages and a few disadvantages. First, the disadvantages: (1) you can't template non-XHTML responses and (2) everything must be well formed XML. The advantages are (1) security (2) performance (it's easier to cache XML and the cost of mutating XML trees is O(log N)), (3) there is better separation of logic from the view (perhaps Terrance Parr's String Template library achieves this level of separation), and (4) the ability to mutate the resulting page (rewrite tags, move stuff to head/tail, consolidate scripts) is more performant and less error-prone than doing the same with a String-based representation. I will address Bill's security question. For String-based rendering systems that emit HTML, the developer is the one who must make a decision at each insertion point as to whether the incoming String needs to be escaped. Because Strings are untyped, you don't know what they mean, if they're safe to be passed directly or if they need to be escaped. On the other hand,
[Lift] Re: Turning of cookies breaks Comet ... again
Found the problem ... I opened http://github.com/dpp/liftweb/issues#issue/100 ticket and workin' on it. Br's, Marius On Oct 14, 10:07 pm, Marius marius.dan...@gmail.com wrote: Hi, A while ago I added the support for URL rewriting when cookies are turned of in the container so that things would correctly work when jssessionid is part of the url. After that this was broken a few times but I fixed it. Not, after quite some time, I'm back in the place where it seems broken. I have a simple Clock Comet and when turn off cookies in jetty the page reloads over and over again (I use FireFox on Ubuntu). I'll try to fix this but in the mean time I want to ask you if you've seen the same behaviour. If you already have the answer would save me a bit of time. Br's, Marius --~--~-~--~~~---~--~~ 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: Dynamic SiteMap
First of all I'm not reinventing anything. I don't think that If LocParam semantic is giving you the hidden functionality as well. User type 2 should not even see the menus for user type 1, not only to not be able to access those locations. The way I see it this functionality should be totally irrespective of Mappers or any persistence store. It is just a matter of how you implement the function passed to If and other LocParams. You can also implement your own Loc and override the calcHidden function and you can decide what to render there. I still think that a conditional hidden LocParam would be helpful. Br's, Marius. On Oct 12, 2:27 am, Dave davidtgoldb...@gmail.com wrote: Marius- Thanks for your help on this. I guess I'm not sure how this differs from the current conception of the If LocParam. As I understand it, it is checked when determining what to display on the Menu as well as when a User attempts to access the page (or its subdirectory if passing a pair). If this is true, then I think there is no need to reinvent the wheel per se. Assuming I'm right and we can use If's to accomplish this functionality, I can follow up this query with an implementation based question. Specifically, since both of my user types extend MegaProtoUser, I end up with loggedIn_? function that tells if some user is logged in, but is confused about which. So if a user of type 1 logs in and I call UserType2.loggedIn_?, it will also return true. Is there a way to check for this in If statements? Or is it necessary to override loggedIn_? (which I've been trying, but has been pretty slow going so far). Thanks Dave On Oct 11, 12:36 pm, marius d. marius.dan...@gmail.com wrote: Yes, a Loc accepts many LocParams ... as I said above If/Unless/Test would be used in conjunction with CondHidden to also provide accessibility constraints. Here is the definition case object CondHidden(test: () = Boolean) extends LocParam but we also have case class If(test: () = Boolean, failMsg: FailMsg) extends LocParam So the test function is the same which means that you essentially implement one function and provide it to both LocParam's. We could probably combine the two LocParams in a: IfHidden(test: () = Boolean, failMsg: FailMsg) // if you have a better name please let me know :) The test function would be called in two cases: 1. When rendering the Menu to see is the Menu should be rendered or not 2. When try to access the location to as a security check I could probably add it this week and point you to my branch to check it out. If I runt into something weird that I cannot foresee I'll let you know. Would this work for you? Other people are welcome to comment as well ... Br's, Marius On Oct 11, 7:06 pm, Dave davidtgoldb...@gmail.com wrote: Hi Marius, Thanks for the response. The LocParam is a good idea, but here is the attendant problem. No only do I have to hide options A,B,C from user type 2, I have to make sure user type 2 does not access those pages/ areas. Can I include that in the locParam as well? Right now, I'm using an If() val to determine what type of user it is, and then funnel accordingly. I assume i can just include both the if (to determine access/where to send) and then the conditional hider LocParam if necessary. But can I bundle both into a more DRY solution? Thanks, Dave On Oct 11, 2:54 am, marius d. marius.dan...@gmail.com wrote: So doesn't what I described about help you? ... a conditional Hidden LocParam? ...thus the SiteMap contains all A, B, C, D, E, F menus but for user type 1 D, E,, F are hidden, and for user type 2 A, B, C are hidden. The decision would done in the function that you provide to CondHidden. If this helps the new LocParam could be added with not much problems. If this doesn't work for you, please elaborate. Br's, Marius On Oct 11, 2:09 am, Dave davidtgoldb...@gmail.com wrote: Hi all- I am interested in a similar question. I have two types of users and once logged in, I'd like to provide them with distinct menu options. For instance User type one would have a menu with A / B / C and User Type Two would have D / E / F. I have tried a variety of approaches including storing a session variable when the user first logs in, but because the sitemap is already built, its tough to modify dynamically. Further, unfortunately, User1.sitemap and User2.sitemap don't play well together, and only one should be shown at one time depending on the user type. Not to take away from Markus' question, but if someone could address this more concrete scenario, it would be much appreciated. Thanks, Dave On Oct 10, 5:09 pm, marius d. marius.dan...@gmail.com wrote: Well SiteMap is per LiftRules which means it's per application runtime. One approach would
[Lift] Re: Lift UVP's
Is the audience mostly Java based or from different other fields including FP? I would insist in how Lift leverages functional programming idioms offered by Scala. Personally I believe this gives Lift a pretty unique position. Br's, Marius On Oct 12, 12:37 am, Timothy Perrett timo...@getintheloop.eu wrote: Guys, In about a month im speaking at a fairly sizeable event in Belgium and wanted to ask a few questions about what users see at Lift's unique value proposition. I did a talk about lift at a bar-camp recently and whilst they were fairly well received, I think i still assumed too much information. To that end, I thought by focusing on some of lifts super cool features in a broad way I would then aim to give people a better overview / warm fuzzy feeling about Lift in the allotted hour. So what are Lift's UVP's? My list looks a little like: - OOTB Comet (probably what draws most people to lift) - View first / code free templating - Utilisation of existing JEE infrastructure (WARs, JPA etc) - Non-perscriptive but highly configurable framework Then we also have some stuff that we inherit from scala: - traits - concise but type safe code - etc etc etc What do people think? I have an hour to make people feel good about Lift and hopefully give them enough of a taste to go away and try it later - am i missing anything blindingly obvious? This isnt a hard and fast outline of my preso, just trying to kick around some thoughts and ideas :-) Cheers, Tim --~--~-~--~~~---~--~~ 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: Dynamic SiteMap
So doesn't what I described about help you? ... a conditional Hidden LocParam? ...thus the SiteMap contains all A, B, C, D, E, F menus but for user type 1 D, E,, F are hidden, and for user type 2 A, B, C are hidden. The decision would done in the function that you provide to CondHidden. If this helps the new LocParam could be added with not much problems. If this doesn't work for you, please elaborate. Br's, Marius On Oct 11, 2:09 am, Dave davidtgoldb...@gmail.com wrote: Hi all- I am interested in a similar question. I have two types of users and once logged in, I'd like to provide them with distinct menu options. For instance User type one would have a menu with A / B / C and User Type Two would have D / E / F. I have tried a variety of approaches including storing a session variable when the user first logs in, but because the sitemap is already built, its tough to modify dynamically. Further, unfortunately, User1.sitemap and User2.sitemap don't play well together, and only one should be shown at one time depending on the user type. Not to take away from Markus' question, but if someone could address this more concrete scenario, it would be much appreciated. Thanks, Dave On Oct 10, 5:09 pm, marius d. marius.dan...@gmail.com wrote: Well SiteMap is per LiftRules which means it's per application runtime. One approach would be to define the entire SiteMap but depending on the context using some conditional Hidden LocParam. Perhaps something like: case object CondHidden(coond: () = Boolean) extends LocParam This could be used in conjunction with If/Unless/Test LocParam-s to also grant access per context (even if the Loc is Hidden) This probably won't suffice if you want each user to have its own unique SiteMap. Can you elaborate more on your application usecase? ... in what way you want unique SiteMap per user? Other option would be to have in LiftRules something like: val sessionSiteMap: (LiftSession) = SiteMap This means that you can provide a function that will create a SiteMap depending on the LiftSession ... which would probably be called after LiftSession is created. I'm not sure if this is the way to do it as this would act as a secondary SiteMap ... and this would complicate things a bit for the Lift engine. Br's, Mariu On Oct 9, 11:36 pm, Markus Kolb liftweb...@tower-net.de wrote: Hi, I'm something new to Scala and Lift is freshmeat for me. At the moment I am trying to find a best practice possibility to setSiteMap with a SiteMap which includes Menus and Locs which might change during application runtime. Let me say... each user should get his own, unique SiteMap after login. The SiteMap should be generated based on class construction and method calls during runtime. I've the problem to find a solution without putting setSiteMap-call nearly everywhere in my code just to update it. Uumh. Yes. Any tips are welcome... Best regards, Markus --~--~-~--~~~---~--~~ 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: Dynamic SiteMap
Yes, a Loc accepts many LocParams ... as I said above If/Unless/Test would be used in conjunction with CondHidden to also provide accessibility constraints. Here is the definition case object CondHidden(test: () = Boolean) extends LocParam but we also have case class If(test: () = Boolean, failMsg: FailMsg) extends LocParam So the test function is the same which means that you essentially implement one function and provide it to both LocParam's. We could probably combine the two LocParams in a: IfHidden(test: () = Boolean, failMsg: FailMsg) // if you have a better name please let me know :) The test function would be called in two cases: 1. When rendering the Menu to see is the Menu should be rendered or not 2. When try to access the location to as a security check I could probably add it this week and point you to my branch to check it out. If I runt into something weird that I cannot foresee I'll let you know. Would this work for you? Other people are welcome to comment as well ... Br's, Marius On Oct 11, 7:06 pm, Dave davidtgoldb...@gmail.com wrote: Hi Marius, Thanks for the response. The LocParam is a good idea, but here is the attendant problem. No only do I have to hide options A,B,C from user type 2, I have to make sure user type 2 does not access those pages/ areas. Can I include that in the locParam as well? Right now, I'm using an If() val to determine what type of user it is, and then funnel accordingly. I assume i can just include both the if (to determine access/where to send) and then the conditional hider LocParam if necessary. But can I bundle both into a more DRY solution? Thanks, Dave On Oct 11, 2:54 am, marius d. marius.dan...@gmail.com wrote: So doesn't what I described about help you? ... a conditional Hidden LocParam? ...thus the SiteMap contains all A, B, C, D, E, F menus but for user type 1 D, E,, F are hidden, and for user type 2 A, B, C are hidden. The decision would done in the function that you provide to CondHidden. If this helps the new LocParam could be added with not much problems. If this doesn't work for you, please elaborate. Br's, Marius On Oct 11, 2:09 am, Dave davidtgoldb...@gmail.com wrote: Hi all- I am interested in a similar question. I have two types of users and once logged in, I'd like to provide them with distinct menu options. For instance User type one would have a menu with A / B / C and User Type Two would have D / E / F. I have tried a variety of approaches including storing a session variable when the user first logs in, but because the sitemap is already built, its tough to modify dynamically. Further, unfortunately, User1.sitemap and User2.sitemap don't play well together, and only one should be shown at one time depending on the user type. Not to take away from Markus' question, but if someone could address this more concrete scenario, it would be much appreciated. Thanks, Dave On Oct 10, 5:09 pm, marius d. marius.dan...@gmail.com wrote: Well SiteMap is per LiftRules which means it's per application runtime. One approach would be to define the entire SiteMap but depending on the context using some conditional Hidden LocParam. Perhaps something like: case object CondHidden(coond: () = Boolean) extends LocParam This could be used in conjunction with If/Unless/Test LocParam-s to also grant access per context (even if the Loc is Hidden) This probably won't suffice if you want each user to have its own unique SiteMap. Can you elaborate more on your application usecase? ... in what way you want unique SiteMap per user? Other option would be to have in LiftRules something like: val sessionSiteMap: (LiftSession) = SiteMap This means that you can provide a function that will create a SiteMap depending on the LiftSession ... which would probably be called after LiftSession is created. I'm not sure if this is the way to do it as this would act as a secondary SiteMap ... and this would complicate things a bit for the Lift engine. Br's, Mariu On Oct 9, 11:36 pm, Markus Kolb liftweb...@tower-net.de wrote: Hi, I'm something new to Scala and Lift is freshmeat for me. At the moment I am trying to find a best practice possibility to setSiteMap with a SiteMap which includes Menus and Locs which might change during application runtime. Let me say... each user should get his own, unique SiteMap after login. The SiteMap should be generated based on class construction and method calls during runtime. I've the problem to find a solution without putting setSiteMap-call nearly everywhere in my code just to update it. Uumh. Yes. Any tips are welcome... Best regards, Markus --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift
[Lift] Re: Dynamic SiteMap
Well SiteMap is per LiftRules which means it's per application runtime. One approach would be to define the entire SiteMap but depending on the context using some conditional Hidden LocParam. Perhaps something like: case object CondHidden(coond: () = Boolean) extends LocParam This could be used in conjunction with If/Unless/Test LocParam-s to also grant access per context (even if the Loc is Hidden) This probably won't suffice if you want each user to have its own unique SiteMap. Can you elaborate more on your application usecase? ... in what way you want unique SiteMap per user? Other option would be to have in LiftRules something like: val sessionSiteMap: (LiftSession) = SiteMap This means that you can provide a function that will create a SiteMap depending on the LiftSession ... which would probably be called after LiftSession is created. I'm not sure if this is the way to do it as this would act as a secondary SiteMap ... and this would complicate things a bit for the Lift engine. Br's, Mariu On Oct 9, 11:36 pm, Markus Kolb liftweb...@tower-net.de wrote: Hi, I'm something new to Scala and Lift is freshmeat for me. At the moment I am trying to find a best practice possibility to setSiteMap with a SiteMap which includes Menus and Locs which might change during application runtime. Let me say... each user should get his own, unique SiteMap after login. The SiteMap should be generated based on class construction and method calls during runtime. I've the problem to find a solution without putting setSiteMap-call nearly everywhere in my code just to update it. Uumh. Yes. Any tips are welcome... Best regards, Markus --~--~-~--~~~---~--~~ 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: Started integrating lift in a scala+spring project. Feedback?
You are correct. I need to make this adjustment today. Thanks for
pointing this out Tim.
Br's,
Marius
On Oct 8, 2:05 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Marius,
Im not sure that will work as ctx is a paramater, not a val paramater.
class HTTPServletContext(ctx: ServletContext) extends HTTPContext
In order to do what you'd suggested wouldnt it need to be:
class HTTPServletContext(val ctx: ServletContext) extends HTTPContext
Thoughts?
Cheers, Tim
On Oct 7, 7:50 pm, marius d. marius.dan...@gmail.com wrote:
Servlet dependencies are abstracted away by a dedicated layer from the
rest of Lift.
LiftRules.context match {
case c: HTTPServletContext = c.ctx // this is a ServletContext
case _ =
}
So you can take the ServletContext and do your stuff with it. But in
this case you explicitly know that you are running Lift in a JEE web
container.
This abstraction is necessary to us in order to be able to run lift
apps in other no JEE containers (Netty, AsyncWeb, Portlets etc).
Br's,
Marius
On Oct 7, 8:40 pm, rintcius rintc...@gmail.com wrote:
Your best bet is to go find some Java static thing that's going to give
you
the ServletContext
Yes that could work, but is it an idea to make the liftServlet
available as an object in Lift (when it has the right provider)?
Then the servletContext can be obtained nicely via
liftServlet.getServletContext()
--~--~-~--~~~---~--~~
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: Started integrating lift in a scala+spring project. Feedback?
I just committed it.
Br's,
Marius
On Oct 8, 2:25 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Thanking you kindly good sir - I knew there was something not quite
right about that :-)
Cheers, Tim
On Oct 8, 12:15 pm, marius d. marius.dan...@gmail.com wrote:
You are correct. I need to make this adjustment today. Thanks for
pointing this out Tim.
Br's,
Marius
On Oct 8, 2:05 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Marius,
Im not sure that will work as ctx is a paramater, not a val paramater.
class HTTPServletContext(ctx: ServletContext) extends HTTPContext
In order to do what you'd suggested wouldnt it need to be:
class HTTPServletContext(val ctx: ServletContext) extends HTTPContext
Thoughts?
Cheers, Tim
On Oct 7, 7:50 pm, marius d. marius.dan...@gmail.com wrote:
Servlet dependencies are abstracted away by a dedicated layer from the
rest of Lift.
LiftRules.context match {
case c: HTTPServletContext = c.ctx // this is a ServletContext
case _ =
}
So you can take the ServletContext and do your stuff with it. But in
this case you explicitly know that you are running Lift in a JEE web
container.
This abstraction is necessary to us in order to be able to run lift
apps in other no JEE containers (Netty, AsyncWeb, Portlets etc).
Br's,
Marius
On Oct 7, 8:40 pm, rintcius rintc...@gmail.com wrote:
Your best bet is to go find some Java static thing that's going to
give you
the ServletContext
Yes that could work, but is it an idea to make the liftServlet
available as an object in Lift (when it has the right provider)?
Then the servletContext can be obtained nicely via
liftServlet.getServletContext()
--~--~-~--~~~---~--~~
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: Started integrating lift in a scala+spring project. Feedback?
Servlet dependencies are abstracted away by a dedicated layer from the
rest of Lift.
LiftRules.context match {
case c: HTTPServletContext = c.ctx // this is a ServletContext
case _ =
}
So you can take the ServletContext and do your stuff with it. But in
this case you explicitly know that you are running Lift in a JEE web
container.
This abstraction is necessary to us in order to be able to run lift
apps in other no JEE containers (Netty, AsyncWeb, Portlets etc).
Br's,
Marius
On Oct 7, 8:40 pm, rintcius rintc...@gmail.com wrote:
Your best bet is to go find some Java static thing that's going to give you
the ServletContext
Yes that could work, but is it an idea to make the liftServlet
available as an object in Lift (when it has the right provider)?
Then the servletContext can be obtained nicely via
liftServlet.getServletContext()
--~--~-~--~~~---~--~~
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: lift nearly inaccessible for newby
Ko, You are in an interesting position :) ... Personally if I would be in your place I would not start with PHP. I would probably start understanding Java servlets and the horrible and crappy JSP's. Then I would try to understand Java not only as a language but also as a platform. Then I would start with Scala. David's book Beginning Scala is an excellent material. Then or maybe in parallel with that dig in Lift. I'm sure you realise there are lots of things for you to digest, but by all means don't let this stop you. Lift and Scala are just great and definitely worth the effort. Br's, Marius On Oct 5, 9:32 pm, koveen liep...@xs4all.nl wrote: Hi, Being a no-programmer and having no Java-background I'd like to have mentioned that Lift really isn't an easy framework. Having said that, I will try to read my way into this system and try to solve the problems I encounter. I have one question. I would like to establish a login method where a visitor of my site (to be) could be accepted as a valid user, based on the info the server receives when the visitor enters the site. In my case it will be a site for mobile phones and some mobile phone operators will provide me with the telephone-number of the user once she enters. Once a user has paid for the service, this number alone should be enough to make the visitior into a valid user. Without needing to log in. I have read the following on:http://demo.liftweb.net/ws t's easy to dispatch incoming HTTP requests. In your Boot class create a PartialFunction that matches a pattern related to the incoming request and then create a short-lived controller to service the request. This code matches all the requests to /webservices/ and assigns the stuff in '' to the variable c. Then the code attempts to find a public method with that name on the controller. If the method exists, it's invoked and Lift processes the result. I assume I will have to write my own public method and place it where??? in the direcory webservices.? Maven didn't include such a directory in my project set-up, so I assume this webservices are on an external server and that I will have torefer to and extend an existing function. Am I correct in this? and is there an exemple of how to write such a method. I would be really happy to make some progress, and any help is welcome. Thanks, Ko --~--~-~--~~~---~--~~ 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 share request scope data among snippets in Lift
On Oct 5, 6:15 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
On Sun, Oct 4, 2009 at 2:41 AM, ishiijp yoshinori.is...@gmail.com wrote:
Thank you for your example, David.
It will work in my purpose.
Cool.
It seems that my poor English and less information let some people
confused.
I appreciate that you have put in the work to translate your thoughts to
English. I apologize that I only speak English, but would love to speak
Japanese, German, Russian, and a few other languages.
oh you gotta learn Romanian :)
I need just a request scope data.
It means I want to share information between snippets across a
request.
(Is the expression request scope not good for in this case...?)
request scope is exactly the right phrase.
Thank all responsed my post,
and your suggestions are informative.
I think very nice community is here.
On 9月26日, 午後10:33, David Pollak feeder.of.the.be...@gmail.com wrote:
To share information between snippets during a request, use a RequestVar:
object MyInfo extends RequestVar(calculate_value)
so
object MyInfo extends RequestVar[Box[Invoice]](Empty)
in one snippet, you may calculate the Invoice and put it in the MyInfo:
MyInfo.set(Full(invoice))
In another snippet, you can extract:
for {
invoice - MyInfo.is
} yield ...
Note that the calculate_value is a call-by-name parameter, so it will
be
invoked each time the RequestVar is uninitialized. You can place lazy
calculation logic in here.
On Sat, Sep 26, 2009 at 12:14 AM, ishiijp yoshinori.is...@gmail.com
wrote:
Hi.
If my lift application have some data that cost to create, and I want
to share it among snippets, how to do in Lift?
if such data are shared inside one snippet, I may use lazy val.
But I have no nice idea to share it among different snippts.
Thanks much.
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
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: execute code when browser is closed
HTTP session termination does not equate with browser-close event. Br's, Marius On Oct 5, 3:22 pm, Jack Widman jack.wid...@gmail.com wrote: Yes, thats what I meant. Thanks On Mon, Oct 5, 2009 at 4:10 AM, Timothy Perrett timo...@getintheloop.euwrote: But you can do it on session termination (which is what you probably want): http://scala-tools.org/mvnsites-snapshots/liftweb/lift-webkit/scalado... Checkout the method: registerCleanupFunc Cheers, Tim On Oct 5, 8:54 am, Viktor Klang viktor.kl...@gmail.com wrote: On Mon, Oct 5, 2009 at 6:50 AM, jack jack.wid...@gmail.com wrote: I would like to call a function when the browser is closed. How do I do this? You cannot reliably do this. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder:http://groups.google.com/group/softpub -- Jack --~--~-~--~~~---~--~~ 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: Lift with JavaRebel, Jetty: Can I add views and/or modify Boot.scala without restarting Jetty?
Well this is not Lift's fault ... Lift application is initialized only once as the servlet filter is. Running boot more then once per context may lead to unexpected behaviors and in LiftRules we have a guard for RuleSeq that they can not be changed after boot is executed. You could however dynamically re-set the SiteMap ... something like LiftRules.siteMap.map(sm = LiftRules.setSiteMap(SiteMap((sm.menus ++ some_otherMenus):_*)) where some_otherMenus is a List[Menu] (I haven't actually compiled the code but you get the idea) But this is not quite what you want and I'm not even convinced that we should allow things like this. Br's, Marius On Oct 4, 6:11 pm, Alex Black a...@alexblack.ca wrote: Thanks Tim and Viktor.. Thats disappointing, I was hoping I wouldn't have to restart the jetty server if when I added a new view. Maybe there is a creative way around this? E.g. is there a way to get a new view/page into lift without modifying Boot.scala? - Alex On Oct 4, 11:09 am, Timothy Perrett timo...@getintheloop.eu wrote: Agreed - changes that modify lifts enviroment require restarting jetty. It's not ideal perhaps, but it's with good reason. Cheers, Tim Sent from my iPhone On 4 Oct 2009, at 11:24, Viktor Klang viktor.kl...@gmail.com wrote: Boot is just executed at webapp init, hence the observed behavior. Changing this is a tricky thing On Oct 4, 2009 4:35 AM, Alex Black a...@alexblack.ca wrote: I'm just getting started with Lift and Scala, and I'm excited about using JavaRebel to avoid waiting to restart Jetty every time I make a change. It seems to be working well: I can see changes made to snippets for example right away, I'm running mvn scala:cc: and I see it pick up the changes. However, if I add a new view say test2.html, then modify the sitemap Boot.scala, I can't access test2 until I restart Jetty, even though I saw that scala.cc picked up the change and recompiled Boot.scala. Should this be possible? Thanks! - Alex --~--~-~--~~~---~--~~ 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: comet
Well render will be called for sure ... but if you build your comet component to rely only with partial updates when updating coment's real estate and don't call re-render then render should be called only when page is loaded, meaning that you can reset any state there. ... of course unless something escapes me :) Br's, Marius On Oct 4, 6:12 pm, jack jack.wid...@gmail.com wrote: How can assure that every time a comet page is loaded, it starts again fresh? I.e. as if the page were being loaded for the first time? --~--~-~--~~~---~--~~ 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: Lift with JavaRebel, Jetty: Can I add views and/or modify Boot.scala without restarting Jetty?
I know Alex :) ... It's just when you change a class and it is immediately exposed by JavaRebel a call flow must imply thechanged class in order to see the changes in action and for Boot it is not applicable as it's executed only once. But you already know that ... Br's, Marius On Oct 4, 6:48 pm, Alex Black a...@alexblack.ca wrote: Marius, I'm not trying to lay blame :) I'm sure I'll get by, restarting jetty when pages are added.. I was hoping for more though given what I'd read about JavaRebel and Lift integration. - Alex On Oct 4, 11:40 am, marius d. marius.dan...@gmail.com wrote: Well this is not Lift's fault ... Lift application is initialized only once as the servlet filter is. Running boot more then once per context may lead to unexpected behaviors and in LiftRules we have a guard for RuleSeq that they can not be changed after boot is executed. You could however dynamically re-set the SiteMap ... something like LiftRules.siteMap.map(sm = LiftRules.setSiteMap(SiteMap((sm.menus ++ some_otherMenus):_*)) where some_otherMenus is a List[Menu] (I haven't actually compiled the code but you get the idea) But this is not quite what you want and I'm not even convinced that we should allow things like this. Br's, Marius On Oct 4, 6:11 pm, Alex Black a...@alexblack.ca wrote: Thanks Tim and Viktor.. Thats disappointing, I was hoping I wouldn't have to restart the jetty server if when I added a new view. Maybe there is a creative way around this? E.g. is there a way to get a new view/page into lift without modifying Boot.scala? - Alex On Oct 4, 11:09 am, Timothy Perrett timo...@getintheloop.eu wrote: Agreed - changes that modify lifts enviroment require restarting jetty. It's not ideal perhaps, but it's with good reason. Cheers, Tim Sent from my iPhone On 4 Oct 2009, at 11:24, Viktor Klang viktor.kl...@gmail.com wrote: Boot is just executed at webapp init, hence the observed behavior. Changing this is a tricky thing On Oct 4, 2009 4:35 AM, Alex Black a...@alexblack.ca wrote: I'm just getting started with Lift and Scala, and I'm excited about using JavaRebel to avoid waiting to restart Jetty every time I make a change. It seems to be working well: I can see changes made to snippets for example right away, I'm running mvn scala:cc: and I see it pick up the changes. However, if I add a new view say test2.html, then modify the sitemap Boot.scala, I can't access test2 until I restart Jetty, even though I saw that scala.cc picked up the change and recompiled Boot.scala. Should this be possible? Thanks! - Alex --~--~-~--~~~---~--~~ 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: Model Events
Scala has a natural support for events notifications = Scala Actors. It's a very natural fit for building event driven systems. In Lift we're moving CometActors to LiftActors instead of Scala Actors due to some memory consumption problems with current Scala actors implementation which are probably fixed now in Scala 2.7.7 RC1. So definitely yes, event driven programming is quite fitful in Lift. Br's, Marius On Oct 4, 8:25 pm, donfranciscodequevedo donfranciscodequev...@gmail.com wrote: I have been looking for Web frameworks that will take advantage of an Event Driven programming model. Some Frameworks like Python's Zope and Grails manage to subscribe to Model Events. E.g. one can subscribe to a notification message, whenever a domain model gets changed, added, deleted, etc. (like explained here http://bit.ly/2AkVBy) Can the Lift Framework throw such events too? Similar to the way Grails and Zope do it? Or is there another way in Lift to do the same? I must say that I preety much do like the Lift Framework and it's fresh approach on important tasks like Comet, Templating, Active Record, Web Services, Localization... However one of my key requirements would be simple handling of events and notifications. Thank you Gregor --~--~-~--~~~---~--~~ 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: RFC: Restructuring Lift Codebase [Round 2]
Why not lift-core = (lift-common, lift-util, lift-json, lift- actor,lift-webkit) ? Br's, Marius On Oct 3, 7:33 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 02/10/09 6:25 PM, David Pollak wrote: On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com wrote: On Oct 2, 5:39 pm, David Pollak feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com wrote: On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.comwrote: Folks, Following up from the previous round, I am summarizing what we discussed so far with an attempt to converge and move on to impl. Would be keen to have feedback and possibly arrive at some resolution on the outstanding items. (Meaty stuff below the module structure) liftweb - lift-core [H] - lift-base [J] - lift-util [J] - lift-actor - lift-json - lift-webkit [K] - lift-persistence - lift-mapper - lift-record - lift-jpa - lift-modules [L] - lift-testkit - lift-osgi - lift-wizard - lift-widgets - lift-machine - lift-textile - lift-facebook - lift-amqp - lift-xmpp - lift-openid - lift-oauth - lift-paypal - lift-jta - lift-archetypes - ... - lift-examples [M] - ... - lift-site - lift-resources [N] - lift-root-model - lift-site-skin - lift-installer - misc config resources (scaladoc, javadoc etc.) Resolved since: [A] lift-* prefix is fine/preferred for top level categories (dir_name == artifactId) [Heiko] [B] For Lift users not using Maven these *-all.jars will be valuable. Assembly preferred to meta [Heiko] [C] lift-testkit to move to lift-modules. Applications would use it under 'test' scope. [David] [D] lift-json to be part of core [Marius] [E] lift-persistence being separated from lift-core into it's own category and made optional [Marius] [F] No deep nesting within modules (no submodules) for now [Heiko] [G] Presentations and docs to be in central repository for now [+1:David/Tim/Derek, +0:Indrajit, -1:Heiko/Viktor]. Settling for central repo at the moment (a: least change, b: in a hurry to converge, c: effect of living in largest democracy in the world!). Later on, I'll attempt to make this part of site build and make them more conveniently available. Outstanding since: [H] lift-core has to get a better and more appropriate name (and also to avoid confusion since lift-core == 'everything lift' at the moment). Starting with two that come to my mind. - lift-lite (Members of this category make up the lightweight, minimalistic Lift distribution that would help you build a Lift based application) - lift-genesis (Members of this category make up the genesis of your Lift based application) - lift-mini (Minimal Lift distribution to get started with Lift) - lift-minimal (Same as above) How about lift-web (the stuff you need to build a web application) Hmm, lift-web vs lift-web/lift-webkit could add to confusion. Too many combination of lift+web (liftweb.net http://liftweb.net, lift-web, lift-webkit) for comfort. okay. Now that lift-base is free for grab, I am settling for lift-base for lack of any other clear winner. So we have lift-base = (lift-common, lift-util, lift-json, lift-actor, lift-webkit) Feel free to comment in favor or against (vote/veto) if someone has a better option popping up. [J] lift-base, lift-util needs more unambiguous names. - lift-base - lift-common [+1:Naftoli/Derek/Stuart/Marius/Tim/ Heiko/Viktor, +0:Indrajit -1:DavidB (very strong)] But still good to have even better option. +1 for lift-common, but I'm not wedded to the name. - lift-util - lift-util (no change) [+1:Marius/David (status quo)] I'm going to mandate that this not change. The cost of changing is too high and the value to changing is minimal. - lift-util - lift-webutil [+1:Naftoli/Derek/Stuart/Indrajit/Tim/ Heiko/Viktor] Veto. Fair do. let's settle for lift-common and lift-util for now. snip/ Cheers, Indrajit --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to
[Lift] Re: 1.1-SNAPSHOT and Snippet problems?
What verions of lift are you using? It appears that lift-util is a
different version than lift ?
Br's,
Marius
On Oct 3, 11:11 pm, Thomas Rampelberg pyronic...@gmail.com wrote:
I just synced up to main this morning and now whenever I try and use
one of my snippets, I'm getting the traceback below. Any hints on what
I'm doing wrong? The snippet in question is just the basic
Util.in/Util.out that the tutorial has you write.
div class=column span-17 last
lift:Util.in
lift:bind name=content /
/lift:Util.in
lift:Util.out
h3 class=alt
You must be logged in to view this content.
lift:menu.item name=LoginLogin/lift:menu.item
/h3
/lift:Util.out
/div
class Util {
def in(html: NodeSeq) =
if (User.loggedIn_?) html else NodeSeq.Empty
def out(html: NodeSeq) =
if (!User.loggedIn_?) html else NodeSeq.Empty
}
Message: java.lang.AbstractMethodError:
net.liftweb.util.Helpers$.tryo(Lscala/PartialFunction;Lscala/Function0;)Lnet/liftweb/util/Box;
net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$instantiateOrRedirect(LiftSession.scala:862)
net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)
net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1$$anonfun$apply$41.apply(LiftSession.scala:911)
net.liftweb.util.Full.flatMap(Box.scala:332)
net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)
net.liftweb.http.LiftSession$$anonfun$net$liftweb$http$LiftSession$$findSnippetInstance$1.apply(LiftSession.scala:911)
net.liftweb.util.EmptyBox.or(Box.scala:374)
net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$findSnippetInstance(LiftSession.scala:910)
net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)
net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1$$anonfun$17.apply(LiftSession.scala:967)
net.liftweb.util.EmptyBox.or(Box.scala:374)
net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:967)
net.liftweb.http.LiftSession$$anonfun$locateAndCacheSnippet$1$1.apply(LiftSession.scala:966)
net.liftweb.util.EmptyBox.or(Box.scala:374)
net.liftweb.http.LiftSession.locateAndCacheSnippet$1(LiftSession.scala:966)
net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:978)
net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48$$anonfun$apply$50.apply(LiftSession.scala:976)
net.liftweb.util.EmptyBox.openOr(Box.scala:372)
net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)
net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45$$anonfun$apply$48.apply(LiftSession.scala:976)
net.liftweb.util.EmptyBox.openOr(Box.scala:372)
net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)
net.liftweb.http.LiftSession$$anonfun$18$$anonfun$apply$45.apply(LiftSession.scala:975)
net.liftweb.http.S$.doSnippet(S.scala:1586)
net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:973)
net.liftweb.http.LiftSession$$anonfun$18.apply(LiftSession.scala:972)
net.liftweb.util.Full.map(Box.scala:330)
net.liftweb.http.LiftSession.net$liftweb$http$LiftSession$$processSnippet(LiftSession.scala:972)
net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1073)
net.liftweb.http.LiftSession$$anonfun$_defaultLiftTagProcessing$1.apply(LiftSession.scala:1061)
net.liftweb.util.NamedPF.apply(NamedPartialFunction.scala:30)
net.liftweb.util.NamedPF$.apply(NamedPartialFunction.scala:76)
net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)
net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58$$anonfun$apply$59.apply(LiftSession.scala:1094)
net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:65)
net.liftweb.http.S$.setVars(S.scala:1414)
net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58.apply(LiftSession.scala:1093)
net.liftweb.http.LiftSession$$anonfun$processSurroundAndInclude$1$$anonfun$apply$57$$anonfun$apply$58.apply(LiftSession.scala:1093)
net.liftweb.http.S$.withAttrs(S.scala:1433)
[Lift] Re: RFC: Restructuring Lift Codebase [Round 2]
Ok ... got it. Thanks. On Oct 3, 10:16 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 04/10/09 12:32 AM, marius d. wrote: Why not lift-core = (lift-common, lift-util, lift-json, lift- actor,lift-webkit) ? 1. Initially, it didn't sound right to me (when we had lift-base, lift-util etc.). 2. DavidP commented, that lift-core currently means everything Lift. and he thought we'd need another name. 3. DavidB pointed out an old thread[a] and suggested that: lift-core == lift-full, but to be backward compatible with the time when there is one jar (lift-core), we keep the name. [a]http://groups.google.com/group/lift-committers/browse_thread/thread/2... Of these, #1 doesn't hold true anymore, thus nullified. Cheers, Indrajit Br's, Marius On Oct 3, 7:33 pm, Indrajit Raychaudhuriindraj...@gmail.com wrote: On 02/10/09 6:25 PM, David Pollak wrote: On Fri, Oct 2, 2009 at 5:53 AM, Indrajit Raychaudhuri indraj...@gmail.commailto:indraj...@gmail.com wrote: On Oct 2, 5:39 pm, David Pollakfeeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com wrote: On Fri, Oct 2, 2009 at 3:43 AM, Indrajit Raychaudhuri indraj...@gmail.commailto:indraj...@gmail.comwrote: Folks, Following up from the previous round, I am summarizing what we discussed so far with an attempt to converge and move on to impl. Would be keen to have feedback and possibly arrive at some resolution on the outstanding items. (Meaty stuff below the module structure) liftweb - lift-core [H] - lift-base [J] - lift-util [J] - lift-actor - lift-json - lift-webkit [K] - lift-persistence - lift-mapper - lift-record - lift-jpa - lift-modules [L] - lift-testkit - lift-osgi - lift-wizard - lift-widgets - lift-machine - lift-textile - lift-facebook - lift-amqp - lift-xmpp - lift-openid - lift-oauth - lift-paypal - lift-jta - lift-archetypes - ... - lift-examples [M] - ... - lift-site - lift-resources [N] - lift-root-model - lift-site-skin - lift-installer - misc config resources (scaladoc, javadoc etc.) Resolved since: [A] lift-* prefix is fine/preferred for top level categories (dir_name == artifactId) [Heiko] [B] For Lift users not using Maven these *-all.jars will be valuable. Assembly preferred to meta [Heiko] [C] lift-testkit to move to lift-modules. Applications would use it under 'test' scope. [David] [D] lift-json to be part of core [Marius] [E] lift-persistence being separated from lift-core into it's own category and made optional [Marius] [F] No deep nesting within modules (no submodules) for now [Heiko] [G] Presentations and docs to be in central repository for now [+1:David/Tim/Derek, +0:Indrajit, -1:Heiko/Viktor]. Settling for central repo at the moment (a: least change, b: in a hurry to converge, c: effect of living in largest democracy in the world!). Later on, I'll attempt to make this part of site build and make them more conveniently available. Outstanding since: [H] lift-core has to get a better and more appropriate name (and also to avoid confusion since lift-core == 'everything lift' at the moment). Starting with two that come to my mind. - lift-lite (Members of this category make up the lightweight, minimalistic Lift distribution that would help you build a Lift based application) - lift-genesis (Members of this category make up the genesis of your Lift based application) - lift-mini (Minimal Lift distribution to get started with Lift) - lift-minimal (Same as above) How about lift-web (the stuff you need to build a web application) Hmm, lift-web vs lift-web/lift-webkit could add to confusion. Too many combination of lift+web (liftweb.nethttp://liftweb.net, lift-web, lift-webkit) for comfort. okay. Now that lift-base is free for grab, I am settling for lift-base for lack of any other clear winner. So we have lift-base = (lift-common, lift-util, lift-json, lift-actor, lift-webkit) Feel free to comment in favor
[Lift] Re: Concurrent Web Service Requests?
Well I said what I had to say. My problem is not really the prefix
name but the existence of other prefixes then lift, that are
interpreted by lift. It's just how I see things now and nothing on
this thread provided sufficient arguments to convince me
otherwise ...
not much else for me to do if majority and especially DPP thinks
otherwise. It is what it is I guess.
Br's,
Marius
On Oct 1, 4:18 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
I think everyone agrees in concept, that an arbitrary prefix sets a bad
precendent, which is why it is no longer do:par. But on the other hand, if
the part after lift: is either a reserved word or a user word--a snippet
name--then the more reserved words, the more you limit snippet names. (Should
S.mapSnippet(parallel, ...) throw an exception?)
So we have these two considerations on either end of the spectrum. Arguably,
liftx as a prefix satisfies both--it is sufficiently generic to include
almost any special attribute that may be added, it clearly spells out
extended lift attribute, and on the other hand it keeps reserved lift
attributes separate from the user's snippet namespace.
Now let's bear in mind that this is all only relevant in the future, when
lift: attributes indeed will be interpreted as lift:snippet=... is now. At
that point it might make sense for the explicit :snippet format to be moved
to the liftx prefix-- liftx:snippet=... --for the same reason, not to
encroach on the snippet namespace.
-
marius d.marius.dan...@gmail.com wrote:
It has been debated many times in slightly different contexts. To me
it is more about clarity. We add a new prefix now, tomorrow add
another one and so on. People would have to remember what goes where
and mix things up. To me lift prefix is enough and quite clear. It is
more than just s snippet thingy. It tells the user hey this thing is
telling the framework something and the framework is doing something
with it. It is separating framework xml markup from the actual xhtml
markup. Having a single reserved prefix promotes clarity and keeps
things simple and rather intuitive.
I'm not in favor of using unprefixed attributes like
par=something (btw I really don't like par naming :) ...) because
unprefixed attributes should be only standard xhtml ones or the ones
that user explicitly specifies it. So lift:parallel=true or
lift:async=true should be just fine.
Br's,
Marius
On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Could you elaborate on why adding a new prefix may not be a good idea? And
is it better or worse than having it unprefixed?
-
marius d.marius.dan...@gmail.com wrote:
On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
I thought there were issues here because anything starting lift: gets
executed as a snippet.
Correct BUT lift:par or lift:parallel attributes are also applicable
to snippets context. They determine the snippet's execution semantics.
So I'm still questioning the need for a new prefix.
I'm still for an eval: prefix, as these proposals all relate to how a
page is evaluated.
On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com
wrote:
lift is already a reserved prefix for snippets. So I'd stay with
simply lift prefix for these attributes as well.
Br's,
Marius
On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
So what is your proposal? Am I interpreting you correctly that you are
for a prefix of 'lift'? And it will be a reserved suffix?
-
marius d.marius.dan...@gmail.com wrote:
I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.
But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.
Br's,
Marius
On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
If you like the idea of having them all as attributes but don't
like the
idea of using a single attribute ('xx:eager_eval=true
xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is
the
prefix to be chosen) then maybe the prefix should be 'eval'.
I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true
The reasons for not combining them
[Lift] Re: Concurrent Web Service Requests?
David, Thank you very much for your kind words. Personally I don't see any reason why the lift prefix can not also have the semantic for enriching the context you described this thing will be changed based on evaluating some code.. These are after all attributes and attributes to me are about about meta-data on how lift will change markup. I will do what you suggested hopefully by next Monday ... and this time using the proper process ;) Br's, Marius On Oct 1, 7:03 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Marius, I have a ton of respect for your opinion and I appreciate your analysis. I have been following this thread and thinking, what does the lift: prefix mean? In my mind, it means this thing will be changed based on evaluating some code. So, using the lift: prefix for something that also means this modifies the meaning of this snippet invocation presents something discordant to me. With that being said, I'm going to hand the decision to you. I trust your decisions and have concerns about my own instincts when it comes to naming. Please update the code to reflect what you think it should be and merge it into master. Thanks, David On Thu, Oct 1, 2009 at 5:58 AM, marius d. marius.dan...@gmail.com wrote: Well I said what I had to say. My problem is not really the prefix name but the existence of other prefixes then lift, that are interpreted by lift. It's just how I see things now and nothing on this thread provided sufficient arguments to convince me otherwise ... not much else for me to do if majority and especially DPP thinks otherwise. It is what it is I guess. Br's, Marius On Oct 1, 4:18 am, Naftoli Gugenheim naftoli...@gmail.com wrote: I think everyone agrees in concept, that an arbitrary prefix sets a bad precendent, which is why it is no longer do:par. But on the other hand, if the part after lift: is either a reserved word or a user word--a snippet name--then the more reserved words, the more you limit snippet names. (Should S.mapSnippet(parallel, ...) throw an exception?) So we have these two considerations on either end of the spectrum. Arguably, liftx as a prefix satisfies both--it is sufficiently generic to include almost any special attribute that may be added, it clearly spells out extended lift attribute, and on the other hand it keeps reserved lift attributes separate from the user's snippet namespace. Now let's bear in mind that this is all only relevant in the future, when lift: attributes indeed will be interpreted as lift:snippet=... is now. At that point it might make sense for the explicit :snippet format to be moved to the liftx prefix-- liftx:snippet=... --for the same reason, not to encroach on the snippet namespace. - marius d.marius.dan...@gmail.com wrote: It has been debated many times in slightly different contexts. To me it is more about clarity. We add a new prefix now, tomorrow add another one and so on. People would have to remember what goes where and mix things up. To me lift prefix is enough and quite clear. It is more than just s snippet thingy. It tells the user hey this thing is telling the framework something and the framework is doing something with it. It is separating framework xml markup from the actual xhtml markup. Having a single reserved prefix promotes clarity and keeps things simple and rather intuitive. I'm not in favor of using unprefixed attributes like par=something (btw I really don't like par naming :) ...) because unprefixed attributes should be only standard xhtml ones or the ones that user explicitly specifies it. So lift:parallel=true or lift:async=true should be just fine. Br's, Marius On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: Could you elaborate on why adding a new prefix may not be a good idea? And is it better or worse than having it unprefixed? - marius d.marius.dan...@gmail.com wrote: On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com wrote: I thought there were issues here because anything starting lift: gets executed as a snippet. Correct BUT lift:par or lift:parallel attributes are also applicable to snippets context. They determine the snippet's execution semantics. So I'm still questioning the need for a new prefix. I'm still for an eval: prefix, as these proposals all relate to how a page is evaluated. On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote: lift is already a reserved prefix for snippets. So I'd stay with simply lift prefix for these attributes as well. Br's, Marius On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: So what is your proposal? Am I interpreting you correctly that you are for a prefix of 'lift
[Lift] Re: Concurrent Web Service Requests?
On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
I thought there were issues here because anything starting lift: gets
executed as a snippet.
Correct BUT lift:par or lift:parallel attributes are also applicable
to snippets context. They determine the snippet's execution semantics.
So I'm still questioning the need for a new prefix.
I'm still for an eval: prefix, as these proposals all relate to how a
page is evaluated.
On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote:
lift is already a reserved prefix for snippets. So I'd stay with
simply lift prefix for these attributes as well.
Br's,
Marius
On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
So what is your proposal? Am I interpreting you correctly that you are for
a prefix of 'lift'? And it will be a reserved suffix?
-
marius d.marius.dan...@gmail.com wrote:
I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.
But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.
Br's,
Marius
On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
If you like the idea of having them all as attributes but don't like
the
idea of using a single attribute ('xx:eager_eval=true
xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is the
prefix to be chosen) then maybe the prefix should be 'eval'.
I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true
The reasons for not combining them:
- They are evaluated in different parts of the code, thus
eager/parallel
doesn't make sense from a code path perspective
- I am reserving the value of liftx:par for future implementation to
allow farming the snippet evaluation to another mechanism. Right
now, it's
hard-coded to use LiftActors. I can see a time when it would work
with Akka
actors or some other parallelization mechanism
As far as ajax evaluation I'm not sure I'm understanding. Could you
show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?
lift:Ajax !-- the snippet name will not be ajax, but you get the idea
--
lift:MySnippet/
/lift:Ajax
-
Ross Mellgrendri...@gmail.com wrote:
My 2 cents,
I'm not sure I'm a fan of do: namespace, though I agree it would be
nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?
-Ross
On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
What do you mean by as a normal snippet?
The parallel snippet processing is implemented deep inside
LiftSession. It's not a snippet. All the lift:xxx/ tags, even
those with defaults built into Lift, are implemented as snippets and
are invoked with normal snippet invocation mechanisms.
That you will nest your snippet inside a special snippet?
There is no special snippet. I used the word normal to highlight
that it's functionality that doesn't require a change to LiftSession
or other parts of Lift to function correctly.
To me it seems worthwhile to have a consistency between the two
syntax-wise, since they have some common denominator semantics-wise.
Actually, maybe throw in eager_eval to the mix. Maybe we could have
one eval or lift:eval or liftx:eval or whatever attribute, which can
contain a space separated list of specifiers--eager, ajax, parellel.
Anything that's prefixed with lift: is a snippet. I'm open to
unifying eager_eval and do:lazy (or do:par or do:parallel) into a
unified namespace.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
A snippet attribute can be invoked with something other than
lift:snippet=Class.method? There's a short syntax? What is it?
There may be a short syntax (e.g., lift:Class.method) in the future.
What was used for the feature that inserts a snippet
asynchronously via
Ajax?
That feature isn't done yet, but that feature is likely to be done
[Lift] Re: Concurrent Web Service Requests?
It has been debated many times in slightly different contexts. To me
it is more about clarity. We add a new prefix now, tomorrow add
another one and so on. People would have to remember what goes where
and mix things up. To me lift prefix is enough and quite clear. It is
more than just s snippet thingy. It tells the user hey this thing is
telling the framework something and the framework is doing something
with it. It is separating framework xml markup from the actual xhtml
markup. Having a single reserved prefix promotes clarity and keeps
things simple and rather intuitive.
I'm not in favor of using unprefixed attributes like
par=something (btw I really don't like par naming :) ...) because
unprefixed attributes should be only standard xhtml ones or the ones
that user explicitly specifies it. So lift:parallel=true or
lift:async=true should be just fine.
Br's,
Marius
On Sep 30, 8:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Could you elaborate on why adding a new prefix may not be a good idea? And is
it better or worse than having it unprefixed?
-
marius d.marius.dan...@gmail.com wrote:
On Sep 30, 8:23 am, Kevin Wright kev.lee.wri...@googlemail.com
wrote:
I thought there were issues here because anything starting lift: gets
executed as a snippet.
Correct BUT lift:par or lift:parallel attributes are also applicable
to snippets context. They determine the snippet's execution semantics.
So I'm still questioning the need for a new prefix.
I'm still for an eval: prefix, as these proposals all relate to how a
page is evaluated.
On Wed, Sep 30, 2009 at 5:34 AM, marius d. marius.dan...@gmail.com wrote:
lift is already a reserved prefix for snippets. So I'd stay with
simply lift prefix for these attributes as well.
Br's,
Marius
On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
So what is your proposal? Am I interpreting you correctly that you are
for a prefix of 'lift'? And it will be a reserved suffix?
-
marius d.marius.dan...@gmail.com wrote:
I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.
But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.
Br's,
Marius
On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
If you like the idea of having them all as attributes but don't like
the
idea of using a single attribute ('xx:eager_eval=true
xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is
the
prefix to be chosen) then maybe the prefix should be 'eval'.
I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true
The reasons for not combining them:
- They are evaluated in different parts of the code, thus
eager/parallel
doesn't make sense from a code path perspective
- I am reserving the value of liftx:par for future implementation to
allow farming the snippet evaluation to another mechanism. Right
now, it's
hard-coded to use LiftActors. I can see a time when it would work
with Akka
actors or some other parallelization mechanism
As far as ajax evaluation I'm not sure I'm understanding. Could
you show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?
lift:Ajax !-- the snippet name will not be ajax, but you get the
idea --
lift:MySnippet/
/lift:Ajax
-
Ross Mellgrendri...@gmail.com wrote:
My 2 cents,
I'm not sure I'm a fan of do: namespace, though I agree it would be
nice to have a common one. Maybe snippet:parallel,
snippet:eager_eval?
-Ross
On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
What do you mean by as a normal snippet?
The parallel snippet processing is implemented deep inside
LiftSession. It's not a snippet. All the lift:xxx/ tags, even
those with defaults built into Lift, are implemented as snippets
and
are invoked with normal snippet invocation mechanisms.
That you will nest your snippet inside a special snippet?
There is no special snippet. I used
[Lift] Re: VCard parser...
Hly cow ! I owe the committers more than a beer. I totally forgot about review board. All, please accept my apologies. Br's, Marius On Sep 29, 8:27 am, Timothy Perrett timo...@getintheloop.eu wrote: I guess we could let him off this time ;-) Any plans to add a vCard builder? I could really use that as it happens! Cheers Tim Sent from my iPhone On 29 Sep 2009, at 14:10, David Pollak feeder.of.the.be...@gmail.com wrote: Marius added it. He owes the committers a beer for not going through review board. On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, Who added the VCard parser, who ever made the commit needs to set there git username :-) VCard parsing is very, very cool - are there any plans for a builder for VCard? Cheers, Tim -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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: VCard parser...
Oh Tim ... a VCard builder should be easier then the parser. I'll add it hopefully in the next days/week ... and will go thru the review board. Damn I'm really sorry about not following the process ... Br's, Marius On Sep 29, 8:50 am, marius d. marius.dan...@gmail.com wrote: Hly cow ! I owe the committers more than a beer. I totally forgot about review board. All, please accept my apologies. Br's, Marius On Sep 29, 8:27 am, Timothy Perrett timo...@getintheloop.eu wrote: I guess we could let him off this time ;-) Any plans to add a vCard builder? I could really use that as it happens! Cheers Tim Sent from my iPhone On 29 Sep 2009, at 14:10, David Pollak feeder.of.the.be...@gmail.com wrote: Marius added it. He owes the committers a beer for not going through review board. On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, Who added the VCard parser, who ever made the commit needs to set there git username :-) VCard parsing is very, very cool - are there any plans for a builder for VCard? Cheers, Tim -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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: VCard parser...
I've looked on the diffs but I need to look into more details as these are no trivial changes. So far I really like what I'm seeing. Hopefully I'll have time today to do it. Br's, Marius On Sep 29, 1:02 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Tue, Sep 29, 2009 at 6:50 AM, marius d. marius.dan...@gmail.com wrote: Hly cow ! I owe the committers more than a beer. I totally forgot about review board. All, please accept my apologies. No worries, we're getting used to the new system. But, feel encouraged to reviewhttp://reviewboard.liftweb.net/r/15/ Br's, Marius On Sep 29, 8:27 am, Timothy Perrett timo...@getintheloop.eu wrote: I guess we could let him off this time ;-) Any plans to add a vCard builder? I could really use that as it happens! Cheers Tim Sent from my iPhone On 29 Sep 2009, at 14:10, David Pollak feeder.of.the.be...@gmail.com wrote: Marius added it. He owes the committers a beer for not going through review board. On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, Who added the VCard parser, who ever made the commit needs to set there git username :-) VCard parsing is very, very cool - are there any plans for a builder for VCard? Cheers, Tim -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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: VCard parser...
Oh wow :) Br's, Marius On Sep 29, 2:18 pm, Charles F. Munat c...@munat.com wrote: Oh, it's no problem, dude! I've been meaning to pick up a bottle of this Jacobsen Vintage #2 beer for a while now, but it's only available in Europe. Maybe you could ship me one? http://www.carlsberggroup.com/brands/Pages/Jacobsen_Vintage_no_2.aspx Chas. :-) marius d. wrote: Hly cow ! I owe the committers more than a beer. I totally forgot about review board. All, please accept my apologies. Br's, Marius On Sep 29, 8:27 am, Timothy Perrett timo...@getintheloop.eu wrote: I guess we could let him off this time ;-) Any plans to add a vCard builder? I could really use that as it happens! Cheers Tim Sent from my iPhone On 29 Sep 2009, at 14:10, David Pollak feeder.of.the.be...@gmail.com wrote: Marius added it. He owes the committers a beer for not going through review board. On Tue, Sep 29, 2009 at 1:10 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, Who added the VCard parser, who ever made the commit needs to set there git username :-) VCard parsing is very, very cool - are there any plans for a builder for VCard? Cheers, Tim -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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: Removing Scala Actors from Lift
I'd vote for: lift-common instead of lift-base. lift-base can be easily misinterpreted as lift's base traits and classes? ... which is not the case. This can hold, Box, comb parsers (JSON, VCard etc), liftactors etc. lift-util - things that are in the current util but lean towards web realm. Br's, Marius On Sep 29, 2:17 pm, Timothy Perrett timo...@getintheloop.eu wrote: +1 sounds like sense to me :-) Cheers, Tim Sent from my iPhone On 29 Sep 2009, at 19:20, Naftoli Gugenheim naftoli...@gmail.com wrote: If I was new to Lift and saw a lift-util module and a lift-base module and had to guess which did not depend on anything web related, I would probably pick lift-util without hesitation. After all, lift is the name of a web framework, and lift-base implies that it's basic but central classes etc. lift-util sounds like utilities that are useful to lift, even necessary, but not central to what lift is. Many libraries have a util that has code with broad applicability but that needed to be packaged with the library because it relies on it and it wan't worth it to get the functionality elsewhere. So if it's an option I would move the web-related functionality to lift-base and leave Box and Actor etc. in lift-util. - David Pollakfeeder.of.the.be...@gmail.com wrote: On Mon, Sep 28, 2009 at 10:47 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: What's the reason to have a new module (lift-base)? Why not put Actor to lift-util and keep Box where it is? Because there are a lot of web-related things in lift-utils. I am going to for a separate package that is far more generic. In your branch def !?(timeout: Long, param: T) will return an Option. Shouldn't this be a Box? Heiko 2009/9/29 David Pollak feeder.of.the.be...@gmail.com Folks, Given the continued instability of Scala Actors, I've decided to remove them from Lift. Specifically, I'm migrating CometActors to sit on top of Lift's Actors. But, you'll also be able to use Akka Actors to power Lift's CometActors. Specifically, I'm working with Jonas to make sure that we share a common interface to Actors. I've gotten Lift nearly completely migrated over to Lift's Actors on the dpp_wip_actorize branch. See http://github.com/dpp/liftweb/tree/dpp_wip_actorize There will be some breaking changes to your applications. Specifically: - Box will be moved to a new package, net.liftweb.base (this is where the interface for Actors will live as well) - If you make any assumptions about your CometActors being Scala Actors (e.g., using linking), you will have to rewrite this code - Some methods in Lift that currently take Scala Actors as parameters will take Lift Actors (e.g., ActorPing) There will be a parallel Maven repository with the new Lift Actor stuff in it so you will be able to build you apps against the new code before the official switch-over. Milestone 6 (which should be out next week) will be based on the existing Actor model. After we get feedback from the community about the new Actor stuff, we will switch -SNAPSHOT over to the new Actor stuff. Questions, thoughts, or comments? Thanks, David -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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: Concurrent Web Service Requests?
I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.
But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.
Br's,
Marius
On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
If you like the idea of having them all as attributes but don't like the
idea of using a single attribute ('xx:eager_eval=true xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is the
prefix to be chosen) then maybe the prefix should be 'eval'.
I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true
The reasons for not combining them:
- They are evaluated in different parts of the code, thus eager/parallel
doesn't make sense from a code path perspective
- I am reserving the value of liftx:par for future implementation to
allow farming the snippet evaluation to another mechanism. Right now, it's
hard-coded to use LiftActors. I can see a time when it would work with
Akka
actors or some other parallelization mechanism
As far as ajax evaluation I'm not sure I'm understanding. Could you show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?
lift:Ajax !-- the snippet name will not be ajax, but you get the idea --
lift:MySnippet/
/lift:Ajax
-
Ross Mellgrendri...@gmail.com wrote:
My 2 cents,
I'm not sure I'm a fan of do: namespace, though I agree it would be
nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?
-Ross
On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
What do you mean by as a normal snippet?
The parallel snippet processing is implemented deep inside
LiftSession. It's not a snippet. All the lift:xxx/ tags, even
those with defaults built into Lift, are implemented as snippets and
are invoked with normal snippet invocation mechanisms.
That you will nest your snippet inside a special snippet?
There is no special snippet. I used the word normal to highlight
that it's functionality that doesn't require a change to LiftSession
or other parts of Lift to function correctly.
To me it seems worthwhile to have a consistency between the two
syntax-wise, since they have some common denominator semantics-wise.
Actually, maybe throw in eager_eval to the mix. Maybe we could have
one eval or lift:eval or liftx:eval or whatever attribute, which can
contain a space separated list of specifiers--eager, ajax, parellel.
Anything that's prefixed with lift: is a snippet. I'm open to
unifying eager_eval and do:lazy (or do:par or do:parallel) into a
unified namespace.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
A snippet attribute can be invoked with something other than
lift:snippet=Class.method? There's a short syntax? What is it?
There may be a short syntax (e.g., lift:Class.method) in the future.
What was used for the feature that inserts a snippet
asynchronously via
Ajax?
That feature isn't done yet, but that feature is likely to be done
as a
normal snippet.
My concern is that as more features are thought up and added they
shouldn't
all end up with different prefixes.
Also, if the prefix is nothing special I would go with the more
verbose
parallel because otherwise it's not obvious what it does. If
it's prefixed
with lift: at least you know it's a lift tag and you can look it
up
somewhere or ask on the list etc. But if you come back to some old
template
that says do:par you may be left clueless.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Wed, Sep 23, 2009 at 3:59 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
Could that be changed to lift:concurrent or lift:par etc. (see
email on
scala-user from Marting Odersky mentioned the future use of
'seq' and
'par'
in concurrent collections)?
Why use a different prefix than everything else built in to
lift? And
'lazy' is arguably not what's happening.
We're using a different prefix because if we use a lift:xxx
prefix, the
snippet execution
[Lift] Re: Concurrent Web Service Requests?
lift is already a reserved prefix for snippets. So I'd stay with
simply lift prefix for these attributes as well.
Br's,
Marius
On Sep 29, 11:11 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
So what is your proposal? Am I interpreting you correctly that you are for a
prefix of 'lift'? And it will be a reserved suffix?
-
marius d.marius.dan...@gmail.com wrote:
I realize that I may be a little late here but I do have second
thoughts about liftx prefix. Yeah, I'm not a big fan of it. I
understand that these attributes are not really snippets or built is
snippets but is this an enough reason to introduce a new prefix?
Personally I don't think so. Historically lift reserved prefix names
were heavily debated and argued and this is a little sensitive area.
But the good news is that I may be the only one feeling this way about
this and everyone else likes it so I'm just a negligible minority.
Br's,
Marius
On Sep 25, 12:02 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Thu, Sep 24, 2009 at 11:33 AM, Naftoli Gugenheim
naftoli...@gmail.comwrote:
If you like the idea of having them all as attributes but don't like the
idea of using a single attribute ('xx:eager_eval=true
xx:parallel=true'
rather than 'xx:eval=eager parallel' as I suggested, where xx is the
prefix to be chosen) then maybe the prefix should be 'eval'.
I've changed the code to:
liftx:eager_eval=true
liftx:par=true | liftx:parallel=true
The reasons for not combining them:
- They are evaluated in different parts of the code, thus eager/parallel
doesn't make sense from a code path perspective
- I am reserving the value of liftx:par for future implementation to
allow farming the snippet evaluation to another mechanism. Right now,
it's
hard-coded to use LiftActors. I can see a time when it would work with
Akka
actors or some other parallelization mechanism
As far as ajax evaluation I'm not sure I'm understanding. Could you show
me what you're thinking?
If I have a snippet
lift:MySnippet /
what would be the syntax to have it inserted via ajax?
lift:Ajax !-- the snippet name will not be ajax, but you get the idea --
lift:MySnippet/
/lift:Ajax
-
Ross Mellgrendri...@gmail.com wrote:
My 2 cents,
I'm not sure I'm a fan of do: namespace, though I agree it would be
nice to have a common one. Maybe snippet:parallel, snippet:eager_eval?
-Ross
On Sep 24, 2009, at 12:46 PM, David Pollak wrote:
On Wed, Sep 23, 2009 at 11:43 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
What do you mean by as a normal snippet?
The parallel snippet processing is implemented deep inside
LiftSession. It's not a snippet. All the lift:xxx/ tags, even
those with defaults built into Lift, are implemented as snippets and
are invoked with normal snippet invocation mechanisms.
That you will nest your snippet inside a special snippet?
There is no special snippet. I used the word normal to highlight
that it's functionality that doesn't require a change to LiftSession
or other parts of Lift to function correctly.
To me it seems worthwhile to have a consistency between the two
syntax-wise, since they have some common denominator semantics-wise.
Actually, maybe throw in eager_eval to the mix. Maybe we could have
one eval or lift:eval or liftx:eval or whatever attribute, which can
contain a space separated list of specifiers--eager, ajax, parellel.
Anything that's prefixed with lift: is a snippet. I'm open to
unifying eager_eval and do:lazy (or do:par or do:parallel) into a
unified namespace.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Wed, Sep 23, 2009 at 10:40 AM, Naftoli Gugenheim
naftoli...@gmail.com
wrote:
A snippet attribute can be invoked with something other than
lift:snippet=Class.method? There's a short syntax? What is it?
There may be a short syntax (e.g., lift:Class.method) in the future.
What was used for the feature that inserts a snippet
asynchronously via
Ajax?
That feature isn't done yet, but that feature is likely to be done
as a
normal snippet.
My concern is that as more features are thought up and added they
shouldn't
all end up with different prefixes.
Also, if the prefix is nothing special I would go with the more
verbose
parallel because otherwise it's not obvious what it does. If
it's prefixed
with lift: at least you know it's a lift tag and you can look it
up
somewhere or ask on the list etc. But if you come back to some old
template
that says do:par you may be left clueless.
-
David Pollakfeeder.of.the.be...@gmail.com wrote:
On Wed, Sep
[Lift] Re: Tabbed browsing and session state
On Sep 27, 10:31 am, Naftoli Gugenheim naftoli...@gmail.com wrote: Do you mean multiple browser tabs? They won't interfere, because which stateful snippet is used in a given request depends on which is registered in that request which depends on which function is called which depends on which function id is in the request query parameters which depends on the link that was clicked which is generated by the stateful snippet :) But if one page must link to several pages each with a pre-instantiated snippet you must use mapSnippet. Marius, did David work on lift-wizard since the last time he said he doesn't know when he will find time? Also, how would he approach his goal using lift-wizard? Dunno. I pointed to lift-wizard mostly for looking to the code and see if the concept fits tiro's needs. - marius d.marius.dan...@gmail.com wrote: Tiro, Please see the lift-wizard project. Br's, Marius On Sep 27, 1:33 am, tiro tim.romb...@googlemail.com wrote: Naftoli, thanks for providing these insights into the inner workings of Stateful Snippets. The mapSnippet solution sounds interesting. I knew that snippets don't live on when not needed, but assumed that IF one is alive in the current session, you would always get that one instance. Hence at most one instance would be alive per snippet class and per session. What you seem to indicate is that the lifecycle is held together by redirects and such (and therefore page ids) rather than two requests being in the same session. I will experiment how that works with tabs. I guess one has to still be very careful since the user may go from the view initiating a snippet and open several tabs from there, whereafter you could still get unwanted interference between the tabs if you don't pay attention. Marius, thanks for your pointsWizard code exciting.. since the wizardiness probably won't jump into my eye, if you happen to stumble on it in the next few days, could you perhaps post a classname here? That data needs to be preserved into a RequestVar, That is precisely what I meant by passing state on from a response to the next request :-) RequestVars are benign. AJAX Tabs Had briefly thought of that. Makes good sense with some types of apps. In this particular app I've already made other compromises to preserve standard behavior and let the user bookmark the current URL etc. Bookmarking URL's would make you loose state unless you preserve that state in the URL itself. But you're fully aware of this. Actually things would already be much simpler if browsers allowed you to address tabs by Javascript (close current tab, jump to search results tab). One could then keep the results list open in a user- friendly way. But apparently browsers have been getting quite restrictive on that, for obvious reasons. --~--~-~--~~~---~--~~ 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: RFC: Restructuring Lift Codebase
Generally I like this structure.Please see my other comments below: On Sep 27, 3:44 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote: Folks, As followup to the proposed goal of Keeping lift-core neat and small, here is the first iteration of the revised structure of Lift codebase. liftweb - lift-core [10] - lift-base [02] - lift-actor - lift-util - lift-json [03] - lift-webkit [04] - lift-testkit [05] - lift-persistence [06] - lift-mapper - lift-record - lift-jpa - lift-modules [07] - lift-osgi - lift-wizard [08] - lift-widgets [09] - lift-machine - lift-textile - lift-facebook - lift-amqp - lift-xmpp - lift-openid - lift-oauth - lift-paypal - lift-jta - lift-archetypes - ... - lift-examples - ... - lift-site [10] - lift-resources [lift-varia, lift-infra ?] [11] - lift-root-model [12] - lift-site-skin - lift-installer - misc config resources (scaladoc, javadoc etc.) General notes (including some obvious ones): [A] lift-* prefix looks superfluous, but it's best to have one for all artifacts that generate jar (packagingjar/packaging). Also Maven reactor feels happier when artifactId == directory_name (site generation, scm extrapolation etc., situation might have improved now). [B] The top level project categories (lift-core, lift-persistence, lift-modules etc.) are simple multi-module models at the moment and not meant to create anything other than pom. Therefore, lift-* prefix can go away. But they'll have to come back if we plan to generate 'one jar' in assembly mode per category (lift-core-all.jar, lift- persistence-all.jar etc.). This could be useful for 'get me everything, I don't care about size' people. But is it necessary? The alternative is to have empty 'meta modules' that pull up the necessary dependencies and can be included by the users in their project (quite similar to what lift-core does now). [C] The members in a project category (lift-mapper, lift-record etc.) would inherit the category model (lift-persistence in case of lift- mapper, lift-record). Related modules clubbed together helps similar configuration pulled up to the parent pom (improves DRY-ness). Added benefit: modules can be developed even outside Lift codebase with the given parent pom (available in global repo) and the developer won't have to worry about most of the infra related boilerplate configurations (couple of config still would need change though). [D] Presentations and other materials aren't really source code for inclusion in source repository. Can this go in wiki? (immediate problem: github doesn't take attachment). Has this been discussed earlier? They can go as a separate github project too. [E] The categorization is mostly based on my interpretation as a late entrant. If there is a different structure that fits the philosophy better (quite likely), this would get regrouped. (Tim ?) [F] The modules in a category can be further sub-grouped, but with caution. Basically, need the right mix between 'flat'-ness and deep nesting. Thoughts on this? [G] Each category can eventually be split up into separate projects and have their own release schedules (less frequent for core, more frequent for modules etc.). This might be little overkill at the moment. Just mentioned to enable us mind the long term perspective :) [H] Other points on the draft hierarchy (see the # in brackets above): [01] With these members, if lift-core doesn't sound as the right name, we need the right name. Provided the grouping is right that is. [02] Base interfaces for Lift (currently present in dpp_wip_actorized) I'm not sure about base interfaces for lift ... [03] Doesn't really have to be part of Lift core in current form, but this is eventually meant to be part of Lift's JS infrastructure (thus kept here at the moment) JSON should not only be part of JS stack as it is used in many contexts for REST API's. So I'd keep it in the core, [04] Candidate for decomposition. But kept intact at the moment. Would be taken up in next pass once the top level reaches steady state. This could either become a category of its own or a module with submodules. Why splitting it up? .. .the webkit if the very core of lift. [05] Little unsure about it's intent and purpose, I could be completely mis-interpreting this. Thoughts from somebody with more understanding please :) [06] Doesn't have to be part of lift-core. Lift applications not using persistence doesn't have to need this. I definitely agree. [07] Extra stuff, necessary iff one needs. Right now, I am putting 'everything else' here for lack of better place, but I see a scaling up issue there. This can turn out to be a place for all the 'nowhere else to go' modules. But we can take it up in next pass. Suggestions? [08][09] See #04 above. Can be subpackage of lift-webkit eventually I would definitely keep them separated
[Lift] Re: Tabbed browsing and session state
On Sep 26, 10:38 am, tiro tim.romb...@googlemail.com wrote: Hi, has anyone investigated or built a way to support tabbed browsing when there is considerable view/workflow state? Or have I missed an elegant way for this to be done in Lift? There is a rather recent wizard code in lift that Dave added (and I haven't looked on it yet :) ... ) that could potentially apply here? If I am not mistaken, Lift currently supports 1. Sending continuations (things that will need to be done) from one Request to the next in the form of FuncHolders that are attached to an ID that is unique for a sent page. This works perfectly in a tabbed environment, and you can send state this way, but the state doesn't live on in the response sent by the snippet that has received it. No your function that is called upon a request, receives the data. That data needs to be preserved into a RequestVar, SessionVar or into a StatefulSnippet so that when rendering phase starts that value is visible by the snippet itself. Function ID-s are generated for each page rendering. This is important for security reasons. 2. Session variables that are global to the session, as well as 3. Stateful snippets that are instantiated at most once in each session. Not necessarily. You can preserve a StatefulSnippet's reference if you're using the functions exposed by it such as link or redirectTo. Also using a StatefulSnippet as a form preserves its reference. Otherwise the StatefulSnippet reference is not kept in LiftSession. When assuming that your user knows how to browse tabbed, I can currently not imagine what 2. and 3. could be practically useful for. Very often though, it seems, people use these mechanisms and then later realize the mess they are in. E.g. (quite funny)http://www.highdots.com/forums/javascript/browser-tab-269390.html More serious:http://www.codeodor.com/index.cfm/2007/7/19/Why-tabbed-browsing-makes... A simple example from an application I'm developing, and I'll bet more than half of all Web apps, is this: I have one page where users can search for a bunch of documents in a database (search form and result list are on the same page - let's not make it too complicated). Clicking on a result will navigate to the detail view of a document. I am sure sooner or later the customer will want a link on the detail view to go back to the search he came from. If I put the last search parameters used into Session Vars, this will not work if the customer uses several such result lists in parallel (not unrealistic in this case). He will always end up going back to the last search used, not the one that was used to open the detail view. Very bad behavior for example when the user has edited an item, and it then vanishes from his view. What would work is: put the search parameters into hidden fields and/ or URL parameters of the detail view. But you break your fingers doing that and it gets really messy when the detail view can be opened from several different context, and the conversation that takes you back to the original context has several steps. There is also a limit to what you can put into a URL, I believe. You use a framework because it saves you these kinds of headaches. It seems to me, Lift already has 80% of what it takes for a great solution. It is the mechanism mentioned under 1. Any tab that is still open calls home regularly to say I'm still here, don't forget me. Depends how you are building your tabs. If your tab is a totally different page than the state should be preserved on the server and the dedicated place is a SessionVar. But you could build your tabs as being part of the same page, hence changing the tabs becomes a matter of making divs visible/hidden and this implies not server hits. Just JavaScript. This will allow you to navigate from one tab to another pretty fast = a better user experience. This is good because otherwise we would have to consider any page ever sent to the client to still be open and come back to haunt us, demanding us to behave as if nothing had happened since. The existing mechanism would only need to allow the state to be passed on, with a delta, to the next response-request episode. --~--~-~--~~~---~--~~ 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: Canceling a ActorPing.scheduleAtFixedRate task
So why not keep the method for the Lift-Actors branch? ... because
there is no concept of linking actors there?
Br's,
Marius
On Sep 24, 6:52 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
I strongly recommend against using scheduleAtFixedRate because:
- Internally, it creates an actor that's linked to your actor and that
leads one of the Scala Actor memory problems
- The turning off issue that you've identified
- On the Scala-Actor-free branch of Lift, I've removed the method.
Instead, I'd suggest scheduling a new actorping each time you receive one.
On Wed, Sep 23, 2009 at 2:17 PM, Xavi Ramirez xavi@gmail.com wrote:
I think I figured out a way to get around this:
class SomeCometActor extends CometActor {
private var tempActor: Actor = null
override def localSetup() {
val cometActor = this
var tempActor = actor{ loop { react {
case TaskMessage = cometActor ! TaskMessage
case UnSchedule = exit
} } }
ActorPing.scheduleAtFixedRate(tempActor, TaskMessage, 15 seconds,
15 seconds)
}
override def lowPriority = {
case TaskMessage =
DoSomething()
if(someCondition) { tempActor ! UnSchedule }
}
}
Instead of registering the comet actors for the scheduled task, I
register a temporary actor. During its execution, scheduleAtFixedRate
creates an actor. Let's call this the Scheduled Task Actor. The
scheduled task actor is then linked(see
http://www.scala-lang.org/docu/files/api/scala/actors/Actor.html#link...
)
to the temporary actor i passed in. So now, when I need to stop the
scheduled task actor, I can shutdown the temporary actor. This works
because when an actor is shutdown, all actors it's linked to are shut
down as well.
This is kinda nuts, but I guess it works.
I'm just sharing in case someone else runs into this problem.
Thanks,
Xavi
On Wed, Sep 23, 2009 at 4:13 PM, Xavi Ramirez xavi@gmail.com wrote:
There isn't much to show... but maybe an example clarify things.
class SomeCometActor extends CometActor {
override def localSetup() {
ActorPing.scheduleAtFixedRate(this, TaskMessage, 15 seconds, 15
seconds)
}
override def lowPriority = {
case TaskMessage =
DoSomething()
if(someCondition) { /* stop the scheduled task... What do I put
here?*/ }
}
}
If scheduleAtFixedRate returned either the Future or the Actor it
creates, then stopping the scheduled task would be fairly straight
forward. Then again, I might be missing something.
Thanks,
Xavi
On Wed, Sep 23, 2009 at 3:54 PM, Timothy Perrett
timo...@getintheloop.eu wrote:
Xavi,
Can you show some code? There might be a way of doing it depending
what you have...
Cheers, Tim
Sent from my iPhone
On 23 Sep 2009, at 20:50, Xavi Ramirez xavi@gmail.com wrote:
Hello,
Is there any way to cancel a task created with a
ActorPing.scheduleAtFixedRate?
From looking at the source
(
http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/ActorPi...
)
it seem that scheduleAtFixedRate creates an actor which accepts an
UnSchedule message. Unfortunately this actor is not returned to the
caller.
Thanks in advance,
Xavi
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--~--~-~--~~~---~--~~
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: Canceling a ActorPing.scheduleAtFixedRate task
Hi,
When you call scheduleAtFixedRate that actor is sending your actor a
Scheduled message, hence you can capture the correct sender. You don't
need to create a different actor.
David's points are quite valid regarding the correct Scala actors'
state.
Br's,
Marius
On Sep 23, 4:17 pm, Xavi Ramirez xavi@gmail.com wrote:
I think I figured out a way to get around this:
class SomeCometActor extends CometActor {
private var tempActor: Actor = null
override def localSetup() {
val cometActor = this
var tempActor = actor{ loop { react {
case TaskMessage = cometActor ! TaskMessage
case UnSchedule = exit
} } }
ActorPing.scheduleAtFixedRate(tempActor, TaskMessage, 15 seconds,
15 seconds)
}
override def lowPriority = {
case TaskMessage =
DoSomething()
if(someCondition) { tempActor ! UnSchedule }
}
}
Instead of registering the comet actors for the scheduled task, I
register a temporary actor. During its execution, scheduleAtFixedRate
creates an actor. Let's call this the Scheduled Task Actor. The
scheduled task actor is then
linked(seehttp://www.scala-lang.org/docu/files/api/scala/actors/Actor.html#link...)
to the temporary actor i passed in. So now, when I need to stop the
scheduled task actor, I can shutdown the temporary actor. This works
because when an actor is shutdown, all actors it's linked to are shut
down as well.
This is kinda nuts, but I guess it works.
I'm just sharing in case someone else runs into this problem.
Thanks,
Xavi
On Wed, Sep 23, 2009 at 4:13 PM, Xavi Ramirez xavi@gmail.com wrote:
There isn't much to show... but maybe an example clarify things.
class SomeCometActor extends CometActor {
override def localSetup() {
ActorPing.scheduleAtFixedRate(this, TaskMessage, 15 seconds, 15 seconds)
}
override def lowPriority = {
case TaskMessage =
DoSomething()
if(someCondition) { /* stop the scheduled task... What do I put
here?*/ }
}
}
If scheduleAtFixedRate returned either the Future or the Actor it
creates, then stopping the scheduled task would be fairly straight
forward. Then again, I might be missing something.
Thanks,
Xavi
On Wed, Sep 23, 2009 at 3:54 PM, Timothy Perrett
timo...@getintheloop.eu wrote:
Xavi,
Can you show some code? There might be a way of doing it depending
what you have...
Cheers, Tim
Sent from my iPhone
On 23 Sep 2009, at 20:50, Xavi Ramirez xavi@gmail.com wrote:
Hello,
Is there any way to cancel a task created with a
ActorPing.scheduleAtFixedRate?
From looking at the source
(http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/util/ActorPi...
)
it seem that scheduleAtFixedRate creates an actor which accepts an
UnSchedule message. Unfortunately this actor is not returned to the
caller.
Thanks in advance,
Xavi
--~--~-~--~~~---~--~~
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: SessionVar.remove() not clearing out the variable
On Sep 22, 10:50 pm, Dano olearydani...@gmail.com wrote:
Marius,
Thanks for your reply. If I look in my pom.xml, I see that I am using
1.1-SNAPSHOT. However, I see your point about the remove() function
not being in Vars.scala. Not sure why I am able to compile a call to
remove() on a SessionVar - but it does!
I'm not aware of any Lift implicits to expose remove function ...
My goal is to clear out the SessionVar for all sessions tied to the
variable so that I can return the Session to the state it was at the
beginning of time (at least with respect to the SessionVars).
I have an object contained within a LiftView class called
PartyLobbyUser:
class GameView extends LiftView {
object PartyLobbyUser extends SessionVar[Box[UserInfo]](Empty)
...
}
This object is set in code called by the GameView.dispatch() function
and then referenced later by some comet actors. I think the problem I
am having is that since a SessionVar is essentially a thread local
variable, I need to clear it (i.e. do something like PartyLobbyUser
(Empty) ) in the right place.
SessionVar is not a ThreadLocal, RequestVar is. SessionVar just sits
on top of LiftSession, and no you don't need to clear it except when
you want to remove things from the session. You also don't need to
clear RequestVar-s as it is done automatically by lift.
If you can put a minimalistic Lift project where you replicate the
problem I'll look on it this weekend.
Perhaps the right context is to do this in the shutdown function of
the comet actors since they are able to reference the variable and get
the correct data (ie. via PartyLobbyUser.is). I will try that and
report back.
Thanks again for your help.
Dan
On Sep 22, 7:03 pm, marius d. marius.dan...@gmail.com wrote:
On Sep 22, 8:13 pm, Dano olearydani...@gmail.com wrote:
Hello Lifters,
I am struggling with trying to clear out a SessionVar which holds user
information which I need to clear out after the user has left a
'lobby' page.
When I call the remove() function, I verify that the SessionVar is
Empty. However, when I click on the URL for the lobby page with new
parameters, the SessionVar retains the old values for each session.
It is as if they were repopulated.
Perhaps I am not understanding out the function works. When I look at
the source code (Vars.scala), it seems like it is clearing out the
state for each session. The remove() function calls clearFunc().
override protected def clearFunc(name: String): Unit =
S.session.foreach(_.unset(name))
No not for each session. S.session returns a Box which has a foreach
function, it does not iterate through all sessions.
Which Lift version are you using? .. there is no remove function in
Vars in 1.1-SNAPSHOT version.
Can you post some code to show where you are setting values on your
SessionVar and where are you deleting them?
Is there something I am missing?
Thanks in advance.
Dan
--~--~-~--~~~---~--~~
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: access to raw HttpServletRequest/Response
I really don't think Lift should expose directly expose servlet references. Applications still have access to servlet stuff by explicit casting. You can do it today like this: S.containerRequest.map(r = (r.asInstanceOf[HTTPRequestServlet]).req) Br's, Marius On Sep 22, 3:53 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Please open a ticket for this one as well. I'll expose it for you. On Tue, Sep 22, 2009 at 1:07 PM, harryh har...@gmail.com wrote: Is it still possible to get access to the raw HttpServletRequest/ Response objects? I know you could at least do this for Request from S, but now I'm not seeing it anymore. Looking to get this so I can use http://mrepo.happyfern.com/sites/facebook-java-api/facebook-java-api/... (I've found getting off the ground with lift-facebooksomewhat confusing). -harryh -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Surf the harmonics --~--~-~--~~~---~--~~ 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: SessionVar.remove() not clearing out the variable
On Sep 22, 8:13 pm, Dano olearydani...@gmail.com wrote: Hello Lifters, I am struggling with trying to clear out a SessionVar which holds user information which I need to clear out after the user has left a 'lobby' page. When I call the remove() function, I verify that the SessionVar is Empty. However, when I click on the URL for the lobby page with new parameters, the SessionVar retains the old values for each session. It is as if they were repopulated. Perhaps I am not understanding out the function works. When I look at the source code (Vars.scala), it seems like it is clearing out the state for each session. The remove() function calls clearFunc(). override protected def clearFunc(name: String): Unit = S.session.foreach(_.unset(name)) No not for each session. S.session returns a Box which has a foreach function, it does not iterate through all sessions. Which Lift version are you using? .. there is no remove function in Vars in 1.1-SNAPSHOT version. Can you post some code to show where you are setting values on your SessionVar and where are you deleting them? Is there something I am missing? Thanks in advance. Dan --~--~-~--~~~---~--~~ 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: javascript disabled on mobile phone browsers
Yes .. you can use lift with zero javascript. But obviously you won't have comet, you need to turn off auto Ajax and comet generation from LiftRules LiftRules.enableLiftGC = false; Liftules.autoIncludeComet = session = false Liftules.autoIncludeAjax = session = false Br's, Marius On Sep 20, 6:18 am, koveen liep...@xs4all.nl wrote: Hi, I am new to this lift group and just starting to build a website for mobile phone users. While I like to use dynamically loaded pages, I am afraid that some older mobile phone browsers don't support Javascript. Is there a way to include Javascript in my web-pages, but to keep a working site is Javascript is not supported? Thanks, Ko --~--~-~--~~~---~--~~ 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: all page URLs appended with ;jsessionid=knq01t90ajh7
I just committed the fix.
Box[String = String] is calling URLRewriter which holds the function
that does URL manipulation. This is set in HTTP Provider. It does 2
things:
- calls encodeURL
- calls URLDecorator
URLDecorator is important in case one wants to add something to all
URL's. For instance in case of sticky sessions, load balancers need to
know where to balance a request and this is done by various policies:
- JSESSIONID affinity
- URI based balancing (here URLDecorator makes a lot of sense as load
balancers can determine where to balance requests based on a query
string parameter)
Other notes about your comments
When a client (browser) connects, the servlet container doesn't know
if cookies are enabled. It sets a session cookie on the response, and
also rewrites path URLs to include ;jsessionid=yourSessionId. -
Server does not rewrite URLs if container's cookies are turned ON.
This decision is done by the container and not Lift. So you either
have JSESSIONID as a cookie or as part of the URL aka URL rewriting.
Br's,
Marius
On Sep 19, 12:09 am, Grant Wood smackt...@gmail.com wrote:
Atsuhiko's experience makes sense if you look in Req.
_fixHref is where the rewriting is actually happening:
--- Req ...
private def _fixHref(contextPath: String, v : Seq[Node], fixURL:
Boolean, rewrite: Box[String = String]): Text = {
val hv = v.text
val updated = if (hv.startsWith(/)) contextPath + hv else hv
Text(if (fixURL rewrite.isDefined
!updated.startsWith(mailto:;)
!updated.startsWith(javascript:)
!updated.startsWith(http://;)
!updated.startsWith(https://;))
rewrite.open_!.apply(updated) else updated)
}
... Req ---
Lift is skipping the rewrite if the attribute startsWith
(javascript:) but if it starts with # it will be rewritten.
This would be an easy fix: !updated.startsWith(#)
I suspect this change would meet most developers behavior
expectations.
If a client is not using cookies and requires :jsessionid=theSessionId
to be appended, this test will also fail to properly rewrite fully
qualified URLs with the http or https protocol that have the same
hostname (S.hostName) as the authority section. Someone with a better
handle on the Servlet and Servlet Container spec will have to chime in
and determine whether there are rules governing this situation.
Does anybody know if rewrite: Box[String = String] being used by
anything other than the jsessionid rewrite?
- Grant
On Sep 18, 9:46 pm, marius d. marius.dan...@gmail.com wrote:
LIft doesn't explicitly add jsessionid to the URL but it calls
encodeUrl on the HttpServletResponse. If in the container you have the
cookies turned off URL rewrite comes into picture. This is because we
need lift apps to still work when cookies are turned off from
container. This is the correct behavior.
Your specific example sounds like a bug and I'll try to fix it
tomorrow.
Br's,
Marius
On Sep 18, 7:04 pm, Atsuhiko Yamanaka atsuhiko.yaman...@gmail.com
wrote:
Hi,
On Sat, Sep 19, 2009 at 4:43 AM, David Pollak
feeder.of.the.be...@gmail.com wrote:
Is this causing a problem? If it is, you can disable it... I forgot
how,
but I can dig through the code to find out the appropriate LiftRules to
change.
I had troubles.
For example,
a href=# onlick=...click/a
was suddenly transformed to
a href=;jsessionid=knq01t90ajh7# onlick=...click/a
and the page reload was happened unexpectedly.
Now, I have rewritten those anchor tags as
a href=javascript:void(0) onclick=...click/a
and such troubles have disappeared. So, it is not a problem for me
anymore.
This is just FYI.
Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Skype callto://jcraft/
--~--~-~--~~~---~--~~
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: CometActor timeout problem
On Sep 17, 11:09 pm, jack jack.wid...@gmail.com wrote: I have a CometActor which displays a list of urls and at the same time launches a bunch of threads each of which gets information about the urls and then puts messages about that information in a Queue. On each new tick, the CometActor checks the queue and updates its urls. The problem is that I am launching the threads from the CometActor and the page is never coming back. It times out. So the page never gets rendered? I would recommend using actors and not really threads but even with threads it shouldn't impact you. But it also depends on what your code does. Can you post a minimalistic example? Is there some general principle about launching threads from a CometActor that might explain this behavior? --~--~-~--~~~---~--~~ 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: all page URLs appended with ;jsessionid=knq01t90ajh7
Turning ON cookies in container will disable URL rewriting. jsessionid will become a cookie. Br's, Marius On Sep 18, 2:43 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Fri, Sep 18, 2009 at 12:15 PM, Chris Lewis burningodzi...@gmail.comwrote: It has nothing to do with lift, but the servlet container. jsessionid is a specified standard, and appending it I *think* is part of the mandate when implementing the servlet api. That is to say, the automatic appending will probably occur on any servlet container. Google around and you'll find various ways people deal with it. Lift is inserting these are part of the URL rewriting at the request of the container. Is this causing a problem? If it is, you can disable it... I forgot how, but I can dig through the code to find out the appropriate LiftRules to change. Grant Wood wrote: The first time a browser visits my site, all the path-only URLs embedded in the requested page are being appended with what looks like a malformed query parameter containing the session id. for example: a href=/correct/path/ link/a is being rewritten: a href=/correct/path/;jsessionid=knq01t90ajh7 link/a What's odd is that it is also happening to img elements as well: img src=/s/images/site/light_blue.png / is being rewritten: img src=/s/images/site/light_blue.png;jsessionid=knq01t90ajh7 / This happens reliably if you clear the cache and all session data from your browser and visit any page in the site first. ANy subsequent pages are fine. The result is that links work fine (which is why I didn't notice the problem right away) but images and embedded media are broken. If you reload the page, the URLs are all fine. The ;jsessionid=session id Other facts: - It is NOT affecting URLs in CSS or js in external files. - It is NOT being added to URLs with a protocol and authority such as: http://www.foo.com/path/to/page (and it makes no difference if its an external link or not) - I first suspected that a script somewhere was doing this, however, disabling javascript in the browser causes no change. I verified this using curl.. the URLs are being altered on the server. - I'm on the latest 1.1-SNAPSHOT, but this has been happening for some time, possibly since I started my work on lift 6 weeks ago. I have been searching through lift code for jsessionid without luck, so hopefully David or someone knows exactly what part of the chain is causing this. Its certainly possible I'm doing this somehow, but I can find nothing that would come close to doing this in any of my snippets (or models or libs for that matter) Thanks for any insight, let me know what other information would be helpful. -- 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: Welcome Indrajit Raychaudhuri to the Lift Committers
Outstanding! Welcome aboard! Br's, Marius On Sep 18, 7:00 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, Please join me in welcoming Indrajit Raychaudhuri to the Lift committers. Indrajit has been very visible on the Lift list of late, offering lots of good solutions to people's questions. He's got some ideas of improving the Lift Maven infrastructure and build process and will be contributing to the build side (and may substantive code side) of Lift. Thanks, David -- 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: Where's LiftFilter connected in with LiftServlet?
LiftFilter is indeed only extending ServletFilterProvider which is
oriented obviously for JEE servlet filter processing (we do this for
backward compatibility reasons). ServletFilterProvider is also
extending HTTPProvider which knows about LiftServlet.
ServletFilterProvider just calls the service function and from here
the LiftServlet gets called. HTTPProvider trait has no knowledge about
servlets API, neither LiftServlet which is not a real JEE servlet.
Br's,
Marius
On Sep 18, 7:03 pm, Meredith Gregory lgreg.mered...@gmail.com wrote:
Dear Lifted,
bash-3.2$ cd liftweb/
bash-3.2$ ls
builtin http sitemap
bash-3.2$ find . -name *.scala -exec grep LiftFilter '{}' \; -print
class LiftFilter extends ServletFilterProvider
./http/LiftServlet.scala
* @see LiftFilter
./http/S.scala
bash-3.2$
The web.xml file references LiftFilter. The class LiftFilter extends the
Java class ServletFilterProvider and has no body. It looks like all the
logic is in LiftServlet. What makes the connection?
Best wishes,
--greg
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117
+1 206.650.3740
http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
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: all page URLs appended with ;jsessionid=knq01t90ajh7
LIft doesn't explicitly add jsessionid to the URL but it calls encodeUrl on the HttpServletResponse. If in the container you have the cookies turned off URL rewrite comes into picture. This is because we need lift apps to still work when cookies are turned off from container. This is the correct behavior. Your specific example sounds like a bug and I'll try to fix it tomorrow. Br's, Marius On Sep 18, 7:04 pm, Atsuhiko Yamanaka atsuhiko.yaman...@gmail.com wrote: Hi, On Sat, Sep 19, 2009 at 4:43 AM, David Pollak feeder.of.the.be...@gmail.com wrote: Is this causing a problem? If it is, you can disable it... I forgot how, but I can dig through the code to find out the appropriate LiftRules to change. I had troubles. For example, a href=# onlick=...click/a was suddenly transformed to a href=;jsessionid=knq01t90ajh7# onlick=...click/a and the page reload was happened unexpectedly. Now, I have rewritten those anchor tags as a href=javascript:void(0) onclick=...click/a and such troubles have disappeared. So, it is not a problem for me anymore. This is just FYI. Sincerely, -- Atsuhiko Yamanaka JCraft,Inc. 1-14-20 HONCHO AOBA-KU, SENDAI, MIYAGI 980-0014 Japan. Tel +81-22-723-2150 +1-415-578-3454 Skype callto://jcraft/ --~--~-~--~~~---~--~~ 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: Tabs + menu builder
It would be pretty easy to write your own snippet and get inspired from Lift's menu snippet code.THe Menu snippet produces lists (ul/li) and if your JQuery Tab plugin works with HTML lists it should work almost on the fly? Br's, Marius On Sep 17, 4:05 pm, caw1461 caw1...@gmail.com wrote: I'm working on a UI for a project and we are looking at the jquery tabs. Currently we just have a plain menu builder site map. we are thinking that a good way to create our UI is to somehow link the site builder with the Tabs such that each tab holds a different link from the site map. I know this is slightly vague, but any advice for a new to lift and scala and HTML/XML. Thanks in advance --~--~-~--~~~---~--~~ 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: Breaking changes in CometActor code vs. continuing instabilities in Scala Actors
What is the problem this time? .. same thing essentially? Br's, Marius On Sep 16, 8:14 am, David Pollak feeder.of.the.be...@gmail.com wrote: Guys, The Scala Actor issue has raised its head again. From November 2008 - June 2009, I did an epic battle with Scala actors and their memory retention issues. I finally wrote a Lift Actor library that made all the Scala Actor-related issues go away for the short-lived Actors that Lift uses as listeners for comet long-polling. It seems that the Actor issue is not gone. I'm not sure it will be gone in Scala 2.8. I can make a change in Lift to move to Lift Actors in CometActor code. It means that if you're using Scala Actors beyond !, !! and !? methods, you will have to change your code, otherwise it will just be a recompile. What do people think? Thanks, David -- 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: JSON forms problem
Maybe this would help ? http://wiki.liftweb.net/index.php/HowTo_use_JSON_forms This definitely worked but I haven't tested in a while. Also the lift book example was tested before putting it in the book. If there is indeed a lift problem I'd be happy to correct it ASAP. Br's, Marius On Sep 15, 1:59 pm, Derek Chen-Becker dchenbec...@gmail.com wrote: The apply method should be getting called because the SHtml.json method should register it as the handler for the form. Would you mind sending me the code you have and I'll take a look at it? I'm pretty sure this code was working at one point, but perhaps something has changed. Derek On Mon, Sep 14, 2009 at 2:03 PM, glenn gl...@exmbly.com wrote: Actually, the JsonHandler in the example gets called, but not the apply (in:Any) method, as that is never called in the book example. Also, the handler seems to be called twice with every submit. Why is that? Glenn On Sep 14, 8:08 am, glenn gl...@exmbly.com wrote: This may be a question for the Lift Book forum, but has anyone gotten the JSON forms example 8.13 in the Lift Book to work? When I tried it, the JsonHandler in class JSONForm never gets called when the submit button is clicked. Glenn --~--~-~--~~~---~--~~ 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: JSON forms problem
Do you see any errors in FireBug ? ... Do see the Ajax request being
send out in FireBug?
On Sep 15, 5:49 pm, glenn gl...@exmbly.com wrote:
Derek,
Here is the template. Just as in the book.
lift:surround with=default at=content
lift:JSONForm.head /
lift:JSONForm.show
input type=text name=name /
br /
input type=text name=value /
br /
input type=radio name=vehicle value=Bike /
input type=radio name=vehicle value=Car /
input type=radio name=vehicle value=Airplane /
br /
select name=cars
option value=volvoVolvo/option
option value=saabSaab/option
option value=opelOpel/option
option value=audiAudi/option
/select
button type=submitSubmit/button
/lift:JSONForm.show
div id=json_result/div
/lift:surround
And here is my JSONForm class:
class JSONForm {
def head = head{Script(json.jsCmd)}/head
def show(html: Group): NodeSeq = {
json.jsCmd
SHtml.jsonForm(json, html)
}
object json extends JsonHandler {
def apply(in: Any): JsCmd =
SetHtml(json_result, Text(This is a test))
}
}
Here, I just simplified the JsCmd returned from the handler.
I understand that in the head method, the call to json.jsCmd creates
the ajax handler (from the apply method), but clicking on the submit
button on the form doesn't populate the json_result div. In fact,
it doesn't do anything even though, on the page source, the button's
onclick method is
wired up.
Glenn
On Sep 15, 11:59 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
The apply method should be getting called because the SHtml.json method
should register it as the handler for the form. Would you mind sending me
the code you have and I'll take a look at it? I'm pretty sure this code was
working at one point, but perhaps something has changed.
Derek
On Mon, Sep 14, 2009 at 2:03 PM, glenn gl...@exmbly.com wrote:
Actually, the JsonHandler in the example gets called, but not the apply
(in:Any) method, as
that is never called in the book example. Also, the handler seems to
be called twice with every submit.
Why is that?
Glenn
On Sep 14, 8:08 am, glenn gl...@exmbly.com wrote:
This may be a question for the Lift Book forum, but has anyone gotten
the JSON forms example 8.13 in the Lift Book to work? When I tried
it, the JsonHandler in class JSONForm never gets called when the
submit button is clicked.
Glenn
--~--~-~--~~~---~--~~
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: JSON forms problem
Where is the head function in your code ?
Here is an example:
def head = headscript type=text/javascript src=/classpath/
jlift.js / {Script(json.jsCmd)}/head
Br's,
Marius
On Sep 15, 5:55 pm, marius d. marius.dan...@gmail.com wrote:
Do you see any errors in FireBug ? ... Do see the Ajax request being
send out in FireBug?
On Sep 15, 5:49 pm, glenn gl...@exmbly.com wrote:
Derek,
Here is the template. Just as in the book.
lift:surround with=default at=content
lift:JSONForm.head /
lift:JSONForm.show
input type=text name=name /
br /
input type=text name=value /
br /
input type=radio name=vehicle value=Bike /
input type=radio name=vehicle value=Car /
input type=radio name=vehicle value=Airplane /
br /
select name=cars
option value=volvoVolvo/option
option value=saabSaab/option
option value=opelOpel/option
option value=audiAudi/option
/select
button type=submitSubmit/button
/lift:JSONForm.show
div id=json_result/div
/lift:surround
And here is my JSONForm class:
class JSONForm {
def head = head{Script(json.jsCmd)}/head
def show(html: Group): NodeSeq = {
json.jsCmd
SHtml.jsonForm(json, html)
}
object json extends JsonHandler {
def apply(in: Any): JsCmd =
SetHtml(json_result, Text(This is a test))
}
}
Here, I just simplified the JsCmd returned from the handler.
I understand that in the head method, the call to json.jsCmd creates
the ajax handler (from the apply method), but clicking on the submit
button on the form doesn't populate the json_result div. In fact,
it doesn't do anything even though, on the page source, the button's
onclick method is
wired up.
Glenn
On Sep 15, 11:59 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
The apply method should be getting called because the SHtml.json method
should register it as the handler for the form. Would you mind sending me
the code you have and I'll take a look at it? I'm pretty sure this code
was
working at one point, but perhaps something has changed.
Derek
On Mon, Sep 14, 2009 at 2:03 PM, glenn gl...@exmbly.com wrote:
Actually, the JsonHandler in the example gets called, but not the apply
(in:Any) method, as
that is never called in the book example. Also, the handler seems to
be called twice with every submit.
Why is that?
Glenn
On Sep 14, 8:08 am, glenn gl...@exmbly.com wrote:
This may be a question for the Lift Book forum, but has anyone gotten
the JSON forms example 8.13 in the Lift Book to work? When I tried
it, the JsonHandler in class JSONForm never gets called when the
submit button is clicked.
Glenn
--~--~-~--~~~---~--~~
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: JSON forms problem
Right ... the head method should not have the js script but did you
include the jlift.js script in your default template?
I'll build an example this week (when I'll find some time for it) and
see if I'm running into the same problems as you are. If you somehow
manage to fix it please let me know. How urgent is this for you?
Br's,
Marius
On Sep 15, 6:15 pm, glenn gl...@exmbly.com wrote:
But, the head method does add the javascript to the page, so no src
attribute is needed, right?
On Sep 15, 3:59 pm, marius d. marius.dan...@gmail.com wrote:
Where is the head function in your code ?
Here is an example:
def head = headscript type=text/javascript src=/classpath/
jlift.js / {Script(json.jsCmd)}/head
Br's,
Marius
On Sep 15, 5:55 pm, marius d. marius.dan...@gmail.com wrote:
Do you see any errors in FireBug ? ... Do see the Ajax request being
send out in FireBug?
On Sep 15, 5:49 pm, glenn gl...@exmbly.com wrote:
Derek,
Here is the template. Just as in the book.
lift:surround with=default at=content
lift:JSONForm.head /
lift:JSONForm.show
input type=text name=name /
br /
input type=text name=value /
br /
input type=radio name=vehicle value=Bike /
input type=radio name=vehicle value=Car /
input type=radio name=vehicle value=Airplane /
br /
select name=cars
option value=volvoVolvo/option
option value=saabSaab/option
option value=opelOpel/option
option value=audiAudi/option
/select
button type=submitSubmit/button
/lift:JSONForm.show
div id=json_result/div
/lift:surround
And here is my JSONForm class:
class JSONForm {
def head = head{Script(json.jsCmd)}/head
def show(html: Group): NodeSeq = {
json.jsCmd
SHtml.jsonForm(json, html)
}
object json extends JsonHandler {
def apply(in: Any): JsCmd =
SetHtml(json_result, Text(This is a test))
}
}
Here, I just simplified the JsCmd returned from the handler.
I understand that in the head method, the call to json.jsCmd creates
the ajax handler (from the apply method), but clicking on the submit
button on the form doesn't populate the json_result div. In fact,
it doesn't do anything even though, on the page source, the button's
onclick method is
wired up.
Glenn
On Sep 15, 11:59 am, Derek Chen-Becker dchenbec...@gmail.com wrote:
The apply method should be getting called because the SHtml.json
method
should register it as the handler for the form. Would you mind
sending me
the code you have and I'll take a look at it? I'm pretty sure this
code was
working at one point, but perhaps something has changed.
Derek
On Mon, Sep 14, 2009 at 2:03 PM, glenn gl...@exmbly.com wrote:
Actually, the JsonHandler in the example gets called, but not the
apply
(in:Any) method, as
that is never called in the book example. Also, the handler seems to
be called twice with every submit.
Why is that?
Glenn
On Sep 14, 8:08 am, glenn gl...@exmbly.com wrote:
This may be a question for the Lift Book forum, but has anyone
gotten
the JSON forms example 8.13 in the Lift Book to work? When I
tried
it, the JsonHandler in class JSONForm never gets called when the
submit button is clicked.
Glenn
--~--~-~--~~~---~--~~
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: Lift deal breakers
On Sep 13, 11:33 am, valotas valo...@gmail.com wrote:
I also think that javascript should go just before the boby's closing
tag. The main reason: Yahoo's YSlow and Google's Page speed both
telling you that is better to have as less scripts as possible and all
of them placed at the end of the page. The optimal would be one
javascript at the end of the page no matter how big it is as it would
be cached by any modern browser and it will be used from the local
cache on other requests from the same domain.
Of course optimal is not always what you can get. Assuming that you
have many javascript files it is also better to have them at the
bottom of the page. You will see a major performance boost because
browsers pause the rendering of the page in order to download
javascript. That is because javascript code could contain a
document.write witch means that it will change the dom of the page and
this is something that the browser will not be able to know in advance
in order to continue the parsing of the page. Moving javascript at the
bottom of the page will not decrease the page loading time BUT will
give the user something to see (the whole page) making him thing that
the page loads faster. Of course the browser will still have to get
the javascript and eval it.
As for unobtrusive, jquery (and the most js frameworks) provides a
solution binding an event on an html element after the page has been
loaded. So instead of having somthing like:
button onclick=liftAjax.lift_ajaxHandler
(quot;F1029758482780OTA=truequot;,
null, null, null); return false;Press me/button
you could have something like:
button id=liftajax_{some_generated_id}Press me/button
and at the end of the page add the javascript:
text type=text/javascript
$(function() {
$(#liftajax_{some_generated_id}).click(function()
{the_lift_ajaxHandler_call_here()})})
/script
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
If the ajax handle call is basically the same for most of the elements
you could instead of adding an id, add a class to the the button for
example:
button class=liftajaxPress me/button
and then at the end of the page add:
text type=text/javascript
$(function() {
$(.liftajax).click(function() {the_lift_ajaxHandler_call_here()})})
Two reason why I don't prefer this:
1. Lots of selectors could slow things down
2. Other JS frameworks may not have nice selectors as JQuery
/script
I personally use jQuery but the above can be done without the help of
any javascript framework. And to make things much more better you
could have all the handler scripts in a separete dynamicaly created
file and the at the end of the html have something like:
script type=text/javscript src=/path/to/the/dynamicaly/created/js/
with/a/random/id/to/prevent/caching/script
One reason for keeping me away from using lift for a project is this
mess with javascript. I mean, I first want plain html and nothing
else. If I get the html to work for me the I just add the javascript I
want or let the framework add it, but that should be done in an
elegant way in order to be able to switch it off or on or completely
replace it with my own. I don't want any framework to add by default
the javascript for me because it makes things harder to understand and
this is something bad for someone new to it.
I would be glad to help in this matter in any way possible.
Sorry for my English,
it's not my mother language!
I think this is a great post !
Yoryos
On Sep 13, 6:35 am, marius d. marius.dan...@gmail.com wrote:
Technically it could (as I implied above) but this can be lucrative
and IMHO the benefits are simply not that big. I'm not saying that
things are nailed down but I'd love to see a list of practical
benefits for Lift to not add event handlers such as on click to the
elements but rather programatically using synthetic (lift generated)
JS functions that would add events (i.e. JQuery, YUI ways).
Br's,
Marius
On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Maybe adding javascript event handlers could be delegated to something
that depends on which library is being used?
-
Kevin Wrightkev.lee.wri...@googlemail.com wrote:
Moving the script import shouldn't be too difficult, we have the
lift:tail
element and tail merge (which acts exactly the same as head merge) for
just
this sort of problem.
On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney
dustin.whit...@gmail.comwrote:
One nice thing about jquery's events, if done wisely, is they are
applied
after the DOM is loaded. With an onclick a button can be clicked and
some
ajax call is fired that returns and tries to modify a part of the DOM
that
hasn't been loaded. This is especially true if you have lots
[Lift] Re: Lift deal breakers
I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ 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: Why isn't this a trait in lift-json?
On Sep 13, 3:15 pm, Joni Freeman freeman.j...@gmail.com wrote:
Hi,
That annotation is used to configure the json path when extracting
values. By default the extraction code assumes that case class
parameter names match with json field names. For instance these match:
case class Foo(bar: String, baz: Int)
{ bar: qwerty, baz: 10 }
But sometimes json field names can contain characters which are not
allowed in Scala identifiers. For example:
{ foo-bar: qwerty, baz: 10 }
Now, to able to extract this we have to somehow tell the extractor the
exact path explicitly. Currently @path annotation is used for that:
case class Foo(@path(foo-bar) bar: String, baz: Int)
I don't see how a trait can accomplish this, maybe I'm missing
something?
The reason why it is in Java is that Scala annotations are not
accessible at runtime.
Right but I'd also suggest removing Java code from Lift stack. The
above can be easily achieved by introducing a trait such as:
case class Foo(bar: String with Nominator, baz: Int)
Lift is a 100% Scala code with zero Java code. We also have strong
opinions in the team that we should stay away from annotations.
one option would be something like this:
Lift would have :
trait Nominator{
def name : String
}
In user's code:
case class Foo(bar: String with MyNominator, baz: Int)
trait MyNominator extends Nominator {
def name = foo-bar
}
Yes it is more verbose then the annotation but IMHO it is more Scala-
ish Lift-ish.
Cheers Joni
On Sep 13, 11:03 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Just had a browse over the latest commit and found the following in
path.java:
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface path {
public String value();
}
Any reason were not using a trait etc to complete the same
functionality?
Cheers, Tim
--~--~-~--~~~---~--~~
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: Lift deal breakers
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
/script
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
--~--~-~--~~~---~--~~
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: Lift deal breakers
On Sep 13, 8:00 pm, Charles F. Munat c...@munat.com wrote:
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
I understand that but this is a bit impractical because lift would
have to generate artificial ID-s OR id-s could be tampered with or
other JS libraries may generate their own ID-s etc. Selectors by class
is also a little impractical from a framework standpoint. Also we'd
have to add code for each underlying JS library (JQuery, YUI etc).
This would require IMHO significant code to write and not a
significant gain. But I'd love to prove me wrong.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
I know this is practical from applications perspective when writing
specific JS etc. but from a framework perspective, this is not.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
I'm not 100% buying any proposal so far ... as I explained above the
disadvantages as we replace a JS expression with another JS function
call. It just adds a bit of conciseness .. nothing more.
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: Lift deal breakers
On Sep 12, 8:34 am, Indrajit Raychaudhuri indraj...@gmail.com wrote: Even if we assumed that Lift managed to do all the hard work, we still have a contradictory situation: the body/ being completely devoid of scripts but still have 'JS loaded at the end of the page'. It still has to be before the close of body tag and thereby sneaking into the body/. Worse, it's going to be incredibly difficult to implement a rich client interface (Cappuccino, Dojo, Sproutcore etc. - those who want to take complete control over the DOM) without the developer constantly having to prevent Lift and the UI framework not wrestle and step into the each other. A web *application* (like CMS) can get away with that, but not a *framework* (like Lift). What control of Lift over the DOM are you talking about. Lift's generated scripts in HTML is minimal, and it is about Comet mostly. Lift scripts do not really stay in other frameworks way. If you have a concrete example where Lift's stays in the way of integrating other tools please be specific about the problem and we'll see what/if we can do something about it. What is the exact wrestle here? And I am given to understand spiders are nowadays smart to recognize dom events handlers (e.g., onclick) and decide what to do when it encounters them. Oh, and while at that, 'view source' a GWT based application and help youself have a perspective :) Cheers, Indrajit On Sep 12, 5:07 pm, marius d. marius.dan...@gmail.com wrote: +1 Andrew. Regarding the rule - absolutely no javascript in the markup doesn't make a lot of sense. Some of the Lift's generated javascript for comet/ ajax calls is put inline at the end of the page. I see no practical reason not to do that. On the other hand putting liftAjax.js on the top of the page is not bad either. IN certain situations users may need this loaded prior their own js code. Besides I really doubt that putting it at the end of the page would really make any practical difference. Not putting lift's JS callas such as Ajax at onclick events like that can become quite lucrative from framework perspective because: 1. Lift would have to queue all these events and add them to a JS sequence and add this js to the served page. 2. that would create a dependency to JQuery events style that would have to be changed when YUI is in place or potentially other framework. If we'd still want this style but be JS library agnostic we'd have to do our own DOM manipulation etc which just adds more overhead without any practical gain. Br's, Marius On Sep 11, 10:18 pm, Andrew Scherpbier and...@scherpbier.org wrote: Dustin Whitney wrote:Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html:buttononclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/buttonThat onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. (I presume here SEO == Search Engine Optimization.) If you are going to use AJAX in your website, you have to use Javascript, right? If you don't want to use AJAX with lift, don't... Just use standard forms and links. (Also turn off client-side garbage collection and any comet stuff in Boot.scala...) So assuming you actually want an ajaxButton, the onclick needs to get in there somehow. The only other way would be to have lift create some javascript that modifies the DOM to somehow add that onclick. I think that would be much harder to read! For the SEO stuff, are you assuming deep traversal (clicking through forms) into your webapp by spiders? I don't know of any spiders that do that very well. Anyway, if that's what you want, then I wouldn't use AJAX for anything. A neat trick to let spiders get to all your public pages if your site has a complex form/ajax based navigation system is to use a site map and make sure all your main URLS are simple, non-form URLs. Criticism is best if one can demonstrate a better alternative.Client Side Load Time: I strive for that A in Y-Slow, so when I seescripttype=text/javascriptsrc=/ajax_request/liftAjax.js/scriptat the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. Have you actually verified that this makes a difference? I haven't verified this, so pardon my ignorance. It just seems like it either makes a difference of milliseconds or no difference at all because modern browsers make parallel requests and start rendering before everything is available. I'm sure if you can demonstrate two pages where the only difference is the location of the script include, and the one with the script include up front is noticeably slower
[Lift] Re: setting cookies in an ajax response
If it doesn't send down the cookie as you did, it sounds like a bug. I'd fix it but I can't in the next couple of weeks. Br's, Marius On Sep 12, 12:54 pm, harryh har...@gmail.com wrote: I have an SHtml.ajaxSelect that, when executed sets a cookie: S.addCookie(HTTPCookie(CITYID, city.id.toString)) and then returns a JsCmds.RedirectTo(uri) command. The cookie isn't actually being set (if I look at the live http headers the Set-Cookie line isn't sent down in the http response to the ajax call. It's not clear to me if this is correct behavior on lift's part, of if this is a bug. If it is correct behavior, is there a better way to do this sort of thing? -harryh --~--~-~--~~~---~--~~ 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: Lift deal breakers
Technically it could (as I implied above) but this can be lucrative and IMHO the benefits are simply not that big. I'm not saying that things are nailed down but I'd love to see a list of practical benefits for Lift to not add event handlers such as on click to the elements but rather programatically using synthetic (lift generated) JS functions that would add events (i.e. JQuery, YUI ways). Br's, Marius On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: Maybe adding javascript event handlers could be delegated to something that depends on which library is being used? - Kevin Wrightkev.lee.wri...@googlemail.com wrote: Moving the script import shouldn't be too difficult, we have the lift:tail element and tail merge (which acts exactly the same as head merge) for just this sort of problem. On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney dustin.whit...@gmail.comwrote: One nice thing about jquery's events, if done wisely, is they are applied after the DOM is loaded. With an onclick a button can be clicked and some ajax call is fired that returns and tries to modify a part of the DOM that hasn't been loaded. This is especially true if you have lots of javascript includes at the top of the page. I have waded my way through many wonky javascript bugs like this. They don't happen in your local environment because they load so quickly, but when pushed to production, problems ensue. Maybe there is a hook in the lift ajax js that waits to fire the call until after the DOM is loaded? -D On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote: I, too, would like to be able to move the liftAjax script call to the bottom of the page. Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin --~--~-~--~~~---~--~~ 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: Using Roles and LIftRules.authentication
On Sep 8, 1:18 am, glenn gl...@exmbly.com wrote:
Marius,
Please bear with me. I'm a little slow in following the logic here.
Don't worry glen.
I understand I can protect the resource as you suggest from all
but users with admin roles, using the LocParam,
HttpAuthProtected(() = Full(AuthRole(admin) .
Now, when I click on the link, if no user is logged in, the system
asks for a username and password to connect, but that's a user
on the host. not an application user.
Not necessarily. It is any type of user. In your authentication
function you can go in DB and validate the receiving credentials as
application user.
Somewhere, I need to assign the
currently logged in user the AuthRole(admin) needed to access
the resource.
Correct. And you dothis by setting userRoles RequestVar.
Seems to me I need code like this to run someplace:
def authorize(roleName:String): Box[Role] = {
object userRoles extends RequestVar[Role](null)
val credentials : (String,String) = User.currentUser match {
case Full(u) = (u.email.is, u.password.is)
case Empty = (null, null)
}
User.isa_?(roleName) match {
case true = {
LiftRules.authentication = HttpBasicAuthentication(lift)
{
case (credentials._1, credentials._2, req) =
println(John is authenticated!)
userRoles(_root_.net.liftweb.http.auth.AuthRole
(roleName))
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false = Empty
}
}
Can't be in Boot,
No you do not. Lift takes care of the roles matching for you. You
don't need to manually test if a user is-an admin or some other role
in order to access that resource. Please keep in mind that is just for
accessing resources (URI-s) if you need to do more complex logic in
your code and see if the user is an admin or having some other Role
that you'd probably need to save the Role into a SessionVar or into
your User object.
All I want here is to explain how HTTP based authentication and roles
based authorization works. I am definitely not claiming that this is
enough for all applications as currently we don't have HTTP based
authentication with forms for example ... but I think we should add
that as well.
Glenn
On Sep 7, 1:36 pm, marius d. marius.dan...@gmail.com wrote:
On Sep 7, 10:53 pm, glenn gl...@exmbly.com wrote:
Marius,
In practical terms, if I am already using an If LocParam, as in the
following:
If(() = User.isa_?(admin), S.?(not_authorized))
what does adding
HttpAuthProtected(() = User.authorize(admin)) to the Loc do?
It sais that this Loc is protected by the returned Role. Thus to
access this after passing the authentication the Role specified in the
authentication function (by setting userRoles) must be the same as or
a child of the Role the is protecting the Loc.
Here, I've had to define User.authorize to make things work, as:
def authorize(roleName:String): Box[Role] = {
val credentials : (String,String) = User.currentUser match {
case Full(u) = (u.email.is, u.password.is)
case Empty = (null, null)
}
User.isa_?(roleName) match {
case true = {
LiftRules.httpAuthProtectedResource.append {
case (ParsePath(listContents :: _, _, _, _)) = Full
(AuthRole(admin))
}
Why do you need to use httpAuthProtectedResource if you' using
HttpAuthProtected LocParam ?
LiftRules.authentication = HttpBasicAuthentication(lift)
{
case (credentials._1, credentials._2, req) =
AuthRole(roleName)
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false = Empty
}
Rather verbose, don't you think.
Your code is verbose but I don't see the justification for this
verbosity:
LiftRules.authentication = HttpBasicAuthentication(lift) {
case (username, password, req) = {
// Do you authentication in DB or whatever and you
determined that this is an admin user
userRoles(AuthRole(admin)) // userRoles needs to be
set. It is a RquestVar.
true
}
In Boot you have:
Menu(Loc(listContents, List(listContents), listContents,
HttpAuthProtected(() = Full(AuthRole(admin)
When you use HttpAuthProtected LocParam Lift appends a function to
LiftRules.httpAuthProtectedResource so you don't need to do it
manually.
This authorixation scheme is only about protecting resource by roles
and you do this almost declaratively and for authentication I thing
the things are pretty straight forward. One a user
[Lift] Re: Crazy idea for lift's mega proto user: admin panel.
Nice thoughts but personally I don't think this should be part of Lift core framework. However an admin panel could be provided via a lift widget and would be pretty interesting thing to have. Br's, Marius On Sep 8, 2:16 am, DFectuoso santiago1...@gmail.com wrote: I was thinking about how wonderful it is to get a login/register/ forgotPassword functionality with mega proto user and how it could become even better with a good tool for creating an admin section. I'm just adding the idea here so maybe if other people find value it could be considered for development(or probably it already is, i don't know). Adding an admin panel to mega proto user where the moderators/admins could change some options(like the way a user is validated, if gzip is enabled, etc) would be great for the end users of our apps, since it would be easier to change and maintain the site. Being a administrator at a Invision Power Board forum and having a couple of wordpress blogs, i see a lot of potential on this as a admin/ dev tool! Listing some of the things that i can imagine in this panel are: -phpMyAdmin-type of DB admin(browse your data easily, remove/change/ add stuff to it without having to create a CRUD for each thing) -execute queries -List the actor(and comet actors) with possibility to kill/reset them -Memory use analysis. -Statistics of use(hits, referrals, etc) -Options (any object/class/trait could have a val foo = adminPanel.option(category,optionName,description,defaultValue, otherValues[]) and be included in this place, of course the categories could create different menus. -User management(ban, authorize, give admin-rights). -Simple to-do list that all admins can edit -Log of errors/warnings/exceptions -Css editor -Easy-logo changer -File Manager(upload your images and stuff here) -String editor (you can change any default string from the megaprotouser forms and the index?) Also, a very polemic(and i think bad idea, but its common to see this in admin panels): -Installable plug-ins for this panel I know this seems like one step away from being a full blown CMS, forum, blog, etc. But if its extensible while we are building an app, it will be very useful for the different moments of development and use. Of course i don't expect any of this to be done right now, i understand there are a couple of integrations and bigger things going on but i really wanted to brainstorm on this with you guys! --~--~-~--~~~---~--~~ 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: Using Roles and LIftRules.authentication
On Sep 8, 7:00 pm, glenn gl...@exmbly.com wrote:
Marius,
I guess there is little more to be said on this issue. Keep in mind
that
in many real-world applications, dynamically assigned user roles are a
requirement. And it's possible for users to have multiple roles, each
in a different role hierarchy, in the same application.
Well Lift Roles are build on hierarchical model.
Inevitably, I will have to implement my own, perhaps using
JaaS or one of its variants. If you have any thoughts on that issue,
I'd like to hear them.
I kind of doubt that JAAS will take you farther then Lift HTTP auth
support.
Thanks,
Glenn
On Sep 8, 8:40 am, marius d. marius.dan...@gmail.com wrote:
On Sep 8, 6:12 pm, glenn gl...@exmbly.com wrote:
Marius,
With your help, I think I'm getting closer to understanding what is
needed
here.
One thing though, is that I believe I do need to manually check if the
user has the
appropriate role (in the DB) before I can set userRoles RequestVar.
See, in my application,
I have no way of knowing in advance if a logged-in user is authorized
to access
a particular resource. I'm trying to accomplish that programatically.
Well if when authenticating a user (LiftRules.authentication) you
can't determine the Role, then this mechanism probably won't help you
and you need to build your own.
And, don't forget, roles
can be changed at any time in the application.
I assume that a super-admin user would be able to change roles for
other users right? ... If so you just need to update data in your DB
for say user X. So when User X authenticates you'll get the new role
assigned. But maybe this is not how your app is designed to work.
In other words, I
can't just assume it in my
authentication function and make the assignment there.
Does that make sense? This is not to say that I can't work
tangentially to Http basic authentication
in Lift and create my own, just that I'm trying to incorporate the
work already done so I don't have to.
Lift's HTTP authentication and authorization is built on very simple
principles such as:
1. In the authentication function you typically know the role for that
user.
2. Resources (URI's essentially) are protected by hierarchically
structured roles that are matched with the role determined by the
authentication function.
Glenn
On Sep 7, 11:24 pm, marius d. marius.dan...@gmail.com wrote:
On Sep 8, 1:18 am, glenn gl...@exmbly.com wrote:
Marius,
Please bear with me. I'm a little slow in following the logic here.
Don't worry glen.
I understand I can protect the resource as you suggest from all
but users with admin roles, using the LocParam,
HttpAuthProtected(() = Full(AuthRole(admin) .
Now, when I click on the link, if no user is logged in, the system
asks for a username and password to connect, but that's a user
on the host. not an application user.
Not necessarily. It is any type of user. In your authentication
function you can go in DB and validate the receiving credentials as
application user.
Somewhere, I need to assign the
currently logged in user the AuthRole(admin) needed to access
the resource.
Correct. And you dothis by setting userRoles RequestVar.
Seems to me I need code like this to run someplace:
def authorize(roleName:String): Box[Role] = {
object userRoles extends RequestVar[Role](null)
val credentials : (String,String) = User.currentUser match {
case Full(u) = (u.email.is, u.password.is)
case Empty = (null, null)
}
User.isa_?(roleName) match {
case true = {
LiftRules.authentication = HttpBasicAuthentication(lift)
{
case (credentials._1, credentials._2, req) =
println(John is authenticated!)
userRoles(_root_.net.liftweb.http.auth.AuthRole
(roleName))
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false = Empty
}
}
Can't be in Boot,
No you do not. Lift takes care of the roles matching for you. You
don't need to manually test if a user is-an admin or some other role
in order to access that resource. Please keep in mind that is just for
accessing resources (URI-s) if you need to do more complex logic in
your code and see if the user is an admin or having some other Role
that you'd probably need to save the Role into a SessionVar or into
your User object.
All I want here is to explain how HTTP based authentication and roles
based authorization works. I am definitely not claiming that this is
enough for all applications as currently we
[Lift] Re: Using Roles and LIftRules.authentication
On Sep 8, 6:12 pm, glenn gl...@exmbly.com wrote:
Marius,
With your help, I think I'm getting closer to understanding what is
needed
here.
One thing though, is that I believe I do need to manually check if the
user has the
appropriate role (in the DB) before I can set userRoles RequestVar.
See, in my application,
I have no way of knowing in advance if a logged-in user is authorized
to access
a particular resource. I'm trying to accomplish that programatically.
Well if when authenticating a user (LiftRules.authentication) you
can't determine the Role, then this mechanism probably won't help you
and you need to build your own.
And, don't forget, roles
can be changed at any time in the application.
I assume that a super-admin user would be able to change roles for
other users right? ... If so you just need to update data in your DB
for say user X. So when User X authenticates you'll get the new role
assigned. But maybe this is not how your app is designed to work.
In other words, I
can't just assume it in my
authentication function and make the assignment there.
Does that make sense? This is not to say that I can't work
tangentially to Http basic authentication
in Lift and create my own, just that I'm trying to incorporate the
work already done so I don't have to.
Lift's HTTP authentication and authorization is built on very simple
principles such as:
1. In the authentication function you typically know the role for that
user.
2. Resources (URI's essentially) are protected by hierarchically
structured roles that are matched with the role determined by the
authentication function.
Glenn
On Sep 7, 11:24 pm, marius d. marius.dan...@gmail.com wrote:
On Sep 8, 1:18 am, glenn gl...@exmbly.com wrote:
Marius,
Please bear with me. I'm a little slow in following the logic here.
Don't worry glen.
I understand I can protect the resource as you suggest from all
but users with admin roles, using the LocParam,
HttpAuthProtected(() = Full(AuthRole(admin) .
Now, when I click on the link, if no user is logged in, the system
asks for a username and password to connect, but that's a user
on the host. not an application user.
Not necessarily. It is any type of user. In your authentication
function you can go in DB and validate the receiving credentials as
application user.
Somewhere, I need to assign the
currently logged in user the AuthRole(admin) needed to access
the resource.
Correct. And you dothis by setting userRoles RequestVar.
Seems to me I need code like this to run someplace:
def authorize(roleName:String): Box[Role] = {
object userRoles extends RequestVar[Role](null)
val credentials : (String,String) = User.currentUser match {
case Full(u) = (u.email.is, u.password.is)
case Empty = (null, null)
}
User.isa_?(roleName) match {
case true = {
LiftRules.authentication = HttpBasicAuthentication(lift)
{
case (credentials._1, credentials._2, req) =
println(John is authenticated!)
userRoles(_root_.net.liftweb.http.auth.AuthRole
(roleName))
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false = Empty
}
}
Can't be in Boot,
No you do not. Lift takes care of the roles matching for you. You
don't need to manually test if a user is-an admin or some other role
in order to access that resource. Please keep in mind that is just for
accessing resources (URI-s) if you need to do more complex logic in
your code and see if the user is an admin or having some other Role
that you'd probably need to save the Role into a SessionVar or into
your User object.
All I want here is to explain how HTTP based authentication and roles
based authorization works. I am definitely not claiming that this is
enough for all applications as currently we don't have HTTP based
authentication with forms for example ... but I think we should add
that as well.
Glenn
On Sep 7, 1:36 pm, marius d. marius.dan...@gmail.com wrote:
On Sep 7, 10:53 pm, glenn gl...@exmbly.com wrote:
Marius,
In practical terms, if I am already using an If LocParam, as in the
following:
If(() = User.isa_?(admin), S.?(not_authorized))
what does adding
HttpAuthProtected(() = User.authorize(admin)) to the Loc do?
It sais that this Loc is protected by the returned Role. Thus to
access this after passing the authentication the Role specified in the
authentication function (by setting userRoles) must be the same as or
a child of the Role the is protecting the Loc.
Here, I've had to define User.authorize to make things work, as:
def authorize(roleName:String): Box[Role
[Lift] Re: FieldIdentifier
A MappedField is a FieldIdentifier. In a field you can override validate function and return a list of FieldError. You need to override uniqueFieldId and return the ID of the page element that will hold the specific error message. It is the ID that you specified to the lift:msg id=abc/ tag. In this way the error message will be rendered in specific places in the page. If you do not specify the uniqueFieldId your error message will be rendered in the overall real estate where you put lift:msgs/ tag. Br's, Marius On Sep 7, 2:01 am, Naftoli Gugenheim naftoli...@gmail.com wrote: How do FieldErrors work? When does a fields uniqueFieldId get set? --~--~-~--~~~---~--~~ 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: Where did AnyVar go ?
Same question for Injector, SimpleInjector etc. Br's, Marius On Sep 7, 4:08 pm, Marius marius.dan...@gmail.com wrote: Hi, I just did a pull and get a bunch of compile time errors obviously. Seems like someone kidnapped AnyVar? Br's, Marius --~--~-~--~~~---~--~~ 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: Using Roles and LIftRules.authentication
On Sep 7, 10:53 pm, glenn gl...@exmbly.com wrote:
Marius,
In practical terms, if I am already using an If LocParam, as in the
following:
If(() = User.isa_?(admin), S.?(not_authorized))
what does adding
HttpAuthProtected(() = User.authorize(admin)) to the Loc do?
It sais that this Loc is protected by the returned Role. Thus to
access this after passing the authentication the Role specified in the
authentication function (by setting userRoles) must be the same as or
a child of the Role the is protecting the Loc.
Here, I've had to define User.authorize to make things work, as:
def authorize(roleName:String): Box[Role] = {
val credentials : (String,String) = User.currentUser match {
case Full(u) = (u.email.is, u.password.is)
case Empty = (null, null)
}
User.isa_?(roleName) match {
case true = {
LiftRules.httpAuthProtectedResource.append {
case (ParsePath(listContents :: _, _, _, _)) = Full
(AuthRole(admin))
}
Why do you need to use httpAuthProtectedResource if you' using
HttpAuthProtected LocParam ?
LiftRules.authentication = HttpBasicAuthentication(lift)
{
case (credentials._1, credentials._2, req) =
AuthRole(roleName)
true
}
Full(new _root_.net.liftweb.http.auth.Role{
def name = roleName})
}
case false = Empty
}
Rather verbose, don't you think.
Your code is verbose but I don't see the justification for this
verbosity:
LiftRules.authentication = HttpBasicAuthentication(lift) {
case (username, password, req) = {
// Do you authentication in DB or whatever and you
determined that this is an admin user
userRoles(AuthRole(admin)) // userRoles needs to be
set. It is a RquestVar.
true
}
In Boot you have:
Menu(Loc(listContents, List(listContents), listContents,
HttpAuthProtected(() = Full(AuthRole(admin)
When you use HttpAuthProtected LocParam Lift appends a function to
LiftRules.httpAuthProtectedResource so you don't need to do it
manually.
This authorixation scheme is only about protecting resource by roles
and you do this almost declaratively and for authentication I thing
the things are pretty straight forward. One a user is authenticated
(using HTTP authentication) you need to specify the Role for this user
and you do this using userRoles RequestVar.Thus /listContents can only
be accessed if:
1. user passed authentications
2. user's Role is an admin or a child of the Role specified in
HttpAuthProtected
elipsisless Glenn
On Sep 6, 8:27 am, Timothy Perrett timo...@getintheloop.eu wrote:
Right, i know it has a sitemap aspect... just based on what chas has
asked about RBAC before, I can only presume he's still looking for
more granularity than sitemap offers :-)
Perhaps it might work for Glenn though...
Cheers, Tim
On Sep 6, 3:44 pm, marius d. marius.dan...@gmail.com wrote:
Glen,
Tim is correct however HTTP auth support + it's Role model can be used
for SiteMenu as well. Please see:
case class HttpAuthProtected(role: () = Box[Role]) extends LocParam
You easily can specify that a Loc is a protected resource you just
need to return the Role that guards this resource. This Loc will be
served only if HTTP authentication succeeds and the Role match.
So this is an RBAC.
Br's,
Marius
On Sep 5, 7:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Glenn, its simply not designed to do what your asking - however, the
most lift way of doing access control is with SiteMap, so
potentially look into that as a solution. You don't detail your needs,
but we've had this conversation several times on-list so just look
through the archives and that might spawn some other ideas for you.
Tim
PS: Is there any good reason you always put an ellipsis after your
name? For some reason it bothers me quite a bit!
On Sep 5, 5:32 pm, glenn gl...@exmbly.com wrote:
Marius,
I appreciate your reply, but the question I asked regards useage of
the Role trait in what Charles
refers to as a Role-Based Access Control (RBAC) system. I could not
find this addressed in the
Lift Book and, no, there is no illuminating code in the lift-
authentication example. It's established
the trait is not a good mixin for a mapper class in maintaining
persistent role/access
data. I was asking, on a lark, if anyone had ideas on a pattern that
might help. I guess
I've gotten an answer - No.
I certainly don't expect Lift, out-of-the-box, to provide a complete
authorization package
and I would have been surprised if it had.
Glenn...
On Sep 5, 12:38 am, marius d. marius.dan...@gmail.com wrote:
I'll let Tim provide you a concrete code
[Lift] Re: Feature Request: Add S.findComet(theType: String, name: String): Option[CometActor]
Is this too inconvenient ?
val myComet = Box(findComet(myType).filter(_.name == myname))
I have nothing against your proposal except it should return a Box not
an Option.
Br's,
Marius
On Sep 6, 6:17 am, Xavi Ramirez xavi@gmail.com wrote:
Hello,
Would it be possible to add the following findComet override to LiftSession?
def findComet(theType: String, name: String): Option[CometActor] =
synchronized { asyncComponents get (theType, name) } // I'm not sure
if this is the correct implementation, but you get the idea
I'd like to be able to get hold of a specific CometActor without
storing it in a session variable.
Thanks,
Xavi
--~--~-~--~~~---~--~~
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: Using Roles and LIftRules.authentication
Glen,
Tim is correct however HTTP auth support + it's Role model can be used
for SiteMenu as well. Please see:
case class HttpAuthProtected(role: () = Box[Role]) extends LocParam
You easily can specify that a Loc is a protected resource you just
need to return the Role that guards this resource. This Loc will be
served only if HTTP authentication succeeds and the Role match.
So this is an RBAC.
Br's,
Marius
On Sep 5, 7:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Glenn, its simply not designed to do what your asking - however, the
most lift way of doing access control is with SiteMap, so
potentially look into that as a solution. You don't detail your needs,
but we've had this conversation several times on-list so just look
through the archives and that might spawn some other ideas for you.
Tim
PS: Is there any good reason you always put an ellipsis after your
name? For some reason it bothers me quite a bit!
On Sep 5, 5:32 pm, glenn gl...@exmbly.com wrote:
Marius,
I appreciate your reply, but the question I asked regards useage of
the Role trait in what Charles
refers to as a Role-Based Access Control (RBAC) system. I could not
find this addressed in the
Lift Book and, no, there is no illuminating code in the lift-
authentication example. It's established
the trait is not a good mixin for a mapper class in maintaining
persistent role/access
data. I was asking, on a lark, if anyone had ideas on a pattern that
might help. I guess
I've gotten an answer - No.
I certainly don't expect Lift, out-of-the-box, to provide a complete
authorization package
and I would have been surprised if it had.
Glenn...
On Sep 5, 12:38 am, marius d. marius.dan...@gmail.com wrote:
I'll let Tim provide you a concrete code example but AFAIK there is a
lift-authetication example in examples?
A few points:
1. We support both BASIC and DIGEST HTTP authentication
2. First, to apply authentication you need to specify which resource
(by URI) is a protected resource. Here we say that resource X is
protected by Role A (Roles are hierarchicaly structured)
3. Secondly you set up the authentication function in Boot (for Basic
or Digest) you check the credentials. If authentication succeeds that
request is being processed.
Here is an example from lift-authentication:
LiftRules.httpAuthProtectedResource.prepend {
case (ParsePath(secure-basic :: Nil, _, _, _)) =
Full(AuthRole(admin))
}
// This resource is protected by an AuthRole named admin.
LiftRules.authentication = HttpBasicAuthentication(lift) {
case (someuser, 1234, req) = {
Log.info(You are now authenticated !)
userRoles(AuthRole(admin))
true
}
}
When we try to access /secure-basic resource HTTP basic auth. is
applied. If
credentials are correct we set the AuthRole as admin on the
Requestvar
userRoles. If we would have set another role such as userRoles
(AuthRole
(guest)) the resource would still not be served as guest has nothing
to do with
an admin. The lift-book describes the rules of Roles application.
All this has nothing to do with Mapper or Record etc. it is purely
about HTTP authentication and a simple authorization mechanism
Br's,
Marius
On Sep 5, 12:53 am, glenn gl...@exmbly.com wrote:
I'm looking for direction on the best pattern for implementing basic
authentication and authorization in Lift.
For example, if I already have a Role mapper to store roles in the
database, to what do I attach the Role trait in
the net.liftweb.http.auth package?
1) The mapper. You would have to make sure there were no naming
conflicts ( i.e., def name in the trait and the mapped string, name,
in the mapper. Not the best design pattern to link the two, in my
humble opinion.)
or
2) A new class, or perhaps an object, with the trait that wraps a Role
mapper instance.
The other piece to the puzzle is managing the list of AuthRoles,
create protected resources and build the Lift.authentication cases. If
you limit this to Boot, then you give up on dynamic authentication and
authorization, or do you?
Glenn...
--~--~-~--~~~---~--~~
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: Using Roles and LIftRules.authentication
I'll let Tim provide you a concrete code example but AFAIK there is a
lift-authetication example in examples?
A few points:
1. We support both BASIC and DIGEST HTTP authentication
2. First, to apply authentication you need to specify which resource
(by URI) is a protected resource. Here we say that resource X is
protected by Role A (Roles are hierarchicaly structured)
3. Secondly you set up the authentication function in Boot (for Basic
or Digest) you check the credentials. If authentication succeeds that
request is being processed.
Here is an example from lift-authentication:
LiftRules.httpAuthProtectedResource.prepend {
case (ParsePath(secure-basic :: Nil, _, _, _)) =
Full(AuthRole(admin))
}
// This resource is protected by an AuthRole named admin.
LiftRules.authentication = HttpBasicAuthentication(lift) {
case (someuser, 1234, req) = {
Log.info(You are now authenticated !)
userRoles(AuthRole(admin))
true
}
}
When we try to access /secure-basic resource HTTP basic auth. is
applied. If
credentials are correct we set the AuthRole as admin on the
Requestvar
userRoles. If we would have set another role such as userRoles
(AuthRole
(guest)) the resource would still not be served as guest has nothing
to do with
an admin. The lift-book describes the rules of Roles application.
All this has nothing to do with Mapper or Record etc. it is purely
about HTTP authentication and a simple authorization mechanism
Br's,
Marius
On Sep 5, 12:53 am, glenn gl...@exmbly.com wrote:
I'm looking for direction on the best pattern for implementing basic
authentication and authorization in Lift.
For example, if I already have a Role mapper to store roles in the
database, to what do I attach the Role trait in
the net.liftweb.http.auth package?
1) The mapper. You would have to make sure there were no naming
conflicts ( i.e., def name in the trait and the mapped string, name,
in the mapper. Not the best design pattern to link the two, in my
humble opinion.)
or
2) A new class, or perhaps an object, with the trait that wraps a Role
mapper instance.
The other piece to the puzzle is managing the list of AuthRoles,
create protected resources and build the Lift.authentication cases. If
you limit this to Boot, then you give up on dynamic authentication and
authorization, or do you?
Glenn...
--~--~-~--~~~---~--~~
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: Logging sql queries generated by Mapper
Please see this thread: http://groups.google.com/group/liftweb/browse_thread/thread/7d5daf78a7e52275/ff9b6f80e19a999b?lnk=gstq=addLogFunc#ff9b6f80e19a999b Br's, Marius On Sep 4, 5:03 pm, José María josemariar...@gmail.com wrote: Hi, I'm new to JAVA as platform, I want to see the sql queries generated by Mapper queries. I've been reading the LiftWeb book but logging appears only as an appendix at the end and it doesn't tell you how to configure the Log system. Should I use Log4J config? Where should I put the configuration files? 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] Re: lift:msgs - how to override the default markup?
In Boot you can do:
LiftRules.snippetDispatch.prepend {
case Msgs = MyMsgs
}
where MyMsg is :
object MyMsg extends DispatchSnippet {
}
But the simplest way is to simply not use Msgs snippet and build your
own one. There is no magic in Msgs snippet. You can probably inspire
your code from Msgs snippet.
Br's,
Marius
On Sep 3, 10:20 pm, george geo...@mattandgeorge.com wrote:
Hello folks,
If I want to change the XHTML output of the builtin snippet Msgs, what
is the best way to do that? / Can I do that?
Say for example if I didn't want an unordered list..
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] Re: lift:msgs - how to override the default markup?
Note that noticesToJsCmd is used for Ajax propagated notices and not when rendering the actual page when the Msgs snippet is executed. Br's, Marius On Sep 3, 10:59 pm, george geo...@mattandgeorge.com wrote: thanks marius, I'll explore both options and hopefully I'll learn some more about scala and lift along the way.. --~--~-~--~~~---~--~~ 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: what is the functionality of fmapFunc
This string acts as a function ID. calling SHtml.link you bound a function to be executed when user clicked that link. That strange string is sent back to Lift and Lift will know which function to invoke. fmapFunc facilitates binding user-function. Having this definition def fmapFunc[T](in: AFuncHolder)(f: String = T) We provide to fmapFunc the user function (abstracted by AFuncHolder) and then another function that receives the created string ID: that strange string. having this string, in function f, Lift just adds that string as a query string to the link itself and returns the generated anchor tag. Br's, Marius On Sep 2, 12:00 pm, XiaomingZheng xiaomingzhen...@gmail.com wrote: when i use the SHtml.link, i found lift framework add a magic string after the url, and this string is generated by fmapFunc. What exactly fmapFunc used for and why add this strange string after the url? 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] Re: HTML decoding
div
{(str.split(\n).map(x = div{x}/div))}
/div
{x} is an expression that returns a String. Assuming that x is a well-
formed XML node you could try something like:
div
{(str.split(\n).map(x = div{XML.loadString(x)}/div))}
/div
Br's,
Marius
On Sep 1, 7:24 am, KP horse.headed.fish@gmail.com wrote:
Hi all.
I have some text I read in from an uploaded file using
scala.io.Source. I then have something like
div
{(str.split(\n).map(x = div{x}/div))}
/div
with str some portion of text from the input file containing HTML
formatting tags like i or b.
Now, characters like are being escaped to their proper entities
lt;. However, I want these to display as actual HTML (e.g. want
ifoo/i to be italic). Is there a straightforward way to do this?
(Note that security isn't an issue since this is a feature only admins
will be using).
Thanks much.
-KP
--~--~-~--~~~---~--~~
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: stopping an Actor
Call self.exit(message) Br's, Marius On Sep 1, 6:27 pm, Jack Widman jack.wid...@gmail.com wrote: How does an Actor stop itself from running. That is to say, stop its act method as soon as possible? --~--~-~--~~~---~--~~ 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: Great advice for startups
Very nice article ! On Sep 1, 6:38 pm, David Pollak feeder.of.the.be...@gmail.com wrote: Folks, I read this blog post this morning:http://blog.asmartbear.com/blog/youre-a-little-company-now-act-like-o... While this list is mainly for discussing Lift, I thought I'd share the link. It's great advice, IMHO, for small startups. Enjoy. Thanks, David -- 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: Question about Lift/Scala Lift Discussion Board
My 2 cents if I may ... Although I love this list and this is the official Lift list and support I think it is important to also have other wiki's, forums etc. out there. Personally I don't see this as a community split. More and more people are becoming pretty knowledgeable with Lift Scala sharing information about Lift on other channels ... is nothing wrong with that .. .quite the opposite. In fact this may take some of the load on this list as community grows. Would be nice though to have a central place where all other wiki's/ forums can be found. For instance serious forums/wikis could be references from lift web-site or even fromthis list in the header section. Br's, Marius On Aug 30, 8:37 am, Naftoli Gugenheim naftoli...@gmail.com wrote: The lift community is not huge. It's David Pollak's brainchild, and I don't see how you can discuss creating a forum (after the fact) without his okaying it. How can you compare it to an IRC? A forum fills much of the same purpose as the list, much more than IRC. Some of the advantages mentioned are better solved by a Wiki. (Your volunteering to help with it is much appreciated.) Searchability - sounds like a bug on Google's part, no? Is there a Group for discussing Google Groups? In any case, it's addressed by services like MarkMail. Isn't Nabbles searchable? Duplicate questions - forums don't completely solve this. Searchability would help, as will the Wiki as it grows. Stickies - Google Groups doesn't allow stickies? Syntax highlighting/formatting; organization - the way I see it, you can draw a continuum with IRC being the most transient and a Wiki etc. the most permanent, with a mailing list, a Google Groups mailng list, and a forum falling in between, in increasing order of permanence/organizability. As you go from left to right you get more of these features, but a forum is still less than a Wiki. On the other hand as you go right to left you get more dynamic/on the fly--you just write a question without worrying about organization or formatting. Does that make sense? - Xavi Ramirezxavi@gmail.com wrote: I applaud Artem's initiative! The mailing list has undoubtedly been an extremely helpful resource. That said, a mailing lists in general have several short comings: - Hard to search through - Many duplicate questions - No stickies - No syntax highlighting and few formatting options - Little to no message organization - Few moderation tools A forum could be a nice way to address these issues, so it might be worth a try. Also I think introducing a forum is anymore likely to splinter than an IRC chat room. Just my two cents. -Xavi On Sat, Aug 29, 2009 at 8:22 PM, Timothy Perretttimo...@getintheloop.eu wrote: Agreed (and +1) - Personally I actually prefer mailing lists full stop because it involves no web site trawling to get to the topics one is after... Cheers, Tim On 30/08/2009 01:20, TylerWeir tyler.w...@gmail.com wrote: I'm not really sure how splintering the community is going to help. I feel the google group has been fine. On Aug 29, 6:59 pm, Artem art...@gmail.com wrote: Hey! I stumbled on Lift a couple weeks ago and have been messing around with it a lot! I am a Ruby on Rails programmer and it seems like Ruby is doing a fine job serving the web programmers community. Recently, I read an article about Twitter running RoR and it crashing after a while. They decided to switch to Scala because it's scalable unlike Ruby. I am planning on developing a large website that will require lots of CPU/Database usage and I was wondering if Scala/Lift is the way to do it? I'm not a fan of Google Groups, they are not very user friendly, so I created a forum specially for Lift developers that like to discuss topics about the Scala/Lift programming language. If you want to help start the forum and post a couple topics I would greatly appreciate it. The link ishttp://www.liftforum.com. It's a new forum so there isn't much content on it yet. 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] Re: Question about Lift/Scala Lift Discussion Board
What? ... Is there on ONE forum about Java, Scala, Spring, Rail etc? ... did all Java forums needed James Gosling approval ? .. Come on .. So yes people can talk about it make they own wikis,forums,blogs ... internet is free you know. I have tons of respect for David and this community and I don't need to write this down here but IMO let people know about Lift Scala by whatever means. It doesn't have to be a single information channel. I hate when I see such a dictatorial attitude about things ... Br's, Marius On Aug 30, 4:20 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: Once again, I don't see how you can discuss it until you know that David's fine with it. Personally I haven't read any concrete benefit (I don't know what take the load off or get more sites out there mean practically) that isn't available now between the list an the wiki---certainly not to outweigh the very clear disadvantage to both posters, who have that much less of a chance getting an answer in any one place and may have to ask twice, as well as to experts who can either only monitor one site and leave the other site with fewer experts; or be inconvenienced to monitor both. How many members are there of the Google Group currently? And what percentage ever offer answers? Regularly? The lift community is not as large as many other communities. Does Scala itself have other forums besides its own lists? If so what is their state? Certainly the Scala community is much larger than lift's. (Maybe you should make your forum be a Scala forum, and have a lift category... But again, I think it's only fair to ask lift's mastermind first!) - marius d.marius.dan...@gmail.com wrote: My 2 cents if I may ... Although I love this list and this is the official Lift list and support I think it is important to also have other wiki's, forums etc. out there. Personally I don't see this as a community split. More and more people are becoming pretty knowledgeable with Lift Scala sharing information about Lift on other channels ... is nothing wrong with that .. .quite the opposite. In fact this may take some of the load on this list as community grows. Would be nice though to have a central place where all other wiki's/ forums can be found. For instance serious forums/wikis could be references from lift web-site or even fromthis list in the header section. Br's, Marius On Aug 30, 8:37 am, Naftoli Gugenheim naftoli...@gmail.com wrote: The lift community is not huge. It's David Pollak's brainchild, and I don't see how you can discuss creating a forum (after the fact) without his okaying it. How can you compare it to an IRC? A forum fills much of the same purpose as the list, much more than IRC. Some of the advantages mentioned are better solved by a Wiki. (Your volunteering to help with it is much appreciated.) Searchability - sounds like a bug on Google's part, no? Is there a Group for discussing Google Groups? In any case, it's addressed by services like MarkMail. Isn't Nabbles searchable? Duplicate questions - forums don't completely solve this. Searchability would help, as will the Wiki as it grows. Stickies - Google Groups doesn't allow stickies? Syntax highlighting/formatting; organization - the way I see it, you can draw a continuum with IRC being the most transient and a Wiki etc. the most permanent, with a mailing list, a Google Groups mailng list, and a forum falling in between, in increasing order of permanence/organizability. As you go from left to right you get more of these features, but a forum is still less than a Wiki. On the other hand as you go right to left you get more dynamic/on the fly--you just write a question without worrying about organization or formatting. Does that make sense? - Xavi Ramirezxavi@gmail.com wrote: I applaud Artem's initiative! The mailing list has undoubtedly been an extremely helpful resource. That said, a mailing lists in general have several short comings: - Hard to search through - Many duplicate questions - No stickies - No syntax highlighting and few formatting options - Little to no message organization - Few moderation tools A forum could be a nice way to address these issues, so it might be worth a try. Also I think introducing a forum is anymore likely to splinter than an IRC chat room. Just my two cents. -Xavi On Sat, Aug 29, 2009 at 8:22 PM, Timothy Perretttimo...@getintheloop.eu wrote: Agreed (and +1) - Personally I actually prefer mailing lists full stop because it involves no web site trawling to get to the topics one is after... Cheers, Tim On 30/08/2009 01:20, TylerWeir tyler.w...@gmail.com wrote: I'm not really sure how splintering the community is going to help. I feel the google group has been fine. On Aug 29, 6:59 pm, Artem
[Lift] Re: Dependency Injection in Lift
Most of DI of Lift is currently done using PartialFunction-s and Function lists that people can set in Boot or for snippets in case on binding functions usign SHtml helpers etc. Personally I'm not at all a fan of Pojo/Poji DI by annotations especially in Scala realm where there are other artifacts such as function composition, monads, mixin composition, higher order functions etc. The other problem with annotations is that we can't currently build annotations in Scala to be visible at runtime, so we'd probably have to code them in Java or use some existent Java annotations ... but this already smells hacky IMHO. If enterprise folks solve one problem by DI by annotation it doesn't mean that this fits in all contexts.Persistence loosely coupling can be achieved in many ways: 1. Implement your own persistence semantic on top of Record 2. Implement your own traits hence your own abstractions 3. etc What we've learned with Lift is the it is OK to give to persistence objects understanding of rendering. Having dumb objects that carry on just data and rely of layers that can do different jobs (render, persist) is IMO not a very good design approach. Having snippets invoking the persistence layer is ok, in fact it is natural for applications. Of course with a proper level of persistence abstraction IF there are chances for the application to use a different persistence mechanism then say JDBC. But many application don't really need such a rigorous decoupling so using mapper/record from snippets makes a lot of sense. Br's, Marius On Aug 30, 6:21 pm, Chris Lewis burningodzi...@gmail.com wrote: I like the Lift framework. It has its rough edges, but it's a great way to get into web app development using scala. It borrows many good ideas from other frameworks, most notably its convention over configuration structure (rails) and its scriptless view layer (wicket). One thing I'm not a big fan of is its baked-in database layer, the Mapper (now in flux and being reborn as Record), and so was pleased to find the JPA archetype in the 1.1 tree. Using this archetype, you get a barebones but functioning lift app using pure JPA. This is a great start, but when I poked around the snippets I saw two things that troubled me: The underlying entity manager API leaks directly into what would be the service layer API; a single object exposed as Model. The snippet code is hardwired to Model, which uses it directly as a global DAO. This archetype is still in development, and it very well may change. It's carries a nature of being experimental; showing you how it can be done, but probably not how it should be done. However, it highlighted an issue I have with Lift, one that the boring enterprise crowd has solved: dependency injection. I have an admittedly specific idea in mind for what I want to implement in my would-be Lift app: I want to be able to declare a few fields and annotate them so that a layer above will provide me with acceptable instances. Yeah, I want to inject DAOs in the oh-so-familiar Guice/Spring/T5 IoC way. I like this partially because it's familiar, but also because it provides me with loosely coupled code. There's been some good discussion on the subject of implementing dependency injection in Scala using mere language constructs. I dove into this subject, starting with chapter 27 of [http://www.artima.com/shop/programming_in_scala]: Modular Programming Using Objects. It's a good read, and I recommend the book. After that I found my way to some relevant posts in the blogs of Debasish Ghosh and Jonas Boner, respectively: http://debasishg.blogspot.com/2008/02/scala-to-di-or-not-to-di.htmlhttp://jonasboner.com/2008/10/06/real-world-scala-dependency-injectio... Very cool indeed, but I've slightly digressed. What I want to explore is how to loosely couple the persistence implementation (be it JPA, JDO, or a baked in model) with the accessing of persistent objects. I don't see how the aforementioned technique (the cake pattern) would help in the case of lift snippets, because we don't have any kind of hooks where we can provide configuration of snippets (at least, not that I know of). This is exactly the issue that DI solves. So what are the thoughts of the lift-power users? Is there a way to get this in lift, or would you say that I am doing it wrong? sincerely, chris --~--~-~--~~~---~--~~ 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: Overriding widgets stylesheets
No you don't have to do this because In Boot you are already calling
CalendarMonthlyView.init
Br's,
Marius
On Aug 30, 7:22 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
4. Additionally, you have to add this in Boot environment. Often we
end up missing out on this step, or don't get the pattern right :)
ResourceServer.allow {
case _ :: style.css :: Nil = true
}
Of course, you can narrow the PF argument to better adjust to the
need.
Cheers, Indrajit
On Aug 27, 9:06 pm, Marius marius.dan...@gmail.com wrote:
Someone encountered the problem where he couldn't override the
stylesheet used by some widget. Damn I can't find any more that
thread ...
Anyways here it is:
1. Include the widget in your application say monthview.
2. The url to the stylesheet is: /classpath/calendars/monthview/
style.css
3. In order to override this put your changed style.css in WEB-INF/
classes/toserve/calendars/monthview/style.css
This works for me.
Br's,
Marius
--~--~-~--~~~---~--~~
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: Overriding widgets stylesheets
Yeah ... in general all existent lift widgets have an init method that
needs to be called in boot.
On Aug 30, 8:39 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
Oops, I didn't follow that this is about the bundled
CalendarMonthView.
I stand corrected, ResourceServer.allow {} isn't necessary because
CalendarMonthlyView.init does the needful.
Cheers, Indrajit
On Aug 30, 9:32 pm, marius d. marius.dan...@gmail.com wrote:
No you don't have to do this because In Boot you are already calling
CalendarMonthlyView.init
Br's,
Marius
On Aug 30, 7:22 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote:
4. Additionally, you have to add this in Boot environment. Often we
end up missing out on this step, or don't get the pattern right :)
ResourceServer.allow {
case _ :: style.css :: Nil = true
}
Of course, you can narrow the PF argument to better adjust to the
need.
Cheers, Indrajit
On Aug 27, 9:06 pm, Marius marius.dan...@gmail.com wrote:
Someone encountered the problem where he couldn't override the
stylesheet used by some widget. Damn I can't find any more that
thread ...
Anyways here it is:
1. Include the widget in your application say monthview.
2. The url to the stylesheet is: /classpath/calendars/monthview/
style.css
3. In order to override this put your changed style.css in WEB-INF/
classes/toserve/calendars/monthview/style.css
This works for me.
Br's,
Marius
--~--~-~--~~~---~--~~
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: Question about Lift/Scala Lift Discussion Board
Personally I like mailing lists .. I find it easier for me to try to help people then a traditional forum. For someone who wants to lear Lit perhaps a more traditional forum is more helpful? ... don't really know .. I guess it depends on the person. Br's, Marius On Aug 30, 10:10 pm, Artem art...@gmail.com wrote: The problem is that this Google Group is not user friendly and not organized. I think it will be better to have a user friendly forum where everything is organized according to its category and easily accessible. This group is hard to find and hard to search. On Aug 30, 3:00 pm, Charles F. Munat c...@munat.com wrote: Just my two cents, but I think establishing a separate forum at this point is a mite premature. What problem, exactly, is it that we're trying to solve? Chas. Naftoli Gugenheim wrote: Once again, I don't see how you can discuss it until you know that David's fine with it. Personally I haven't read any concrete benefit (I don't know what take the load off or get more sites out there mean practically) that isn't available now between the list an the wiki---certainly not to outweigh the very clear disadvantage to both posters, who have that much less of a chance getting an answer in any one place and may have to ask twice, as well as to experts who can either only monitor one site and leave the other site with fewer experts; or be inconvenienced to monitor both. How many members are there of the Google Group currently? And what percentage ever offer answers? Regularly? The lift community is not as large as many other communities. Does Scala itself have other forums besides its own lists? If so what is their state? Certainly the Scala community is much larger than lift's. (Maybe you should make your forum be a Scala forum, and have a lift category... But again, I think it's only fair to ask lift's mastermind first!) - marius d.marius.dan...@gmail.com wrote: My 2 cents if I may ... Although I love this list and this is the official Lift list and support I think it is important to also have other wiki's, forums etc. out there. Personally I don't see this as a community split. More and more people are becoming pretty knowledgeable with Lift Scala sharing information about Lift on other channels ... is nothing wrong with that .. .quite the opposite. In fact this may take some of the load on this list as community grows. Would be nice though to have a central place where all other wiki's/ forums can be found. For instance serious forums/wikis could be references from lift web-site or even fromthis list in the header section. Br's, Marius On Aug 30, 8:37 am, Naftoli Gugenheim naftoli...@gmail.com wrote: The lift community is not huge. It's David Pollak's brainchild, and I don't see how you can discuss creating a forum (after the fact) without his okaying it. How can you compare it to an IRC? A forum fills much of the same purpose as the list, much more than IRC. Some of the advantages mentioned are better solved by a Wiki. (Your volunteering to help with it is much appreciated.) Searchability - sounds like a bug on Google's part, no? Is there a Group for discussing Google Groups? In any case, it's addressed by services like MarkMail. Isn't Nabbles searchable? Duplicate questions - forums don't completely solve this. Searchability would help, as will the Wiki as it grows. Stickies - Google Groups doesn't allow stickies? Syntax highlighting/formatting; organization - the way I see it, you can draw a continuum with IRC being the most transient and a Wiki etc. the most permanent, with a mailing list, a Google Groups mailng list, and a forum falling in between, in increasing order of permanence/organizability. As you go from left to right you get more of these features, but a forum is still less than a Wiki. On the other hand as you go right to left you get more dynamic/on the fly--you just write a question without worrying about organization or formatting. Does that make sense? - Xavi Ramirezxavi@gmail.com wrote: I applaud Artem's initiative! The mailing list has undoubtedly been an extremely helpful resource. That said, a mailing lists in general have several short comings: - Hard to search through - Many duplicate questions - No stickies - No syntax highlighting and few formatting options - Little to no message organization - Few moderation tools A forum could be a nice way to address these issues, so it might be worth a try. Also I think introducing a forum is anymore likely to splinter than an IRC chat room. Just my two cents. -Xavi On Sat, Aug 29, 2009 at 8:22 PM, Timothy Perretttimo...@getintheloop.eu wrote: Agreed (and +1) -
[Lift] Re: Dependency Injection in Lift
On Aug 30, 9:03 pm, Chris Lewis burningodzi...@gmail.com wrote:
I am specifically talking about decoupling my web logic, ie, event
handlers for forms in lift snippets, from the persistence layer. As
currently implemented, snippets know exactly what persistence mechanism
is in use because there is no intermediary API. If I'm using Mapper, my
snippets must use the Mapper api. If JPA, the global EM wrapper Model.
The same, I imagine, holds true for the Record api.
Why do you say this holds true about Record? ... Recourd is not bound
to any persistence technology. If you are concerned about Mapper,
means to me that you want a complete abstraction such that you can
replace JDBC with something totally different. Ok, but what stops you
from invoking the Mapper from layer abstracted by application specific
traits?
This makes the
persistence layer a Leaky Abstraction
(http://en.wikipedia.org/wiki/Leaky_abstraction), and I want to avoid that.
Most of DI of Lift is currently done using PartialFunction-s and
Function lists that people can set in Boot or for snippets in case on
binding functions usign SHtml helpers etc.
Ok, but how does that help me decouple my web logic from the persistence
details?
The statement was about Lift's DI beyond the context of persistence.
If you want your snippets to not know about Mapper abstract the Mapper
wok with your own traits ... could use a Factory pattern or something
similar.
What we've learned with Lift is the it is OK to give to persistence
objects understanding of rendering. Having dumb objects that carry on
just data and rely of layers that can do different jobs (render,
persist) is IMO not a very good design approach.
I disagree. An entity, like Author, is nothing more than an expression
of a real-world concept modeled in code. It should know about itself,
its direct constituents (like a Book collection), anything else that
defines its own semantics, and nothing more. How it is stored is none of
its business.
I didn't quite expect that you would :). We found Lift's approach to
be quite productive in real life apps.
Don't misunderstand me - I accept that I may be missing something. We
agree that the concept of DI is valuable because it helps us keep
abstractions loosely coupled. I don't see the problem with annotations,
but I am not at all married to them.
No worries I think your approach for a debate is a very healthy one.
Having different opinions is OK. I explained one of the problems with
annotations in Scala
* The other problem with annotations is that we can't currently
build annotations in Scala to be visible at runtime, so we'd probably
have to code them in Java or use some existent Java annotations ...
but this already smells hacky IMHO.
You point at partial functions and traits to implement abstractions over
the persistence layer, but what is missing is how to apply that to
snippets. Yes, I could abstract the layer however I want, but my
snippets we still be required to get at the layer by calling it
directly, instead of having it provided. Can you share some input on
that part?
def mySnipetFunc(xhtml: NodeSeq) : NodeSeq = {
val persistence = MyPersistenceFactory.getPersistence();
...
persistence.getBy( --- some predicate ---)
...
}
This is a trivial model ... but in most cases this would be enough. In
many cases I don't really need something that injects a reference to
an annotated class member.
One other approach would be to use a RequestVar or a SessionVar to
hold a Persistence reference and you can access it from different
places. You could set the proper context for such var-s from from our
LoanWrapper added in boot by calling S.addAround.
Thanks for the discussion,
chris
marius d. wrote:
Most of DI of Lift is currently done using PartialFunction-s and
Function lists that people can set in Boot or for snippets in case on
binding functions usign SHtml helpers etc.
Personally I'm not at all a fan of Pojo/Poji DI by annotations
especially in Scala realm where there are other artifacts such as
function composition, monads, mixin composition, higher order
functions etc. The other problem with annotations is that we can't
currently build annotations in Scala to be visible at runtime, so we'd
probably have to code them in Java or use some existent Java
annotations ... but this already smells hacky IMHO.
If enterprise folks solve one problem by DI by annotation it doesn't
mean that this fits in all contexts.Persistence loosely coupling can
be achieved in many ways:
1. Implement your own persistence semantic on top of Record
2. Implement your own traits hence your own abstractions
3. etc
What we've learned with Lift is the it is OK to give to persistence
objects understanding of rendering. Having dumb objects that carry on
just data and rely of layers that can do different jobs (render,
persist) is IMO not a very good design approach
[Lift] Re: Creating your own tags?
Tim, obscuring things may get you a really long way indeed. But once the obscurity get broken and people figure out that they can do other things by using strange undocumented tags (i.e lift tags) they could cause lots of problems and side effects. Personally I'd stay away from it. And if I'd need to create a CMS templating mechanism with special nodes I'd probably create one separated from Lift's templating engine as parsing XML in Scala is pretty easy, and you can safely add CMS content specific semantics without worrying about anything else. Such templating system would be nothing more then a transformation between the CMS language to the one understood by Lift. But that's just me ... Br's, Marius On Aug 29, 2:22 am, Charles F. Munat c...@munat.com wrote: Security by obscurity, eh? Timothy Perrett wrote: Its not that I want to completely stop the normal lift tag processing, I don't, I just want to make it appear to users as if they are not using lift... That might sound crazy, but essentially I want users to only know about that tags they are told about, rather than having obvious access to all the lift default stuff. Yes, ok, they could do some research and dig it out, but in my experience if it is not staring users in the face, only a few of them will go looking any deeper. Does that make any sense what-so-ever? Cheers, Tim On 28/08/2009 21:47, marius d. marius.dan...@gmail.com wrote: Hey Marius Firstly I agree with your thoughts on LiftTagPF - im not sure that overriding the default lift tags would ever be a good idea for implementing users... Well I was referring to overwriting (as those would take precedence over builtin snippets) ... not much of an overriding. However, I do see a use case, in, for instance the CMS arena where having a specialized tagging mechanism would be beneficial because you simply wouldn't want to use the default lift namespace so that users could just do: lift:comet type=Whatever / All over their template code - you'd want to restrict what users could actually do whilst still keeping the templates designer friendly. Such restrictions could be very tricky to achieve if the CMS template is processed by Lift engine. Perhaps for specialized CMS templates a dedicated templating definition and engine is more appropriate in order to strictly process given tags that define the CMS templating language? This is one use case, and in my particular circumstances, I want to provide a degree of functionality that is succinctly separate from the lift functionality and I don't want the twain to meet (as it were) but its important for my purposes at least that the templates still play well with tools such as Dreamweaver (just as the lift tags do) What are your thoughts? Related to my notes above if you define a set of tags for your CMS template and you run that against Lift's templating engine how do you prevent lift specific tags to be executed? --~--~-~--~~~---~--~~ 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: Searching this Group
Damn that's great stuff ... I was searching a couple of days ago for some thread and couldn't find it period. Thanks a lot Ryan :) Br's, Marius On Aug 29, 12:02 am, Ryan Donahue donahu...@gmail.com wrote: Search this group doesn't always work. I found this by searching for the term fade, recalling a discussion Marius posted about fading out messages. Search this group does not find the discussion, but you can find the discussion by changing the search criteria to fade group:liftweb and use the Search Groups button. Here's a very short screencast (28sec) showing the problem and solution:http://www.utipu.com/app/tip/id/15703/ I hope this helps somebody else find what they are looking for. Maybe it's why there are so many duplicate questions posted. --~--~-~--~~~---~--~~ 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: Deleting elements after a modal confirmation dialog
In such cases IF you also need to send an ajax request you can also use the SHtml.ajaxButton that takes a Call as an argument. See this thread: http://groups.google.com/group/liftweb/browse_thread/thread/f7a5eb09a756e076/009d5802f7652669?hl=enlnk=gstq=Call#009d5802f7652669 Br's, Marius On Aug 30, 12:31 am, Ross Mellgren dri...@gmail.com wrote: Well it depends on how your dialog works... if you need a JS function that calls back to the server, use SHtml.ajaxInvoke. If you want a button element that does the same thing, use SHtml.ajaxButton. If that doesn't help you, please post what code you do have or an example of what you want. -Ross On Aug 29, 2009, at 5:23 PM, Channing Walton wrote: I'm a bit stumped as to how to proceed with the following. I have a page which shows a list of items, each of which can be deleted. When the user clicks the delete button next to an item, I would like to open a confirmation dialog and if they confirm, call a backend function to delete the corresponding object, and then delete the item's row in the list. I have managed to integrate the modal confirmation example shown here: http://demo.liftweb.com/rhodeisland Everything works except I cannot figure out how to call some javascript when the user clicks the 'yes' button to update the list. Help and pointers much appreciated, I really am stumped. Channing --~--~-~--~~~---~--~~ 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: authentication and access control
I'm not sure you HTTP authentication is what your looking for. Lift has support for both BASIC and DIGEST authentication models (irrespective of any persistence technology) and you can grant access based on Roles defined as a hierarchical structure. See /examples/http-authentication application. As far as Mapper goes it has a built in ProtoUser implementation for login, registration, forgot password etc. Br's, Marius On Aug 28, 4:42 am, Chris Lewis burningodzi...@gmail.com wrote: Lift users, I'm curious what you all are using for user access control (Mapper users excluded). I'm seriously evaluating lift for a project that will use JPA. My full time job uses Spring Security, which while nice in that it stays out of the way, is too clunky for my tastes. I haven't dissected how lift implements it with Mapper, but wanted to ask the group first. Thanks! chris --~--~-~--~~~---~--~~ 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 use thread in lift
Why don't you use scala actors? ... and after you populate asynchronously the two lists do you need to report the lists back to client asynchronously (say Comet) or when the page is rendered? ... If it's the later that you'd probably need a count-down-latch or a cyclic barrier. Br's, Mairus On Aug 28, 12:05 pm, pravin pravinka...@gmail.com wrote: Hi, i want to use thread in my lift application. I have two Lists i.e. List1() and List2(); when i click on submit button i want to do following things - i am executing to method to populate above to list -; List1() = fun1(); List2() = fun2(); So i want to do above things with thread s thread 1 will do List1() = fun1(); and thread 2 will do List2() = fun2(); so i can increase performance of my application Note:serial execution is working Is this possible with lift --~--~-~--~~~---~--~~ 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: Db.addLogFunc
EXCELLENT WORK DEREK !
On Aug 28, 7:28 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
Hi all,
I've made a change to the Mapper logging functionality in
wip-dcb-sql-log-wrappers. The DB.addLogFunc method has changed to:
addLogFunc( f: (DBLog,Long) = Any)
where DBLog is a new trait (below) and the Long corresponds to the *total*
duration of a given DB execution method. DBLog is defined as:
trait DBLog {
... private stuff up here ...
/** Return a list of all of the DBStatementEntry instances in the log
buffer */
def statementEntries : List[DBStatementEntry] = ...
/** Return a list of all of the DBMetaEntry instances in the log buffer */
def metaEntries : List[DBMetaEntry] = ...
/** Return all log buffer entries */
def allEntries : List[DBLogEntry] = ...
}
and we have some new event class/traits:
trait DBLogEntry {
def statement : String
def duration : Long}
object DBLogEntry {
def unapply(obj : Any) = obj match {
case entry : DBLogEntry = Some(entry.statement,entry.duration)
case _ = None
}}
case class DBStatementEntry(statement : String, duration : Long) extends
DBLogEntry
case class DBMetaEntry(statement : String, duration : Long) extends
DBLogEntry
Statements are SQL statements, prepared or immediate, and meta entries
correspond to things like getMaxRows, getGeneratedKeys, etc. As you can see,
each individual statement records its own duration as well, so you can get
fine-grained detail on all activity. An example log function in Boot could
look like:
DB.addLogFunc {
case (query, time) = {
Log.info(All queries took + time + ms: )
query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
Log.info(stmt + took + duration + ms)})
Log.info(End queries)
}
}
And we get output like:
INFO - All queries took 17ms:
INFO - Exec update INSERT INTO users
(lastname,locale,password_pw,password_slt,validated,uniqueid,timezone,firstname,email,superuser,textarea)
VALUES
(C,en_US,GzwLqDpmJ6TrECg06bGKvOAQxyc=,1JTAWGSSYLJHXASO,1,DU0G0RT3IFOA0NHSY5QQQTX42BOIHDGI,US/Mountain,D,
d...@c.com,0,) : updated 1 rows took 9ms
INFO - Get generated keys : rs =
oracle.jdbc.driver.oraclereturnresult...@23f9e6e5 took 2ms
INFO - Closed Statement took 0ms
INFO - End queries
Note that this code does introduce a breaking change if you're already using
log functions, since the addLogFunc signature has changed. If I can get a
review on the code before I merge to master I would appreciate it.
Derek
On Sat, Aug 15, 2009 at 8:02 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
OK, a preliminary version of log wrappers is checked in on
wip-dcb-sql-log-wrappers. I'll merge it on Tuesday if no one sees any
problems with it.
Derek
On Tue, Aug 11, 2009 at 11:08 AM, Derek Chen-Becker dchenbec...@gmail.com
wrote:
Will do.
On Tue, Aug 11, 2009 at 2:33 AM, marius d. marius.dan...@gmail.comwrote:
Please do so. If you need any help for some reason (time availability
etc.) please let me know. As a note probably the wrappers should be
only only when there is at least one log function registered.
Br's,
Marius
On Aug 6, 11:48 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
If there's a consensus that we want our own JDBC wrappers I'll go ahead
and
write them.
Derek
On Thu, Aug 6, 2009 at 1:19 PM, marius d. marius.dan...@gmail.com
wrote:
Probably building our own wrappers would be more lightweight then
3-rd
party. Jus' guessing
Br's,
Marius
On Aug 6, 9:58 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
Well, I started looking at it and determined that the only way for
us to
truly log the queries would be to essentially make our own wrappers
over
Statement and PreparedStatement. There are projects (log4jdbc,
notably)
that
already do this, and in a transparent manner. I'm not sure that
adding a
whole bunch of SQL logging directly to Lift is better than
leveraging
some
existing libraries to do it.
Derek
On Thu, Aug 6, 2009 at 11:03 AM, marius d.
marius.dan...@gmail.com
wrote:
Yeah we're aware of that. That is based on toString application
which
is JDBC driver dependent. I think Derek started some work on this
to
correct this behavior. Derek ?
Br's,
Marius
On Aug 6, 8:01 pm, jon jonhoff...@gmail.com wrote:
Hi,
I have the following in boot:
DB.addLogFunc((query, len) = Log.info(The query: +query+
took
+len+ milliseconds))
I was expecting the query parameter to be sql, but it's
actually some
sort of guid
INFO - The query: 6839c016-0122-f09a-9c96-003844e8 took 5
milliseconds
Any ideas?
I'm running with derby.
Thanks,
Jon
--~--~-~--~~~---~--~~
You received this message because you
[Lift] Re: Creating your own tags?
Personally I'm not a fan of such feature. To me this doesn't bring much benefits especially that snippets pretty much allow this support such as: lift:MySnippet something:notlift attr=whatever / /lift:MySnippet ...yes the wrapping tag is extra typing but still I can't find a real problem where a custom tags solves it and snippets do now. To me this looks like ... what I'd call a false sense of extensibility. I mean at the first glance we allow people to define a tag soup (with or without naming overlaps) but then looking closely is that we didn't actually do too much. Snippets would do the job in a more standardize lift way IMO. For what I can tell the LiftRules.LiftTagPF should probably be deprecated. The debatable value that I could currently find in LiftTagPF is that people could overwrite Lift built in snippets with some proprietary implementation. However in practice this is not really needed .. I think. All in all I'd love to see some types of problems where custom tags would be a better fit. Br's, Marius On Aug 28, 7:30 pm, Timothy Perrett timo...@getintheloop.eu wrote: Hey David, Id like to echo your thoughts - I see no issue with views being tied to plugins or other such arbitrary tags... as you say, they are already tied to snippets. What are your thoughts on how arbitrary tag / prefix support could be implemented? Cheers, Tim There's been some discussion of this feature in the past. The generally outcome is that cost of prefix/label soup would become very confusing because the views become tied to plugins (although this seems weird to me because views are tied to snippets.) I think in light of the modularization discussion and the potential for snippet name overlap, it might be having the discussion about supporting arbitrary tags and arbitrary attributes in Lift's templating system. Anybody have thoughts? --~--~-~--~~~---~--~~ 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: Creating your own tags?
On Aug 28, 11:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: Hey Marius Firstly I agree with your thoughts on LiftTagPF - im not sure that overriding the default lift tags would ever be a good idea for implementing users... Well I was referring to overwriting (as those would take precedence over builtin snippets) ... not much of an overriding. However, I do see a use case, in, for instance the CMS arena where having a specialized tagging mechanism would be beneficial because you simply wouldn't want to use the default lift namespace so that users could just do: lift:comet type=Whatever / All over their template code - you'd want to restrict what users could actually do whilst still keeping the templates designer friendly. Such restrictions could be very tricky to achieve if the CMS template is processed by Lift engine. Perhaps for specialized CMS templates a dedicated templating definition and engine is more appropriate in order to strictly process given tags that define the CMS templating language? This is one use case, and in my particular circumstances, I want to provide a degree of functionality that is succinctly separate from the lift functionality and I don't want the twain to meet (as it were) but its important for my purposes at least that the templates still play well with tools such as Dreamweaver (just as the lift tags do) What are your thoughts? Related to my notes above if you define a set of tags for your CMS template and you run that against Lift's templating engine how do you prevent lift specific tags to be executed? Cheers, Tim On Aug 28, 5:48 pm, marius d. marius.dan...@gmail.com wrote: Personally I'm not a fan of such feature. To me this doesn't bring much benefits especially that snippets pretty much allow this support such as: lift:MySnippet something:notlift attr=whatever / /lift:MySnippet ...yes the wrapping tag is extra typing but still I can't find a real problem where a custom tags solves it and snippets do now. To me this looks like ... what I'd call a false sense of extensibility. I mean at the first glance we allow people to define a tag soup (with or without naming overlaps) but then looking closely is that we didn't actually do too much. Snippets would do the job in a more standardize lift way IMO. For what I can tell the LiftRules.LiftTagPF should probably be deprecated. The debatable value that I could currently find in LiftTagPF is that people could overwrite Lift built in snippets with some proprietary implementation. However in practice this is not really needed .. I think. All in all I'd love to see some types of problems where custom tags would be a better fit. Br's, Marius On Aug 28, 7:30 pm, Timothy Perrett timo...@getintheloop.eu wrote: Hey David, Id like to echo your thoughts - I see no issue with views being tied to plugins or other such arbitrary tags... as you say, they are already tied to snippets. What are your thoughts on how arbitrary tag / prefix support could be implemented? Cheers, Tim There's been some discussion of this feature in the past. The generally outcome is that cost of prefix/label soup would become very confusing because the views become tied to plugins (although this seems weird to me because views are tied to snippets.) I think in light of the modularization discussion and the potential for snippet name overlap, it might be having the discussion about supporting arbitrary tags and arbitrary attributes in Lift's templating system. Anybody have thoughts? --~--~-~--~~~---~--~~ 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: some questions on lift
Tim has a magic articles bag :) On Aug 27, 4:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: Checkout my article here on how to localize with Lift: http://is.gd/1NXGN Cheers, Tim On 27/08/2009 14:08, surfman chinasmile...@gmail.com wrote: 3) internationalization support. how does lift support this? --~--~-~--~~~---~--~~ 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: CSS Override
I'll take a look and get back to you. A resource is eventually read using container's provided API (from the ServletContext.getResourceXXX functions). The container first locates a resource from WEB-INF/ classes folder and then it looks up in the jar files. Br's, Marius On Aug 26, 8:39 am, Shane Gill tothegi...@gmail.com wrote: Hi, I've been working through the book Exploring Lift. I'm trying to override the CSS file for a CalendarMonthView widget without any luck. The book says: provide your own style.css file under the WEB-INF/classes/calendars/ monthview directory in your project I have done this but the style doesn't change. I have tried messing with different paths and ResourceServer.allow but no dice. Any help would be much appreciated Cheers, Shane --~--~-~--~~~---~--~~ 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: Codebase Organization...
renaming sites to examples would probably be more obvious for people. So fine by me. About archetypes thingy that's an interesting idea. I like it. Br's, Marius On Aug 26, 12:39 pm, Timothy Perrett timo...@getintheloop.eu wrote: Chaps, Any objections to me renaming sites to examples? Moreover, I want to move some of these so called examples to be archetypes as it strikes me that they are better starting points than anything else (e.g. HTTP Auth, PayPal etc) Thoughts? Cheers, Tim --~--~-~--~~~---~--~~ 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: Submit to different page
Well you can put a regular lift form that submits to itself in terms or URI, do the computation in your processing function and redirect- with-state to your new page. So this would imply a redirect which one can say that it is suboptimal as it implies one additional request. Personally I see no reason why not allowing for non-ajax form to have a different user-specified action attribute. So IMO we could add this support quite easily. If someone thinks that we shouldn't do this, I'd love to see the arguments. Br's, Marius On Aug 25, 10:38 am, Ulises ulises.cerv...@gmail.com wrote: Hey people, I'm trying to have a form be submitted to a different page (so, not a POST/GET back). The scenario is a search form which renders on a front page as well as on the search page. E.g.: /index should include a form that submits to /search /search form that submits to itself Any hints on how to do this/were to look to learn how to do this? I guess that the form on the front page could be just static HTML however I'm not entirely sure how /search would deal with the form submission from a static form ... Cheers, Ulises --~--~-~--~~~---~--~~ 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: Submit to different page
Something like that yes. Of course if action is missing current behavior will apply. Br's, Marius On Aug 25, 12:34 pm, Timothy Perrett timo...@getintheloop.eu wrote: Marius, So to clarify, your proposing: lift:MySnippet form=post action=??? Cheers, Tim On 25/08/2009 10:24, marius d. marius.dan...@gmail.com wrote: Well you can put a regular lift form that submits to itself in terms or URI, do the computation in your processing function and redirect- with-state to your new page. So this would imply a redirect which one can say that it is suboptimal as it implies one additional request. Personally I see no reason why not allowing for non-ajax form to have a different user-specified action attribute. So IMO we could add this support quite easily. If someone thinks that we shouldn't do this, I'd love to see the arguments. Br's, Marius On Aug 25, 10:38 am, Ulises ulises.cerv...@gmail.com wrote: Hey people, I'm trying to have a form be submitted to a different page (so, not a POST/GET back). The scenario is a search form which renders on a front page as well as on the search page. E.g.: /index should include a form that submits to /search /search form that submits to itself Any hints on how to do this/were to look to learn how to do this? I guess that the form on the front page could be just static HTML however I'm not entirely sure how /search would deal with the form submission from a static form ... Cheers, Ulises --~--~-~--~~~---~--~~ 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: Submit to different page
Sure this is totally doable but I think we should be able to support the case above where a form can submit to a different page. Br's, Marius On Aug 25, 2:05 pm, Timothy Perrett timo...@getintheloop.eu wrote: Ulises, Am I missing something? There is nothing stopping you making a URL like: /search?for=Some+Term You can do that as it stands today... Just read in the parameter using S.param(for) //= Box[String] Seems like this would be the easiest route, no? Cheers, Tim On 25/08/2009 11:15, Ulises ulises.cerv...@gmail.com wrote: lift:MySnippet form=post action=??? Interestingly enough that's the first thing I tried. I'm sure that there are good reasons for the restriction that I'm overlooking. As for the redirection solution, I did think about that and that would equate (someone please correct me) to a GET with parameters which (apparently) is the way to deal with search form submissions (because of reloads, blah blah). If my vote counts for anything lift:MyClass form=post|get action=other_url would get my +1 Cheers, Ulises --~--~-~--~~~---~--~~ 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: Notes from 8/19/09 Lift Committers Call - LIFT SESSION REPLICATION DISCUSSION
I understand your thoughts David ... but I'm not convinced that Java
serialization is the way to go. A more efficient serialization of the
dependency graph sounds more appropriate but also quite complex.
Br's,
Marius
On Aug 25, 12:42 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Mon, Aug 24, 2009 at 12:58 PM, Meredith Gregory lgreg.mered...@gmail.com
wrote:
David,
Can one leave proxies in place for things that are not actually
serializable?
Anything that's marked serializable should be... and it's up to the thing
that marks itself as serialiable to create a proxy. Things that are not
marked as serializable may or may not be... the issue is what kind of
instance variables they have to determine if they could be serialized.
Best wishes,
--greg
On Mon, Aug 24, 2009 at 12:55 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
On Mon, Aug 24, 2009 at 12:36 PM, marius d. marius.dan...@gmail.comwrote:
Just a FYI. I briefly talked with Martin and he said this idea is
possible but quite tricky. Stephane Micheloud did something similar
and he may share some of his work. I'm waiting some feedback from him.
I think we can do it at runtime in development mode. This is just for
data gathering, not for actual implementation. We just need to calculate
whether a given class is serializable once... so we don't have to worry
about cyclic graphs or anything else... just... are the slots (instance
variables) for each class serializable.
Br's,
Marius
On Aug 24, 10:46 am, marius d. marius.dan...@gmail.com wrote:
On Aug 24, 10:39 am, Viktor Klang viktor.kl...@gmail.com wrote:
On Mon, Aug 24, 2009 at 8:13 AM, marius d. marius.dan...@gmail.com
wrote:
On Aug 24, 12:06 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Sun, Aug 23, 2009 at 10:45 AM, marius d.
marius.dan...@gmail.com
wrote:
Hmmm .. I'm wondering if we can write aScalacompilerpluginthat
transform functions provided to Lift's S/SHtml function etc.
into a
richer FunctionX implementation that knows how to serialize
it's
members. We could restrict the types that as LiftSerializable
on top
of primitives, Calenars, SessionVar/RequestVar etc. If users
need
their own classes to be LiftSerilizable they would have to
implement
LiftSerializable trait.
I think we can do it without explicit traits. I think we just
need to
walk
the graph for everything that's added to the LiftSession and see
where it
leads. Any graph we can walk is something that we can
serialize... even
without Java serialization. Any graph that ends in globals or
some class
that refers to native stuff (e.g., IO), then we're toast.
Totally agree. The rationale for explicit LiftSerializable would be
just for user defined types. Otherwise user's won't have to use it.
Graphs may also have be cyclic paths ... it shouldn't be too big of
a
pain though. Furthermore if a dependency graph path leads say to an
IO
reference maybe that's unintentional user code doesn't really use
that
but compiler put it for whatever reason. If such cases are possible
and could be determined maybe we could exclude that silently from
the
serialization operation and add a compile time warning.
I guess we need to dig more intoscalacompilerpluginsystem.
1. Isn't there a problem with references _inside_ methods that are
impure/sideeffecting?
s = { Db.myCachedInfoNotInSession foo s }
Regarding member references, a simple check for transient
(sca...@transient == java *transient*) to forcve people to use
transient
members for non-serializable state.
But IMHO the serialization problem is a (negative?) sideeffect of
Lifts rich
model GUID=Func approach.
Perhpas there is a middle way, a way where we can replicate just
enough to
survive a node crash?
That's exactly it. We probably don't need everything that Java
Serialization does. Just enough to make it consistent ... the
dependency graphs that is actually used by the user's function.
Thoughts?
Br's,
Marius
On Aug 23, 8:30 pm, marius d. marius.dan...@gmail.com
wrote:
At a first glace Java serialization is needed because of its
awareness
of the reference graph. But in the same time it does not
perform
well.
One way might be the byte level instrumentation that would
induce
code
to figure out the reference graph and know how to stream-ify
it using
a given efficient protocol. But that induces risks and it
involves
tons of work. I think would be doable though.
The problem is not really the technology of propagating
session
information to other nodes. That's the easiest part, but
tough one is
figuring out the low level reference graph
[Lift] Re: Submit to different page
1. I just pushed a little change that allows:
lift:MySnippet form=post action=/search
...
/lift:MySnippet
2. You can also do
form method=post action=/search
lift:mysnippet
f:inputSearch/
f:submit/
/mysnippet
/form
In both cases you can use Lift's html abstractions such as SHtml.text
etc. and bind your function. In the second example we used a snippet
that has no idea about form ... it is just wrapped by a form. So in
both cases you don't really need to call S.attr to manually get
parameters.
Br's,
Marius
On Aug 25, 6:24 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
On Tue, Aug 25, 2009 at 12:38 AM, Ulises ulises.cerv...@gmail.com wrote:
Hey people,
I'm trying to have a form be submitted to a different page (so, not a
POST/GET back). The scenario is a search form which renders on a front
page as well as on the search page.
E.g.:
/index
should include a form that submits to /search
/search
form that submits to itself
form method=post action=/searchinput type=text name=search
value=/input type=submit value=Search//form
In the snippet that handles the search page:
val searchTerm = S.param(search) openOr {S.error(no search term);
S.redirectTo(S.referer openOr /)}
Any hints on how to do this/were to look to learn how to do this? I
guess that the form on the front page could be just static HTML
however I'm not entirely sure how /search would deal with the form
submission from a static form ...
Cheers,
Ulises
--
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
-~--~~~~--~~--~--~---
