[Lift] Re: Facebook Application
Hello, I've been in Emacs land the past couple of days, tried it out, got lost but i've found my way back to TextMate ;) I would like to take a wack at this, but it's hard for me to estimate how much time I have to play around lift the next two weeks though - so if it isn't something that needs to get fixed right away I would like to work on it :) Thanks, Mads Hartmann Jensen On Feb 4, 10:22 am, Timothy Perrett timo...@getintheloop.eu wrote: Seems like this would be a good task to assign to one of the new / free of task committers? It probably wouldn't take a huge amount of work to clean it up right? Ideally we want to avoid having modules in Lift that are totally unsupported :-) Cheers, Tim On 3 Feb 2010, at 22:52, David Pollak wrote: The current LiftFacebooksupport is old and growing cobwebs. Jorge Ortiz, the guy who wrote most of the code, might have some additional thoughts. My suggestion is looking for a Java-based FB library and using that within your Liftapp. Sorry. David -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Mapped(Date)(Time) formatter/parser
Naftoli Gugenheim naftoli...@gmail.com writes: David and all, QUESTION 1 I'm working on issue #258. Here are two options for an overridable parser (applies to formatting too): 1. def parse(s: String): Box[Date] = ConversionRules.parseDate()(s) 2. def parse: String=Box[Date] = ConversionRules.parseDate() What are the pros and cons, and which should I use? I prefer 1) I see no reason for parse to be a function QUESTION 2 MappedDate and MappedDateTime apparently were parsing via LiftRules in setFromAny, while buildSetStringValue etc. were using (Time)Helpers.toDate. Is there a reason not to change it? Or, should toDate use ConversionRules? I think it would be natural for toDate to use ConversionRulesthen ConversionRules becomes the only place where date formatting is handled. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Mapped(Date)(Time) formatter/parser
On 05/02/10 5:28 PM, Jeppe Nejsum Madsen wrote: Naftoli Gugenheimnaftoli...@gmail.com writes: David and all, QUESTION 1 I'm working on issue #258. Here are two options for an overridable parser (applies to formatting too): 1. def parse(s: String): Box[Date] = ConversionRules.parseDate()(s) 2. def parse: String=Box[Date] = ConversionRules.parseDate() What are the pros and cons, and which should I use? I prefer 1) I see no reason for parse to be a function +1 QUESTION 2 MappedDate and MappedDateTime apparently were parsing via LiftRules in setFromAny, while buildSetStringValue etc. were using (Time)Helpers.toDate. Is there a reason not to change it? Or, should toDate use ConversionRules? I think it would be natural for toDate to use ConversionRulesthen ConversionRules becomes the only place where date formatting is handled. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Upgrade to Flot 0.6
Looks great! One little nit is, could we add the hoverable option to FlotGridOptions? That's a new feature which was added to Flot which shouldn't break backwards compatibility. Any thoughts about integrating plugins as the zooming and FlotOverview class don't work without the selecting plugin. - A On Thu, Feb 4, 2010 at 7:56 PM, Peter Robinett pe...@bubblefoundry.com wrote: Hi Aaron, I've pushed the simplest update possible to my branch here: http://github.com/dpp/liftweb/tree/pr1001_issue_322. I will make the series options change if there are no significant dissenting voices in the thread I created[1]. In the meantime, do. The flotDemo app seems to work without any changes. What do you think? Peter [1]: http://groups.google.com/group/liftweb/t/ba7e0f76042ff562 On Feb 3, 6:30 am, Aaron Valade a...@alum.mit.edu wrote: I've created a ticket here: http://github.com/dpp/liftweb/issues/issue/322 Thanks again! - Aaron On Tue, Feb 2, 2010 at 10:10 PM, Peter Robinett pe...@bubblefoundry.com wrote: You're welcome. I'm happy to look into adding Flot plugin support, but please open a ticket on GitHub (http://github.com/dpp/liftweb/issues). Peter On Feb 1, 10:22 am, Aaron Valade a...@alum.mit.edu wrote: Thanks Peter! One of the other things that changed between Flot 0.4 and 0.6 is that a plugin structure was introduced and some functionality was pushed out of the core and into a plugin, specifically the selection functionality which can be used for zooming and other interactions with the charted data. I hate to tack on requests for more work, but if you get a chance, I'd appreciate if you could add functionality to the Lift Flot Widget to allow use of these plugins. I'm in the process of making some small changes with the Flot Widget to support these plugins in my local fork of Lift and would be happy to share what I've done, if that's allowed. Otherwise, I'd be very eager to provide additional testing of any capabilities that you make available or any other help that I can provide within the guidelines of the Lift project. Thanks, - A On Mon, Feb 1, 2010 at 12:28 PM, Peter Robinett pe...@bubblefoundry.com wrote: Ok guys, I'll work on this in the next few days (I'm out of town right now). Peter On Jan 31, 3:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: It seems like peter will take ownership of this and make it happen ASAP so a patch / diff should not be needed. Peter, please confirm when you will roll this in a branch and put it on review board? Cheers, Tim Sent from my iPhone On 31 Jan 2010, at 22:48, Aaron Valade aval...@gmail.com wrote: I'm more than happy to submit the patch under the Lift IP policy, but I understand if you don't feel comfortable with that. And I can submit it anyway that works for you. I'm just looking to help give back to everyone that's helped me out. Albeit in a very, very small way. Sent from my iPhone On Jan 31, 2010, at 5:43 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Peter, Please keep in mind the Lift IP policy. We don't pull from other repositories nor do we accept patches. We'll have to do the Flot 0.6 ourselves. Thanks, David On Fri, Jan 29, 2010 at 4:44 PM, Peter Robinett pe...@bubblefoundry.com wrote: Aaron, thanks so much for taking the initiative to upgrade Flot, it's something that I've been meaning to do. Just skimming over your changes, everything looks good. As for not using the packed excanvas file, that should be ok since Lift runs the YUI compressor by default on all Javascript files (correct, David?). Of course, broken URLs need to be fixed. David, how do we go about merging these changes? Peter On Jan 29, 3:32 pm, Aaron Valade a...@alum.mit.edu wrote: There is one break that my commit made which I just realized after I had sent this email in that I deleted the excanvas.pack.js file and dropped in the excanvas.js that was included with the Flot 0.6 distribution but didn't rename it to be excanvas.pack.js and didn't change the path in the Flot.scala file. I can make an additional commit that fixes this, if it pleases the court. :-) - A On Fri, Jan 29, 2010 at 6:15 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Peter, What do you think of the upgrade (given that you're the most Flot-ish Lift committer)? Thanks, David On Fri, Jan 29, 2010 at 12:32 PM, Aaron Valade a...@alum.mit.edu wrote: Hello all, I needed to use some of the recent functionality in the Flot jQuery plugin which is version 0.6. The Flot lift-widget is currently at 0.4. So I upgraded it to use the new version and I've posted the commit on github:
[Lift] Re: Facebook Application
Hi, I have only tried to do a couple of things with the Facebook module (I'm using 2.0-M1) and I have gotten some of the stuff to actually work :) Photo upload would be something like this: import java.io.File import org.apache.commons.io.FileUtils import net.liftweb.ext_api.facebook._ import scala.xml._ FacebookRestApi.apiKey = your api key FacebookRestApi.secret = secret // Get a user to login to Facebook with a link like http://www.facebook.com/login.php?v=1.0api_key=your api key // If you mess around with the Facebook settings you will get FB to // redirect the user back to your app with a token as a query param val authToken = as described previously val client = FacebookClient.fromAuthToken(authToken).get val photo = new File(...) val bytes = FileUtils.readFileToByteArray(photo) val resp = client !? UploadPhoto(test.jpg, jpg, bytes) val photoUrl = (resp \\ link).text Getting a list of friends: val resp = client !? GetFriends() Some real documentation and examples sure would be nice! Leo On Feb 3, 9:00 am, celestocalculus celestocalcu...@yahoo.co.uk wrote: Hello, I'm an intermediate lift developer. Suddenly, it has become my first choice framework for web applications. I really think it's a nice framework you guys are doing a great job. I'm new on facebook application development and I have been looking at the liftweb facebook API. I really don't know how to put this but I'm just blank, I don't know where to start. I would really appreciate it if I get a step by step explanation. All the book I got on facebook apps are on php and I find it difficult to match the php codes to their corresponding lift counterparts. Please I'll also appreciate sample codes, please let it be step by step and on point. 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 lift...@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] LiftRules inconsistencies (including FactoryMaker grump)
Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? For example: LiftRules.stripComments.default.set(() = false) This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: LiftRules inconsistencies (including FactoryMaker grump)
Yeah it is not clear to me why not just using function like: LiftRules.stripComments: () = Boolean Maybe I missed previous talks, or just not remember it it doesn't look that API simplified or became more intuitive by adding FactoryMakers ... Br's, Marius On Feb 5, 5:35 pm, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? For example: LiftRules.stripComments.default.set(() = false) This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: LiftRules inconsistencies (including FactoryMaker grump)
If I remember correctly, it was a result of some fairly well-made dependency injection arguments around testing and fully mocking the lift pipeline / process. I agree though, its a fairly crappy API. Cheers, Tim On Feb 5, 3:38 pm, Marius marius.dan...@gmail.com wrote: Yeah it is not clear to me why not just using function like: LiftRules.stripComments: () = Boolean Maybe I missed previous talks, or just not remember it it doesn't look that API simplified or became more intuitive by adding FactoryMakers ... Br's, Marius On Feb 5, 5:35 pm, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? For example: LiftRules.stripComments.default.set(() = false) This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Accessing innerHTML during bind?
Thanks for the suggestions. I knew it was not the most efficient,
however, we don't have many products.
On Feb 4, 3:39 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
On Thu, Feb 4, 2010 at 7:32 AM, Ross Mellgren dri...@gmail.com wrote:
I think this new version will be slower than your original one, as each
call to bind will visit the entire input XHTML. Why not use your original
formulation but instead of TheBindParam, use FuncBindParam (which is the
sugar-free version of body = ... that David describes)?
Yeah... the bind operation is O(n log m) where 'n' is the number of element
nodes and m is the number of things to be bound. Using foldLeft, you're
making that O(n m) Then again, if the code is understandable for you, then
a couple of nanoseconds here and there are not overly important.
-Ross
On Feb 4, 2010, at 10:28 AM, Tim Maxwell wrote:
Hi David,
There really are a lot of paths available with scala/lift, aren't
there?
After looking at what you wrote, here's what I came up with that works
well/is functional and compact, in case anyone else is wondering about
it.
def links(html:NodeSeq): NodeSeq={
Product.findActive.foldLeft(html) {
(html, prod) = bind(links,html,
force_+prod.product -{x:NodeSeq = {a href={/forced?
product=+prod.product}{x}/a}}
)
}
}
Product is a JPA entity class, findactive returns a list of products.
If anyone has suggestions, please share.
Cheers,
Tim
On Feb 3, 5:08 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
On Wed, Feb 3, 2010 at 12:44 PM, Tim Maxwell truthspi...@gmail.com
wrote:
Hi folks,
I am trying to do binds based on a list of products. The point is to
create links that can be wrapped around existing text or images.
Something like this:
signup:links.force_PRODThis is the link text our marketing dept.
creates/signup:link
Here's what I have so far in the snippet related to it:
def links(html:NodeSeq): NodeSeq={
val productBinds:Seq[BindParam] = Product.findActive.flatMap{
prod = List[BindParam] ( TheBindParam( force_+prod.product,
SHtml.link(/forced?product=+prod.product, ()=() , _ ) ) )
}
bind(links , html, productBinds: _*)
It's so cool to see how people stuff in Lift...
Within your function, you can get the element that's being bound with:
BindHelpers.currentNode: Box[Elem]
On the other hand, if you're looking to get the children of the node
currently being bound:
FuncBindParam(force_+prod.product, body = a
href={/forced?product=+Helpers.urlEncode(prod.product)}{body}/a)
Hope this helps.
Thanks,
David
}
Cheers,
Tim
--
You received this message because you are subscribed to the Google
Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroup
s.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
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 lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
--
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 lift...@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: S.params disappear?
Hmpf. Same problem here :(
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/users/0505710286 HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /tumps-server/
api/users/0505710286 took 12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /tumps-server/api/users/0505710286 HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: S.params disappear?
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes params
available differently for PUTs than for POSTs, but Jetty does not, and I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run. Then
I
package it into a war and load it up in Tomcat 6 on the server, and
when
I
do, suddenly it won't work.
The issue is with the S.params. I have a form that submits via an
Ajax
PUT
request. The params are sent in the header just fine. As I said,
works
like a charm on Jetty. But when it gets to Tomcat, the entity is
saved
with blank attributes... i.e., everything worked but the
S.param(whatever) showed up blank. I tested this by doing
S.param(whatever).openOr(Phooey) and, indeed, that attribute was
set
to Phooey on the new entity.
Tomcat issue? Or am I missing something obvious? This form is running
on
a
subdomain, so that's where I'm looking now (in server.xml).
TIA,
Chas.
--
You received this message because you are subscribed to the Google
Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] OSGi example, what to do to make it run?
On 5 February 2010 05:00, philip philip14...@gmail.com wrote: I downloaded the git source and made a OSGi jar package by running the maven, now what do I do with it? I see its a jar file with the manifest for OSGi, I guess I can load it into Apache Felix, but doesn't Liftweb need tomcat or jetty to run? So I don't really understand how its going to run. I've also puzzled over this. I've figured out that you can point pax-runner at the hello.composite file. I'd love to see a tutorial on how experienced OSGI developers set up their the development environment, and how they work the edit/compile/redeploy cycle. It's very obvious for mvn jetty:run (just wait for the scanner, or use JavaRebel). It's not so obvious how people work with OSGI containers. The best I've figured is to use the pax assembly: stuff to point at target classes, and run update bundle-id for each edit/compile cycle - it's a bit clunky. Any offers/suggestions? (Sorry, I realise the question more about OSGI than lift) Martin -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Suggestion to extend Comet (ListenerManager) to selectively update subscribers
OK, its on RB (http://reviewboard.liftweb.net/r/206/) = Take a look ... Heiko On 5 February 2010 01:07, Timothy Perrett timo...@getintheloop.eu wrote: Probally helpful if you share your prototype code? Cheers, Tim Sent from my iPhone On 5 Feb 2010, at 00:05, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Hi, In the current state the ListenerManager will always update all subscribers. I have got a use case where only certain subscribers should be updated. Therefore I suggest to extend the ListenerManager such that there can be an optional partial function that determines which subscribers will be updated. This change will not break the current API and will not affect the default behavior. I have already implemented a prototype solution but would like to know your opinion first. So what do you think? Any objections up-front? Cheers, Heiko Work: http://weiglewilczek.comweiglewilczek.com Blog: http://heikoseeberger.nameheikoseeberger.name Follow me: http://twitter.com/hseebergertwitter.com/hseeberger OSGi on Scala: http://scalamodules.orgscalamodules.org Lift, the simply functional web framework: http://liftweb.netliftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Single Table Inheritance
This is actually fairly common that messages Naftoli sends are empty, or don't
get threaded onto the original discussion, or formatting comes out funny.
Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have broken your first message, It's a blank
message if you view it through the web-interface:
http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5dbaad4a65
If you have a solution I would love to hear it :)
On Feb 5, 1:52 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Does my approach not work?
-
Mads Hartmannmads...@gmail.com wrote:
Yeah that helped, my lab and scientist now looks like this:
/--- code
trait BaseSourceTrait[ T :BaseSourceTrait[T] ] extends
LongKeyedMapper[T] {
self: T =
override def primaryKeyField = id
object id extends MappedLongIndex(this)
object name extends MappedPoliteString(this, 256)
object sourceType extends MappedEnum(this,SourceTypes)
object SourceTypes extends Enumeration {
val Scientist = Value(Scientist)
val Lab = Value(Lab)
}
}
class Scientist extends BaseSourceTrait[Scientist] {
def getSingleton = Scientist
object birth extends MappedInt(this)
object death extends MappedInt(this)
object nationality extends MappedPoliteString(this, 128)
}
object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
{
override def dbTableName = Source
}
class Lab extends BaseSourceTrait[Lab] {
def getSingleton = Lab
object institution extends MappedLongForeignKey(this, Institution)
}
object Lab extends Lab with LongKeyedMetaMapper[Lab] {
override def dbTableName = Source
}
/--- code ends
My only problem now is that I can't figure out how to implement the
following:
A Discovery (a mapped class) needs to have a foreign key to the source
that made the discovery, this could be either a lab or a scientist, so
normally i would have a field with a reference to the super-class of
both Scientist and Lab - However, I don't have a super-class, I just
have a trait :)
I would like to be able to write something like this:
/--- code starts again
class Discovery extends LongKeyedMapper[Discovery] with IdPK {
def getSingleton = Discovery
// primatives
object description extends MappedDateTime(this)
object year extends MappedInt(this)
object reference extends MappedPoliteString(this, 128)
// relationships
object source extends MappedLongForeignKey(this, BaseSourceTrait) //
-- this is what i want.
}
object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
/--- code ends
As always I truely appreciate the help you guys are giving me :)
Thanks,
Mads Hartmann Jensen
On Feb 4, 9:56 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
Please take a look at the MegaProtoUser and MegaMetaProtoUser code for
examples of how to create traits that can be mixed into classes.
Does that help?
On Thu, Feb 4, 2010 at 9:58 AM, Mads Hartmann Jensen
mads...@gmail.comwrote:
hello Jeppe,
In my project I've got the following three models: A discovery, a Scientist
and a lab. The Discovery has been invented by someone, this is either a
single scientist or sometimes a lab - This is easily done through
inheritance (would create a superclass named source) but I'm not sure how
to
do this so it maps nicely to the database.
Scientist and Lab only share one attribute so what I'm most interested in
is to be able express that a Discovery has s source that can be either a
lab
or scientist :)
Hope this explains my problem more clearly, thanks for the help
Mads Hartmann
Sent from my iPhone
On 04/02/2010, at 18.17, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Mads Hartmann mads...@gmail.com writes:
Hello Everyone,
I'm currently trying to figure out how to map objects with inheritance
using the Mapper framework. I've got a Lab and a Scientist who inherit
from Source.
As I understand there's no direct way to do inheritance using the
Mapper framework so I'm trying to figure out how to implement 'Single
Table Inheritance'.
Right now I'm trying to create a single trait (Source) for the values
that they share called BaseSource and my idea is to mix it in both Lab
and Scientist. I would then define the table name of both scientist
and lab to be the same - I think this would work but what I'm not sure
of is the following:
- If both Scientist and Lab mixes in the IdPK trait and use the same
table, will the id still be unique?
- A Discovery has a source, how do i create MappedLongForeignKey
Re: [Lift] OSGi example, what to do to make it run?
On Feb 5, 2010, at 12:18 PM, David Pollak wrote: On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 5 February 2010 15:05, Martin Ellis ellis@gmail.com wrote: Any offers/suggestions? (Sorry, I realise the question more about OSGI than lift) Indeed, let's discuss this off-list ... Can you discuss it on-list? I'd like to learn. +1 -Ross -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: S.params disappear?
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes params
available differently for PUTs than for POSTs, but Jetty does not, and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Then
I
package it into a war and load it up in Tomcat 6 on the server, and
when
I
do, suddenly it won't work.
The issue is with the S.params. I have a form that submits via an
Ajax
PUT
request. The params are sent in the header just fine. As I said,
works
like a charm on Jetty. But when it gets to Tomcat, the entity is
saved
with blank attributes... i.e., everything worked but the
S.param(whatever) showed up blank. I tested this by doing
S.param(whatever).openOr(Phooey) and, indeed, that attribute
was
set
to Phooey on the new entity.
Tomcat issue? Or am I missing something obvious? This form is
running
on
a
subdomain, so that's where I'm looking now (in server.xml).
TIA,
Chas.
--
You received this
Re: [Lift] Re: Single Table Inheritance
Peek -- www.getpeek.com
Please forward any bad messages to feedb...@getpeek.com
-
Ross Mellgrendri...@gmail.com wrote:
This is actually fairly common that messages Naftoli sends are empty, or don't
get threaded onto the original discussion, or formatting comes out funny.
Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have broken your first message, It's a blank
message if you view it through the web-interface:
http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5dbaad4a65
If you have a solution I would love to hear it :)
On Feb 5, 1:52 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Does my approach not work?
-
Mads Hartmannmads...@gmail.com wrote:
Yeah that helped, my lab and scientist now looks like this:
/--- code
trait BaseSourceTrait[ T :BaseSourceTrait[T] ] extends
LongKeyedMapper[T] {
self: T =
override def primaryKeyField = id
object id extends MappedLongIndex(this)
object name extends MappedPoliteString(this, 256)
object sourceType extends MappedEnum(this,SourceTypes)
object SourceTypes extends Enumeration {
val Scientist = Value(Scientist)
val Lab = Value(Lab)
}
}
class Scientist extends BaseSourceTrait[Scientist] {
def getSingleton = Scientist
object birth extends MappedInt(this)
object death extends MappedInt(this)
object nationality extends MappedPoliteString(this, 128)
}
object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
{
override def dbTableName = Source
}
class Lab extends BaseSourceTrait[Lab] {
def getSingleton = Lab
object institution extends MappedLongForeignKey(this, Institution)
}
object Lab extends Lab with LongKeyedMetaMapper[Lab] {
override def dbTableName = Source
}
/--- code ends
My only problem now is that I can't figure out how to implement the
following:
A Discovery (a mapped class) needs to have a foreign key to the source
that made the discovery, this could be either a lab or a scientist, so
normally i would have a field with a reference to the super-class of
both Scientist and Lab - However, I don't have a super-class, I just
have a trait :)
I would like to be able to write something like this:
/--- code starts again
class Discovery extends LongKeyedMapper[Discovery] with IdPK {
def getSingleton = Discovery
// primatives
object description extends MappedDateTime(this)
object year extends MappedInt(this)
object reference extends MappedPoliteString(this, 128)
// relationships
object source extends MappedLongForeignKey(this, BaseSourceTrait) //
-- this is what i want.
}
object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
/--- code ends
As always I truely appreciate the help you guys are giving me :)
Thanks,
Mads Hartmann Jensen
On Feb 4, 9:56 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
Please take a look at the MegaProtoUser and MegaMetaProtoUser code for
examples of how to create traits that can be mixed into classes.
Does that help?
On Thu, Feb 4, 2010 at 9:58 AM, Mads Hartmann Jensen
mads...@gmail.comwrote:
hello Jeppe,
In my project I've got the following three models: A discovery, a Scientist
and a lab. The Discovery has been invented by someone, this is either a
single scientist or sometimes a lab - This is easily done through
inheritance (would create a superclass named source) but I'm not sure how
to
do this so it maps nicely to the database.
Scientist and Lab only share one attribute so what I'm most interested in
is to be able express that a Discovery has s source that can be either a
lab
or scientist :)
Hope this explains my problem more clearly, thanks for the help
Mads Hartmann
Sent from my iPhone
On 04/02/2010, at 18.17, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Mads Hartmann mads...@gmail.com writes:
Hello Everyone,
I'm currently trying to figure out how to map objects with inheritance
using the Mapper framework. I've got a Lab and a Scientist who inherit
from Source.
As I understand there's no direct way to do inheritance using the
Mapper framework so I'm trying to figure out how to implement 'Single
Table Inheritance'.
Right now I'm trying to create a single trait (Source) for the values
that they share called BaseSource and my idea is to mix it in both Lab
and Scientist. I would then define the table name of both scientist
and lab to be the same - I think this would work but what I'm not sure
of is the following:
- If both
[Lift] Re: Single Table Inheritance
Naftoli would you please re-post your solution :) I could really use
the help
On Feb 5, 6:56 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Peek --www.getpeek.com
Please forward any bad messages to feedb...@getpeek.com
-
Ross Mellgrendri...@gmail.com wrote:
This is actually fairly common that messages Naftoli sends are empty, or
don't get threaded onto the original discussion, or formatting comes out
funny. Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have broken your first message, It's a blank
message if you view it through the web-interface:
http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5db...
If you have a solution I would love to hear it :)
On Feb 5, 1:52 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Does my approach not work?
-
Mads Hartmannmads...@gmail.com wrote:
Yeah that helped, my lab and scientist now looks like this:
/--- code
trait BaseSourceTrait[ T :BaseSourceTrait[T] ] extends
LongKeyedMapper[T] {
self: T =
override def primaryKeyField = id
object id extends MappedLongIndex(this)
object name extends MappedPoliteString(this, 256)
object sourceType extends MappedEnum(this,SourceTypes)
object SourceTypes extends Enumeration {
val Scientist = Value(Scientist)
val Lab = Value(Lab)
}
}
class Scientist extends BaseSourceTrait[Scientist] {
def getSingleton = Scientist
object birth extends MappedInt(this)
object death extends MappedInt(this)
object nationality extends MappedPoliteString(this, 128)
}
object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
{
override def dbTableName = Source
}
class Lab extends BaseSourceTrait[Lab] {
def getSingleton = Lab
object institution extends MappedLongForeignKey(this, Institution)
}
object Lab extends Lab with LongKeyedMetaMapper[Lab] {
override def dbTableName = Source
}
/--- code ends
My only problem now is that I can't figure out how to implement the
following:
A Discovery (a mapped class) needs to have a foreign key to the source
that made the discovery, this could be either a lab or a scientist, so
normally i would have a field with a reference to the super-class of
both Scientist and Lab - However, I don't have a super-class, I just
have a trait :)
I would like to be able to write something like this:
/--- code starts again
class Discovery extends LongKeyedMapper[Discovery] with IdPK {
def getSingleton = Discovery
// primatives
object description extends MappedDateTime(this)
object year extends MappedInt(this)
object reference extends MappedPoliteString(this, 128)
// relationships
object source extends MappedLongForeignKey(this, BaseSourceTrait)
//
-- this is what i want.
}
object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
/--- code ends
As always I truely appreciate the help you guys are giving me :)
Thanks,
Mads Hartmann Jensen
On Feb 4, 9:56 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
Please take a look at the MegaProtoUser and MegaMetaProtoUser code for
examples of how to create traits that can be mixed into classes.
Does that help?
On Thu, Feb 4, 2010 at 9:58 AM, Mads Hartmann Jensen
mads...@gmail.comwrote:
hello Jeppe,
In my project I've got the following three models: A discovery, a
Scientist
and a lab. The Discovery has been invented by someone, this is either a
single scientist or sometimes a lab - This is easily done through
inheritance (would create a superclass named source) but I'm not sure
how to
do this so it maps nicely to the database.
Scientist and Lab only share one attribute so what I'm most interested in
is to be able express that a Discovery has s source that can be either a
lab
or scientist :)
Hope this explains my problem more clearly, thanks for the help
Mads Hartmann
Sent from my iPhone
On 04/02/2010, at 18.17, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Mads Hartmann mads...@gmail.com writes:
Hello Everyone,
I'm currently trying to figure out how to map objects with inheritance
using the Mapper framework. I've got a Lab and a Scientist who inherit
from Source.
As I understand there's no direct way to do inheritance using the
Mapper framework so I'm trying to figure out how to implement 'Single
Table Inheritance'.
Right now I'm trying to create a single trait (Source) for the values
that they share called BaseSource and my idea is to mix it
Re: [Lift] UML Diagram from existing lift application
On Thu, Feb 4, 2010 at 11:44 PM, Dick Hirsch hirsch.d...@gmail.com wrote: On the esme-dev mailing list, we've got a request for a class/uml diagram for our lift-based server code. Does anyone know of a tool (maven-plugin?) that could provide such functionality? I know of none. The most likely place to look is in IntelliJ-land. IntelliJ does a lot of code analysis and there may be a way to tap into this to get UMLish inforamtion. Thanks. D. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@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.
Re: [Lift] Re: Single Table Inheritance
Basically, either use two protected LongMappedMappers and a public
getter/setter that takes a boolean into account in both directions; or use a
MappedLong, with
def obj = whicheverLookUpTable.find(this.is)
and
override def set(s: Source) = s match ...
Sorry for the brevity, if unclear please ask.
-
Mads Hartmannmads...@gmail.com wrote:
Naftoli would you please re-post your solution :) I could really use
the help
On Feb 5, 6:56 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Peek --www.getpeek.com
Please forward any bad messages to feedb...@getpeek.com
-
Ross Mellgrendri...@gmail.com wrote:
This is actually fairly common that messages Naftoli sends are empty, or
don't get threaded onto the original discussion, or formatting comes out
funny. Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have broken your first message, It's a blank
message if you view it through the web-interface:
http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5db...
If you have a solution I would love to hear it :)
On Feb 5, 1:52 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Does my approach not work?
-
Mads Hartmannmads...@gmail.com wrote:
Yeah that helped, my lab and scientist now looks like this:
/--- code
trait BaseSourceTrait[ T :BaseSourceTrait[T] ] extends
LongKeyedMapper[T] {
self: T =
override def primaryKeyField = id
object id extends MappedLongIndex(this)
object name extends MappedPoliteString(this, 256)
object sourceType extends MappedEnum(this,SourceTypes)
object SourceTypes extends Enumeration {
val Scientist = Value(Scientist)
val Lab = Value(Lab)
}
}
class Scientist extends BaseSourceTrait[Scientist] {
def getSingleton = Scientist
object birth extends MappedInt(this)
object death extends MappedInt(this)
object nationality extends MappedPoliteString(this, 128)
}
object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
{
override def dbTableName = Source
}
class Lab extends BaseSourceTrait[Lab] {
def getSingleton = Lab
object institution extends MappedLongForeignKey(this, Institution)
}
object Lab extends Lab with LongKeyedMetaMapper[Lab] {
override def dbTableName = Source
}
/--- code ends
My only problem now is that I can't figure out how to implement the
following:
A Discovery (a mapped class) needs to have a foreign key to the source
that made the discovery, this could be either a lab or a scientist, so
normally i would have a field with a reference to the super-class of
both Scientist and Lab - However, I don't have a super-class, I just
have a trait :)
I would like to be able to write something like this:
/--- code starts again
class Discovery extends LongKeyedMapper[Discovery] with IdPK {
def getSingleton = Discovery
// primatives
object description extends MappedDateTime(this)
object year extends MappedInt(this)
object reference extends MappedPoliteString(this, 128)
// relationships
object source extends MappedLongForeignKey(this, BaseSourceTrait)
//
-- this is what i want.
}
object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
/--- code ends
As always I truely appreciate the help you guys are giving me :)
Thanks,
Mads Hartmann Jensen
On Feb 4, 9:56 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
Please take a look at the MegaProtoUser and MegaMetaProtoUser code for
examples of how to create traits that can be mixed into classes.
Does that help?
On Thu, Feb 4, 2010 at 9:58 AM, Mads Hartmann Jensen
mads...@gmail.comwrote:
hello Jeppe,
In my project I've got the following three models: A discovery, a
Scientist
and a lab. The Discovery has been invented by someone, this is either a
single scientist or sometimes a lab - This is easily done through
inheritance (would create a superclass named source) but I'm not sure
how to
do this so it maps nicely to the database.
Scientist and Lab only share one attribute so what I'm most interested in
is to be able express that a Discovery has s source that can be either a
lab
or scientist :)
Hope this explains my problem more clearly, thanks for the help
Mads Hartmann
Sent from my iPhone
On 04/02/2010, at 18.17, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
Mads Hartmann mads...@gmail.com writes:
Hello Everyone,
I'm currently trying to figure out how to map objects with inheritance
using
Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)
On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett timo...@getintheloop.euwrote: Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? Okay... once the assembla ticket system is up, open a ticket on this and assign it to me. For example: LiftRules.stripComments.default.set(() = false) FactoryMakers allows you to do a number of things: 1. define functions that calculate a value for a given thing (like should comments be stripped) 2. support aggregation into a Factory which can be used for Java-style dependency injection (you ask the Factory for a thing of type T and it gives it to you) 3. supports session, request, and current-thread over-riding of the calculation function So, why functions vs. values? Because functions are more flexible than values... they allow the calculation of values given the current context. Why not use call-by-name rather than explicit functions? I've found that making things explicit functions remove ambiguity. Additionally, there's an implicit that's supposed to promote a constant (T) to a function... but it doesn't always get invoked. If it's a function, why have session, request, and thread-based functions? Because you have to know at Boot time what you want the function to look like in all cases. Kris had some reasonable examples of over-riding the functions on a test-by-test basis (thread-based). Additionally, it strikes me that you might want to have a snippet that triggers a change in particular behavior (request-based) and rather than having to code that behavior into the function defined in Boot, you change it at the request level (we've got some examples of stuff that does that already, but making the common pattern into something that's built into the Factor/FactoryMaker makes sense). Are the names and call patterns optimal? No. But given that Factory/FactoryMaker is little used outside of LiftRules, I'd be up for breaking changes (as long as they turned into compile-time errors) to make things better. Tim -- you want to volunteer? This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@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.
Re: [Lift] Flot 0.6 Upgrade Breaking Change Question
On Thu, Feb 4, 2010 at 4:07 PM, Peter Robinett pe...@bubblefoundry.comwrote: Hello all, Please tell me if you are using the lift-flot module. I am working on upgrading it to Flot 0.6 and as Aaron noted[1], Flot has switched to a slightly new format of specifying options. However, they have kept backwards compatibility, meaning that we could upgrade to the latest version of Flot without changing the way series options are specified. Would you prefer to have a breaking change in lift-flot now in order to ensure future compatibility or would you like to put off this change until a future version of Flot drops support for this now depreciated format? Can you deprecate the Scala calls that correspond to the deprecated Flot calls? If so, that'd be optimal. I'm not sure how widely used Flot is, but unless there are more than 3 people who object to a breaking change, I'd be okay with it. Peter [1]: http://groups.google.com/group/liftweb/browse_thread/thread/a25a93f55c181475 -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@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.
Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)
In my experience, I found that the functionality of the FactoryMakers was very flexible (and I could see the utility of that), but that the documentation was just plain missing. Maybe more/better documentation on FactoryMaker itself, and some simple common examples on the places where FactoryMaker is used, e.g. stripComments might say: * To strip comments from all resources served by lift: *LiftRules.stripComments.default.set(() = false) * To strip only for a certain request: *... -Ross On Feb 5, 2010, at 1:41 PM, David Pollak wrote: On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? Okay... once the assembla ticket system is up, open a ticket on this and assign it to me. For example: LiftRules.stripComments.default.set(() = false) FactoryMakers allows you to do a number of things: define functions that calculate a value for a given thing (like should comments be stripped) support aggregation into a Factory which can be used for Java-style dependency injection (you ask the Factory for a thing of type T and it gives it to you) supports session, request, and current-thread over-riding of the calculation function So, why functions vs. values? Because functions are more flexible than values... they allow the calculation of values given the current context. Why not use call-by-name rather than explicit functions? I've found that making things explicit functions remove ambiguity. Additionally, there's an implicit that's supposed to promote a constant (T) to a function... but it doesn't always get invoked. If it's a function, why have session, request, and thread-based functions? Because you have to know at Boot time what you want the function to look like in all cases. Kris had some reasonable examples of over-riding the functions on a test-by-test basis (thread-based). Additionally, it strikes me that you might want to have a snippet that triggers a change in particular behavior (request-based) and rather than having to code that behavior into the function defined in Boot, you change it at the request level (we've got some examples of stuff that does that already, but making the common pattern into something that's built into the Factor/FactoryMaker makes sense). Are the names and call patterns optimal? No. But given that Factory/FactoryMaker is little used outside of LiftRules, I'd be up for breaking changes (as long as they turned into compile-time errors) to make things better. Tim -- you want to volunteer? This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options,
Re: [Lift] Re: S.params disappear?
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Then
I
package it into a war and load it up in Tomcat 6 on the server,
and
when
I
do, suddenly it won't work.
The issue is with the S.params. I have a form that submits
Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)
One advantage is setting the value only in a session, request, or local (doWith) scope. - Ross Mellgrendri...@gmail.com wrote: In my experience, I found that the functionality of the FactoryMakers was very flexible (and I could see the utility of that), but that the documentation was just plain missing. Maybe more/better documentation on FactoryMaker itself, and some simple common examples on the places where FactoryMaker is used, e.g. stripComments might say: * To strip comments from all resources served by lift: *LiftRules.stripComments.default.set(() = false) * To strip only for a certain request: *... -Ross On Feb 5, 2010, at 1:41 PM, David Pollak wrote: On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? Okay... once the assembla ticket system is up, open a ticket on this and assign it to me. For example: LiftRules.stripComments.default.set(() = false) FactoryMakers allows you to do a number of things: define functions that calculate a value for a given thing (like should comments be stripped) support aggregation into a Factory which can be used for Java-style dependency injection (you ask the Factory for a thing of type T and it gives it to you) supports session, request, and current-thread over-riding of the calculation function So, why functions vs. values? Because functions are more flexible than values... they allow the calculation of values given the current context. Why not use call-by-name rather than explicit functions? I've found that making things explicit functions remove ambiguity. Additionally, there's an implicit that's supposed to promote a constant (T) to a function... but it doesn't always get invoked. If it's a function, why have session, request, and thread-based functions? Because you have to know at Boot time what you want the function to look like in all cases. Kris had some reasonable examples of over-riding the functions on a test-by-test basis (thread-based). Additionally, it strikes me that you might want to have a snippet that triggers a change in particular behavior (request-based) and rather than having to code that behavior into the function defined in Boot, you change it at the request level (we've got some examples of stuff that does that already, but making the common pattern into something that's built into the Factor/FactoryMaker makes sense). Are the names and call patterns optimal? No. But given that Factory/FactoryMaker is little used outside of LiftRules, I'd be up for breaking changes (as long as they turned into compile-time errors) to make things better. Tim -- you want to volunteer? This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@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. -- You received this message because you are subscribed to the Google Groups Lift group. To
[Lift] Re: Single Table Inheritance
Thank you for taking your time to answer my question
I don't think I fully understand how to implement any of the suggested
solutions, if you have the time I would love a code example :)
Thanks a lot,
Mads Hartmann Jensen
On Feb 5, 7:34 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Basically, either use two protected LongMappedMappers and a public
getter/setter that takes a boolean into account in both directions; or use a
MappedLong, with
def obj = whicheverLookUpTable.find(this.is)
and
override def set(s: Source) = s match ...
Sorry for the brevity, if unclear please ask.
-
Mads Hartmannmads...@gmail.com wrote:
Naftoli would you please re-post your solution :) I could really use
the help
On Feb 5, 6:56 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Peek --www.getpeek.com
Please forward any bad messages to feedb...@getpeek.com
-
Ross Mellgrendri...@gmail.com wrote:
This is actually fairly common that messages Naftoli sends are empty, or
don't get threaded onto the original discussion, or formatting comes out
funny. Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have broken your first message, It's a blank
message if you view it through the web-interface:
http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5db...
If you have a solution I would love to hear it :)
On Feb 5, 1:52 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Does my approach not work?
-
Mads Hartmannmads...@gmail.com wrote:
Yeah that helped, my lab and scientist now looks like this:
/--- code
trait BaseSourceTrait[ T :BaseSourceTrait[T] ] extends
LongKeyedMapper[T] {
self: T =
override def primaryKeyField = id
object id extends MappedLongIndex(this)
object name extends MappedPoliteString(this, 256)
object sourceType extends MappedEnum(this,SourceTypes)
object SourceTypes extends Enumeration {
val Scientist = Value(Scientist)
val Lab = Value(Lab)
}
}
class Scientist extends BaseSourceTrait[Scientist] {
def getSingleton = Scientist
object birth extends MappedInt(this)
object death extends MappedInt(this)
object nationality extends MappedPoliteString(this, 128)
}
object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
{
override def dbTableName = Source
}
class Lab extends BaseSourceTrait[Lab] {
def getSingleton = Lab
object institution extends MappedLongForeignKey(this, Institution)
}
object Lab extends Lab with LongKeyedMetaMapper[Lab] {
override def dbTableName = Source
}
/--- code ends
My only problem now is that I can't figure out how to implement the
following:
A Discovery (a mapped class) needs to have a foreign key to the source
that made the discovery, this could be either a lab or a scientist, so
normally i would have a field with a reference to the super-class of
both Scientist and Lab - However, I don't have a super-class, I just
have a trait :)
I would like to be able to write something like this:
/--- code starts again
class Discovery extends LongKeyedMapper[Discovery] with IdPK {
def getSingleton = Discovery
// primatives
object description extends MappedDateTime(this)
object year extends MappedInt(this)
object reference extends MappedPoliteString(this, 128)
// relationships
object source extends MappedLongForeignKey(this,
BaseSourceTrait) //
-- this is what i want.
}
object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
/--- code ends
As always I truely appreciate the help you guys are giving me :)
Thanks,
Mads Hartmann Jensen
On Feb 4, 9:56 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
Please take a look at the MegaProtoUser and MegaMetaProtoUser code for
examples of how to create traits that can be mixed into classes.
Does that help?
On Thu, Feb 4, 2010 at 9:58 AM, Mads Hartmann Jensen
mads...@gmail.comwrote:
hello Jeppe,
In my project I've got the following three models: A discovery, a
Scientist
and a lab. The Discovery has been invented by someone, this is either a
single scientist or sometimes a lab - This is easily done through
inheritance (would create a superclass named source) but I'm not sure
how to
do this so it maps nicely to the database.
Scientist and Lab only share one attribute so what I'm most interested
in
is to be able express
Re: [Lift] Re: S.params disappear?
If any other proxy includes nginx, then a lot of people!
-
chasc...@munat.com wrote:
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Then
I
package it into a war and load it up in Tomcat 6
Re: [Lift] Re: S.params disappear?
Looking at the tomcat code, it seems pretty likely this is a Tomcat-specific
issue.
-Ross
On Feb 5, 2010, at 2:01 PM, Naftoli Gugenheim wrote:
If any other proxy includes nginx, then a lot of people!
-
chasc...@munat.com wrote:
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)
This is exactly right ross - I get its purpose (but I dont necessarily like the API), I just don't get the inconstancy in usage. It would certainly help a great deal if there were examples littered by its usages. Cheers, Tim On 5 Feb 2010, at 18:44, Ross Mellgren wrote: In my experience, I found that the functionality of the FactoryMakers was very flexible (and I could see the utility of that), but that the documentation was just plain missing. Maybe more/better documentation on FactoryMaker itself, and some simple common examples on the places where FactoryMaker is used, e.g. stripComments might say: * To strip comments from all resources served by lift: *LiftRules.stripComments.default.set(() = false) * To strip only for a certain request: *... -Ross On Feb 5, 2010, at 1:41 PM, David Pollak wrote: On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett timo...@getintheloop.eu wrote: Guys, I just wanted to have a grumpy moan about FactoryMaker. Now, this must easily be the most complicated / confusing piece of scala code in Lift. Its totally non-trivial implementation and its levels of miss- direction (and total lack of examples) make it an utter nightmare to figure out what one needs to do to use it for pre-assigned vals in LiftRules. This brings me neatly onto my next point: LiftRules and its occasional use of FactoryMaker, partial functions and mutable vars. I appreciate that this is partially a legacy thing as many different people within the team add stuff to LiftRules, however I thought FactoryMaker was brought in to facilitate object mocking / testing right? Shouldn't it be the first-order choice for configuration? weather or not that is the case, why oh why are there no explanations in the comments for LiftRules where factory maker is used as to how to alter those configuration options? Okay... once the assembla ticket system is up, open a ticket on this and assign it to me. For example: LiftRules.stripComments.default.set(() = false) FactoryMakers allows you to do a number of things: define functions that calculate a value for a given thing (like should comments be stripped) support aggregation into a Factory which can be used for Java-style dependency injection (you ask the Factory for a thing of type T and it gives it to you) supports session, request, and current-thread over-riding of the calculation function So, why functions vs. values? Because functions are more flexible than values... they allow the calculation of values given the current context. Why not use call-by-name rather than explicit functions? I've found that making things explicit functions remove ambiguity. Additionally, there's an implicit that's supposed to promote a constant (T) to a function... but it doesn't always get invoked. If it's a function, why have session, request, and thread-based functions? Because you have to know at Boot time what you want the function to look like in all cases. Kris had some reasonable examples of over-riding the functions on a test-by-test basis (thread-based). Additionally, it strikes me that you might want to have a snippet that triggers a change in particular behavior (request-based) and rather than having to code that behavior into the function defined in Boot, you change it at the request level (we've got some examples of stuff that does that already, but making the common pattern into something that's built into the Factor/FactoryMaker makes sense). Are the names and call patterns optimal? No. But given that Factory/FactoryMaker is little used outside of LiftRules, I'd be up for breaking changes (as long as they turned into compile-time errors) to make things better. Tim -- you want to volunteer? This is totally non-obvious - if we are going to use stuff like this, it really out to be in the comments. Stuff like this can seriously affect Lift's ease of use, and considering the current lack of documentation we need to be careful about what we are doing here. Sorry for the grump, i just felt this was warranted. Cheers, Tim -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at
Re: [Lift] Re: S.params disappear?
Agreed - based on the code, its a systemic issue with Tomcat rather than the
proxy. Consider swapping to another container if that is a viable option...
Cheers, Tim
On 5 Feb 2010, at 19:04, Ross Mellgren wrote:
Looking at the tomcat code, it seems pretty likely this is a Tomcat-specific
issue.
-Ross
On Feb 5, 2010, at 2:01 PM, Naftoli Gugenheim wrote:
If any other proxy includes nginx, then a lot of people!
-
chasc...@munat.com wrote:
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a
Re: [Lift] Re: Single Table Inheritance
Not tested or compiled
object isLab extends MappedBoolean(this)
1.
def source: Box[Source] = if(isLab.is) lab.obj else scientist.obj
def source_=(s: Source) = s match {
case l: Lab = isLab(true); lab(l)
// same for scientist
}
2.
object source extends MappedLong {
def obj = if(isLab) Lab.find(is) else Scientist.find(is)
def obj_=(s: Source) = s match {
case _: Lab = set(s.id)
// same for scientist
}
The advantage of 1 is database FK constraints.
The advantage of 2 is fewer fields.
-
Mads Hartmannmads...@gmail.com wrote:
Thank you for taking your time to answer my question
I don't think I fully understand how to implement any of the suggested
solutions, if you have the time I would love a code example :)
Thanks a lot,
Mads Hartmann Jensen
On Feb 5, 7:34 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Basically, either use two protected LongMappedMappers and a public
getter/setter that takes a boolean into account in both directions; or use a
MappedLong, with
def obj = whicheverLookUpTable.find(this.is)
and
override def set(s: Source) = s match ...
Sorry for the brevity, if unclear please ask.
-
Mads Hartmannmads...@gmail.com wrote:
Naftoli would you please re-post your solution :) I could really use
the help
On Feb 5, 6:56 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Peek --www.getpeek.com
Please forward any bad messages to feedb...@getpeek.com
-
Ross Mellgrendri...@gmail.com wrote:
This is actually fairly common that messages Naftoli sends are empty, or
don't get threaded onto the original discussion, or formatting comes out
funny. Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have broken your first message, It's a blank
message if you view it through the web-interface:
http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5db...
If you have a solution I would love to hear it :)
On Feb 5, 1:52 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Does my approach not work?
-
Mads Hartmannmads...@gmail.com wrote:
Yeah that helped, my lab and scientist now looks like this:
/--- code
trait BaseSourceTrait[ T :BaseSourceTrait[T] ] extends
LongKeyedMapper[T] {
self: T =
override def primaryKeyField = id
object id extends MappedLongIndex(this)
object name extends MappedPoliteString(this, 256)
object sourceType extends MappedEnum(this,SourceTypes)
object SourceTypes extends Enumeration {
val Scientist = Value(Scientist)
val Lab = Value(Lab)
}
}
class Scientist extends BaseSourceTrait[Scientist] {
def getSingleton = Scientist
object birth extends MappedInt(this)
object death extends MappedInt(this)
object nationality extends MappedPoliteString(this, 128)
}
object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
{
override def dbTableName = Source
}
class Lab extends BaseSourceTrait[Lab] {
def getSingleton = Lab
object institution extends MappedLongForeignKey(this, Institution)
}
object Lab extends Lab with LongKeyedMetaMapper[Lab] {
override def dbTableName = Source
}
/--- code ends
My only problem now is that I can't figure out how to implement the
following:
A Discovery (a mapped class) needs to have a foreign key to the source
that made the discovery, this could be either a lab or a scientist, so
normally i would have a field with a reference to the super-class of
both Scientist and Lab - However, I don't have a super-class, I just
have a trait :)
I would like to be able to write something like this:
/--- code starts again
class Discovery extends LongKeyedMapper[Discovery] with IdPK {
def getSingleton = Discovery
// primatives
object description extends MappedDateTime(this)
object year extends MappedInt(this)
object reference extends MappedPoliteString(this, 128)
// relationships
object source extends MappedLongForeignKey(this,
BaseSourceTrait) //
-- this is what i want.
}
object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
/--- code ends
As always I truely appreciate the help you guys are giving me :)
Thanks,
Mads Hartmann Jensen
On Feb 4, 9:56 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
Please take a look at the MegaProtoUser and MegaMetaProtoUser code for
examples of how to create traits that can be mixed into classes.
[Lift] Re: Flot 0.6 Upgrade Breaking Change Question
It requires changing the FlotOptions trait. Actually, we could do exactly what Flot 0.6 does and support both (just add the series option without removing the lines, points and shadowSize options), though then we'd need some way to prioritize one way over the other. Peter On Feb 5, 10:43 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Thu, Feb 4, 2010 at 4:07 PM, Peter Robinett pe...@bubblefoundry.comwrote: Hello all, Please tell me if you are using the lift-flot module. I am working on upgrading it to Flot 0.6 and as Aaron noted[1], Flot has switched to a slightly new format of specifying options. However, they have kept backwards compatibility, meaning that we could upgrade to the latest version of Flot without changing the way series options are specified. Would you prefer to have a breaking change in lift-flot now in order to ensure future compatibility or would you like to put off this change until a future version of Flot drops support for this now depreciated format? Can you deprecate the Scala calls that correspond to the deprecated Flot calls? If so, that'd be optimal. I'm not sure how widely used Flot is, but unless there are more than 3 people who object to a breaking change, I'd be okay with it. Peter [1]: http://groups.google.com/group/liftweb/browse_thread/thread/a25a93f55... -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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 lift...@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.
Re: [Lift] Re: Flot 0.6 Upgrade Breaking Change Question
Would we even need to prioritize it? If Flot supports both, we should let it do the hard work of deciding which one to use if they are both present, which I would imagine would be a very rare case. We can just mark the old methods as deprecated and then remove them in the future when Flot doesn't support the old way anymore. On Fri, Feb 5, 2010 at 2:22 PM, Peter Robinett pe...@bubblefoundry.com wrote: It requires changing the FlotOptions trait. Actually, we could do exactly what Flot 0.6 does and support both (just add the series option without removing the lines, points and shadowSize options), though then we'd need some way to prioritize one way over the other. Peter On Feb 5, 10:43 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Thu, Feb 4, 2010 at 4:07 PM, Peter Robinett pe...@bubblefoundry.comwrote: Hello all, Please tell me if you are using the lift-flot module. I am working on upgrading it to Flot 0.6 and as Aaron noted[1], Flot has switched to a slightly new format of specifying options. However, they have kept backwards compatibility, meaning that we could upgrade to the latest version of Flot without changing the way series options are specified. Would you prefer to have a breaking change in lift-flot now in order to ensure future compatibility or would you like to put off this change until a future version of Flot drops support for this now depreciated format? Can you deprecate the Scala calls that correspond to the deprecated Flot calls? If so, that'd be optimal. I'm not sure how widely used Flot is, but unless there are more than 3 people who object to a breaking change, I'd be okay with it. Peter [1]: http://groups.google.com/group/liftweb/browse_thread/thread/a25a93f55... -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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 lift...@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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: Upgrade to Flot 0.6
Hi Aaron, I just added hoverable to my branch. Please let me know if you have any issues with it. As for plugins, I think it might take a little thinking to get right. Looking at the Flot plugin documentation (http://flot.googlecode.com/ svn/trunk/PLUGINS.txt), a plugin registers itself by calling $.plot.plugins.push(pluginDefinitionObject). I think we could have a generic plugin trait and make individual instances for each specific plugin which would implement the minimum possible, which may simply be including the plugin javascript file on the page. However, including the plugin Javascript files could be tricky. Flot.init in boot.scala could be aggressive about including as many plugin files as possible, but that's not a particularly elegant way. However, including them elsewhere, for example as part of the Flot.render, would make uses like calling Flot.render in a CometActor tricky. Finally, I notice that plugins are allowed to add their own options to the new series option object we've been discussing. Because by their nature we can't anticipate all options, it may make sense that the series object should be some sort of Map. What do people think? Peter On Feb 5, 6:13 am, Aaron Valade a...@alum.mit.edu wrote: Looks great! One little nit is, could we add the hoverable option to FlotGridOptions? That's a new feature which was added to Flot which shouldn't break backwards compatibility. Any thoughts about integrating plugins as the zooming and FlotOverview class don't work without the selecting plugin. - A On Thu, Feb 4, 2010 at 7:56 PM, Peter Robinett pe...@bubblefoundry.com wrote: Hi Aaron, I've pushed the simplest update possible to my branch here: http://github.com/dpp/liftweb/tree/pr1001_issue_322. I will make the series options change if there are no significant dissenting voices in the thread I created[1]. In the meantime, do. The flotDemo app seems to work without any changes. What do you think? Peter [1]:http://groups.google.com/group/liftweb/t/ba7e0f76042ff562 On Feb 3, 6:30 am, Aaron Valade a...@alum.mit.edu wrote: I've created a ticket here: http://github.com/dpp/liftweb/issues/issue/322 Thanks again! - Aaron On Tue, Feb 2, 2010 at 10:10 PM, Peter Robinett pe...@bubblefoundry.com wrote: You're welcome. I'm happy to look into adding Flot plugin support, but please open a ticket on GitHub (http://github.com/dpp/liftweb/issues). Peter On Feb 1, 10:22 am, Aaron Valade a...@alum.mit.edu wrote: Thanks Peter! One of the other things that changed between Flot 0.4 and 0.6 is that a plugin structure was introduced and some functionality was pushed out of the core and into a plugin, specifically the selection functionality which can be used for zooming and other interactions with the charted data. I hate to tack on requests for more work, but if you get a chance, I'd appreciate if you could add functionality to the Lift Flot Widget to allow use of these plugins. I'm in the process of making some small changes with the Flot Widget to support these plugins in my local fork of Lift and would be happy to share what I've done, if that's allowed. Otherwise, I'd be very eager to provide additional testing of any capabilities that you make available or any other help that I can provide within the guidelines of the Lift project. Thanks, - A On Mon, Feb 1, 2010 at 12:28 PM, Peter Robinett pe...@bubblefoundry.com wrote: Ok guys, I'll work on this in the next few days (I'm out of town right now). Peter On Jan 31, 3:20 pm, Timothy Perrett timo...@getintheloop.eu wrote: It seems like peter will take ownership of this and make it happen ASAP so a patch / diff should not be needed. Peter, please confirm when you will roll this in a branch and put it on review board? Cheers, Tim Sent from my iPhone On 31 Jan 2010, at 22:48, Aaron Valade aval...@gmail.com wrote: I'm more than happy to submit the patch under the Lift IP policy, but I understand if you don't feel comfortable with that. And I can submit it anyway that works for you. I'm just looking to help give back to everyone that's helped me out. Albeit in a very, very small way. Sent from my iPhone On Jan 31, 2010, at 5:43 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Peter, Please keep in mind the Lift IP policy. We don't pull from other repositories nor do we accept patches. We'll have to do the Flot 0.6 ourselves. Thanks, David On Fri, Jan 29, 2010 at 4:44 PM, Peter Robinett pe...@bubblefoundry.com wrote: Aaron, thanks so much for taking the initiative to upgrade Flot, it's something that I've been meaning to do. Just skimming over your changes, everything looks good. As for not using the packed excanvas file, that should be ok since Lift
[Lift] Re: Map to JsObj
I know there was something simple. Thanks, now I just need to make sure I have the right implicits imported and I'm good to go. On Feb 5, 12:54 pm, Ross Mellgren dri...@gmail.com wrote: JsObj(map.toSeq: _*) ? -Ross On Feb 5, 2010, at 3:53 PM, Peter Robinett wrote: I thought it would be something that already exists but I can't for the life of me find out how to convert a Map to a JsObj. Am I missing something basic in net.liftweb.http.js? Thanks, Peter -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: S.params disappear?
On Fri, Feb 5, 2010 at 6:34 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Crud. Can someone do a survey of how other JVM web frameworks handle the PUT inconsistencies on different containers? Does S.param map directly to the servletrequest getParameter? If so, I think the Servlet Spec explains it: The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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-OpenID should default to openid_identifier for post param name
Thanks! I'm now trying to customize the attribute-exchange and noticed that it is embedded in a longish method. I think it would be good if this was extracted to a method (maybe: def reqAttributeExchange: Option[FetchRequest] ?) so that ax info could be modified without digging into the rest of the logic or copy'n'pasting. Specifically, I think these lines could be extracted: // Attribute Exchange example: fetching the 'email' attribute val fetch = FetchRequest.createFetchRequest() fetch.addAttribute(email, // attribute alias http://schema.openid.net/contact/email;, // type URI true); // required Erkki L On Feb 2, 1:33 am, David Pollak feeder.of.the.be...@gmail.com wrote: I've changed the code from a val to a def and changed the default value to openid_identifier. If this causes code breakage, folks can change it back to the old value. Thanks for the suggestion. On Sat, Jan 30, 2010 at 7:58 AM, Erkki Lindpere vill...@gmail.com wrote: Hi, I suggest that Lift-OpenID should have openid_identifier as the default post param name instead of openIdUrl. openid_identifier is the one recommended in the OpenID spec. with the idea that user agents may someday special support for that. I think this change would be justified considering Lift's philosophy of providing sensible defaults? (not that it's hard to change, but it took me a while to figure out why /openid/login resulted in not found -- I used a custom form with the standard field names not the one generated by Lift) Erkki -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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 lift...@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] Potential breakage: Choosing the default Lift logging backend
(Moved from committers list) Hi, A fix is on RB (http://reviewboard.liftweb.net/r/198/) for Issue 309 that changes the Lift internal logging to always go through Slf4j (a logging facade that provides a uniform logging interface to different logging backends such as Log4j and logback) Since slf4j-api.jar is only a facade, an actual logging backend (such as log4j) needs to be included in an app. A decision remains as to what the best solution is for specifying this dependency and configure the backend. There are 2 options as I see it: 1) Include the slf4j-log4j12 as runtime dependency in lift-util. This also includes the log4j.jar. Log4j is configured automatically, as in the current code. Pros: No changes to client code or poms Cons: Need to explicitly exclude slf4j-log4j12 dependency if another backend than log4j (such as logback) is needed. 2) Don't include any logging backends, but the user is forced to make a decision before the app will log anything. Pros: No need to exclude anything if using another backend than log4j. Cons: People need to update their poms. The configuration of log4j would have to depend on dynamic classloading if we are to avoid code changes. The current patch implements 1) as I like the fact that some default exists, even though it makes it a bit harder for people to switch backends. 2) is the cleanest solution since the choice of logging backend is made explicit. But this requires people to change their poms in order to get any logging. Thoughts? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] OSGi example, what to do to make it run?
OK ;-) This is what I answered to Martin so far: I do not know such a tutorial, sorry. OSGi offers hot deployment out of the box, hence you do not need any JRebel or so. But by default (according to the spec) each bundle must be a JAR, hence you need a full build cycle. Eclipse Equinox allows for hosted deployment of usual PDE projects. Currently Lift's OSGi support is constrained to single bundle (module) applications. Of course this is already beneficial, because all the dependencies (including lift-webkit etc.) are deployed as separate modules and therefore can be updated separately. Also it should be possible to deploy different Lift apps to one OSGi container. But on the long run I would like to see real modular Lift applications: Where one Lift app is made up from several bundles. Maybe some of them are installed later and contribute to the menus, the mapper etc. OSGi and JEE integration, namely web app integration, has been quiet for some time, but recently there seems to be some process. I am not sure whether the spec will deal with composite web apps: If not, we could pioneer in this field. Any ideas or questions? Heiko On 5 February 2010 18:18, David Pollak feeder.of.the.be...@gmail.comwrote: On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 5 February 2010 15:05, Martin Ellis ellis@gmail.com wrote: Any offers/suggestions? (Sorry, I realise the question more about OSGI than lift) Indeed, let's discuss this off-list ... Can you discuss it on-list? I'd like to learn. Heiko Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Potential breakage: Choosing the default Lift logging backend
Hi, On 5 February 2010 22:11, Jeppe Nejsum Madsen je...@ingolfs.dk wrote: 2) is the cleanest solution since the choice of logging backend is made explicit. But this requires people to change their poms in order to get any logging. Let's go for 2) because in real-world projects people will have to adjust the POM anyway. E.g. for persistence modules or for 3rd party libs. Heiko Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Upgrade to Flot 0.6
Yeah, I'm not sure what the best solution is going to be on plugins.
The naive way I've approached this problem so far was by creating:
trait FlotPlugin {
val pluginFile: String
}
and then creating objects that extended that with the name of the plugin file:
object FlotSelection extends FlotPlugin {
val pluginFile = jquery.flot.selection.js
}
Then I added a new var and a new init method inside the Flot object
var plugins: List[FlotPlugin] = Nil
def init(fp: FlotPlugin*) {
plugins = fp.toList
init()
plugins.foreach{ p =
ResourceServer.allow({
case flot :: p.pluginFile :: Nil = true
})
}
}
And I also added a for loop into the renderHead method to yield a
script include for each plugin that was in the plugins List of the
Flot object. That way, I could at least choose in my Boot.scala which
plugins I wanted to initialize in my project by calling
Flot.init(FlotSelection).
Ideally, it would be cool if you would define a FlotCapability as
needing a particular FlotPlugin and then use some method inside of
Flot.init to lookup all the FlotCapabilities that you've declared in
your project and then initialize the plugins based on that list. I'm
not sure if there's a good way to do that outside of using reflection
though as I'm not too familiar with the Lift initialization process.
- Aaron
On Fri, Feb 5, 2010 at 3:22 PM, Peter Robinett pe...@bubblefoundry.com wrote:
Hi Aaron,
I just added hoverable to my branch. Please let me know if you have
any issues with it.
As for plugins, I think it might take a little thinking to get right.
Looking at the Flot plugin documentation (http://flot.googlecode.com/
svn/trunk/PLUGINS.txt), a plugin registers itself by calling
$.plot.plugins.push(pluginDefinitionObject). I think we could have a
generic plugin trait and make individual instances for each specific
plugin which would implement the minimum possible, which may simply be
including the plugin javascript file on the page.
However, including the plugin Javascript files could be tricky.
Flot.init in boot.scala could be aggressive about including as many
plugin files as possible, but that's not a particularly elegant way.
However, including them elsewhere, for example as part of the
Flot.render, would make uses like calling Flot.render in a CometActor
tricky.
Finally, I notice that plugins are allowed to add their own options to
the new series option object we've been discussing. Because by their
nature we can't anticipate all options, it may make sense that the
series object should be some sort of Map.
What do people think?
Peter
On Feb 5, 6:13 am, Aaron Valade a...@alum.mit.edu wrote:
Looks great!
One little nit is, could we add the hoverable option to
FlotGridOptions? That's a new feature which was added to Flot which
shouldn't break backwards compatibility.
Any thoughts about integrating plugins as the zooming and FlotOverview
class don't work without the selecting plugin.
- A
On Thu, Feb 4, 2010 at 7:56 PM, Peter Robinett pe...@bubblefoundry.com
wrote:
Hi Aaron,
I've pushed the simplest update possible to my branch here:
http://github.com/dpp/liftweb/tree/pr1001_issue_322. I will make the
series options change if there are no significant dissenting voices in
the thread I created[1]. In the meantime, do. The flotDemo app seems
to work without any changes.
What do you think?
Peter
[1]:http://groups.google.com/group/liftweb/t/ba7e0f76042ff562
On Feb 3, 6:30 am, Aaron Valade a...@alum.mit.edu wrote:
I've created a ticket here:
http://github.com/dpp/liftweb/issues/issue/322
Thanks again!
- Aaron
On Tue, Feb 2, 2010 at 10:10 PM, Peter Robinett pe...@bubblefoundry.com
wrote:
You're welcome. I'm happy to look into adding Flot plugin support, but
please open a ticket on GitHub (http://github.com/dpp/liftweb/issues).
Peter
On Feb 1, 10:22 am, Aaron Valade a...@alum.mit.edu wrote:
Thanks Peter!
One of the other things that changed between Flot 0.4 and 0.6 is that
a plugin structure was introduced and some functionality was pushed
out of the core and into a plugin, specifically the selection
functionality which can be used for zooming and other interactions
with the charted data. I hate to tack on requests for more work, but
if you get a chance, I'd appreciate if you could add functionality to
the Lift Flot Widget to allow use of these plugins. I'm in the process
of making some small changes with the Flot Widget to support these
plugins in my local fork of Lift and would be happy to share what I've
done, if that's allowed. Otherwise, I'd be very eager to provide
additional testing of any capabilities that you make available or any
other help that I can provide within the guidelines of the Lift
project.
Thanks,
- A
On Mon, Feb 1, 2010 at 12:28 PM, Peter Robinett
pe...@bubblefoundry.com wrote:
Ok guys, I'll work on this
Re: [Lift] Re: S.params disappear?
On Fri, Feb 5, 2010 at 1:03 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: On Fri, Feb 5, 2010 at 6:34 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Crud. Can someone do a survey of how other JVM web frameworks handle the PUT inconsistencies on different containers? Does S.param map directly to the servletrequest getParameter? If so, I think the Servlet Spec explains it: The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. Okay... so at the very least Jetty violates the spec. We can change things up so that Lift does its own interpretation of the PUT body. If we do this before we call getParameter, then I think we avoid problems in Jetty. Once Assembla is accepting tickets (sometime after sundown EST Saturday) please open a ticket on Assembla. Either Marius or I will work on it. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://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 lift...@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: Single Table Inheritance
Ah! It seems to be working now - Thanks a lot :)
On Feb 5, 8:15 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Not tested or compiled
object isLab extends MappedBoolean(this)
1.
def source: Box[Source] = if(isLab.is) lab.obj else scientist.obj
def source_=(s: Source) = s match {
case l: Lab = isLab(true); lab(l)
// same for scientist
}
2.
object source extends MappedLong {
def obj = if(isLab) Lab.find(is) else Scientist.find(is)
def obj_=(s: Source) = s match {
case _: Lab = set(s.id)
// same for scientist
}
The advantage of 1 is database FK constraints.
The advantage of 2 is fewer fields.
-
Mads Hartmannmads...@gmail.com wrote:
Thank you for taking your time to answer my question
I don't think I fully understand how to implement any of the suggested
solutions, if you have the time I would love a code example :)
Thanks a lot,
Mads Hartmann Jensen
On Feb 5, 7:34 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Basically, either use two protected LongMappedMappers and a public
getter/setter that takes a boolean into account in both directions; or use
a MappedLong, with
def obj = whicheverLookUpTable.find(this.is)
and
override def set(s: Source) = s match ...
Sorry for the brevity, if unclear please ask.
-
Mads Hartmannmads...@gmail.com wrote:
Naftoli would you please re-post your solution :) I could really use
the help
On Feb 5, 6:56 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Peek --www.getpeek.com
Please forward any bad messages to feedb...@getpeek.com
-
Ross Mellgrendri...@gmail.com wrote:
This is actually fairly common that messages Naftoli sends are empty, or
don't get threaded onto the original discussion, or formatting comes out
funny. Naftoli, what email client are you using?
-Ross
On Feb 5, 2010, at 1:49 AM, Mads Hartmann wrote:
Hey Naftoli,
I think something might have broken your first message, It's a blank
message if you view it through the web-interface:
http://groups.google.com/group/liftweb/browse_thread/thread/e2317e5db...
If you have a solution I would love to hear it :)
On Feb 5, 1:52 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
Does my approach not work?
-
Mads Hartmannmads...@gmail.com wrote:
Yeah that helped, my lab and scientist now looks like this:
/--- code
trait BaseSourceTrait[ T :BaseSourceTrait[T] ] extends
LongKeyedMapper[T] {
self: T =
override def primaryKeyField = id
object id extends MappedLongIndex(this)
object name extends MappedPoliteString(this, 256)
object sourceType extends MappedEnum(this,SourceTypes)
object SourceTypes extends Enumeration {
val Scientist = Value(Scientist)
val Lab = Value(Lab)
}
}
class Scientist extends BaseSourceTrait[Scientist] {
def getSingleton = Scientist
object birth extends MappedInt(this)
object death extends MappedInt(this)
object nationality extends MappedPoliteString(this, 128)
}
object Scientist extends Scientist with LongKeyedMetaMapper[Scientist]
{
override def dbTableName = Source
}
class Lab extends BaseSourceTrait[Lab] {
def getSingleton = Lab
object institution extends MappedLongForeignKey(this, Institution)
}
object Lab extends Lab with LongKeyedMetaMapper[Lab] {
override def dbTableName = Source
}
/--- code ends
My only problem now is that I can't figure out how to implement the
following:
A Discovery (a mapped class) needs to have a foreign key to the source
that made the discovery, this could be either a lab or a scientist, so
normally i would have a field with a reference to the super-class of
both Scientist and Lab - However, I don't have a super-class, I just
have a trait :)
I would like to be able to write something like this:
/--- code starts again
class Discovery extends LongKeyedMapper[Discovery] with IdPK {
def getSingleton = Discovery
// primatives
object description extends MappedDateTime(this)
object year extends MappedInt(this)
object reference extends MappedPoliteString(this, 128)
// relationships
object source extends MappedLongForeignKey(this,
BaseSourceTrait) //
-- this is what i want.
}
object Discovery extends Discovery with LongKeyedMetaMapper[Discovery]
/--- code ends
As always I truely appreciate the help you guys are giving me :)
Thanks,
Mads
[Lift] Help embedding lift in jetty
Hello - newbie to scala and (esp) lift. I'm trying to get lift embedded into a server I wrote which also embeds jetty, so trying to avoid making war files, etc (the init code is at the end of this email) and thought someone out there might be able to point me in the right direction. I am using lift-util-1.0.jar and lift-webkit-1.0.jar, a bunch of the jetty jars, and any other jars needed to resolve dependencies. I may be a sucker for punishment, but everything works fine - the LiftServlet and LiftFilter are installed into jetty, and when I surf to : http://localhost:8081/lift/ I get a 'broken link' error response to the browser, and the scala console outputs: scala INFO - Service request (GET) /lift/ took 136 Milliseconds So, it looks like it's getting to lift, but likely lift thinks that there are no web apps, and hence the error (or something). I have a directory containing a simple hello world lift app created with maven archetype:generate, and I'd like to point the LiftServlet to that, if at all possible. Or copy that project structure somewhere underneath jetty... I've tried copying the lift app to cwd, the classes directory, the lib directory, etc to no avail. Does anyone know how to get the LiftServlet to find the web apps? Any help is appreciated. brian... --- x8 snip import com.whatevernot.liaison.servlet.HelloServlet import net.liftweb.http. import org.eclipse.jetty.server. import org.eclipse.jetty.servlet._ val server = new Server(8081) val context = new ServletContextHandler(ServletContextHandler.SESSIONS) context.addFilter(new FilterHolder(new LiftFilter()), /lift/, 1) context.addServlet(new ServletHolder(new HelloServlet()), /hello/) context.addServlet(new ServletHolder(new LiftServlet()), /lift/*) context.setContextPath(/) server.setHandler(context) server.start -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] URL Rewriting - 'nested' ParsePath?
Hi, I'd like to rewrite a url like this:
/manufacturer/product
e.g.
LiftRules.statelessRewrite.append( {
case RewriteRequest(
ParsePath( manufacturerName :: productName :: Nil, _, _,_), _,
_) =
RewriteResponse(productView :: Nil)
})
But, I'd like to the ParsePath case to not 'catch' for non-existant
manufacturers, and non-existant products by the manufacturer.
So, I might do this:
LiftRules.statelessRewrite.append( {
case RewriteRequest(
ParsePath( Manufacturer(manufacturer) :: Product(product) ::
Nil, _, _,_), _, _) =
RewriteResponse(productView :: Nil)
})
Where Manufacturer and Product objects provide an extractor which does
a lookup.
However, the product lookup depends on the manufacturer.. is there a
way to handle that?
ideas:
1. use an if guard
case RewriteRequest(
ParsePath( Manufacturer(manufacturer) :: productName :: Nil,
_, _,_), _, _) if manufacturer.contains(productName) =
val product = manufacturer.getProduct(productName)
sucks because it looks up the product twice.
2. some time of nested case?
case RewriteRequest(
ParsePath( Manufacturer(manufacturer) :: Product(manufacturer,
product) :: Nil, _, _,_), _, _) =
obviously doesn't work..
any suggestions welcome, thanks!
- Alex
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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: Help embedding lift in jetty
There is a RunWebApp.scala that seems to be included in the generated
projects from the maven archetype, you can probably copy it?
object RunWebApp extends Application {
val server = new Server(8080)
val context = new WebAppContext()
context.setServer(server)
context.setContextPath(/)
context.setWar(src/main/webapp)
server.addHandler(context)
try {
println( STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO
STOP)
server.start()
while (System.in.available() == 0) {
Thread.sleep(5000)
}
server.stop()
server.join()
} catch {
case exc : Exception = {
exc.printStackTrace()
System.exit(100)
}
}
}
On Feb 5, 6:22 pm, parki whatever...@gmail.com wrote:
Hello - newbie to scala and (esp) lift.
I'm trying to get lift embedded into a server I wrote which also
embeds jetty, so trying to avoid making war files, etc (the init code
is at the end of this email) and thought someone out there might be
able to point me in the right direction. I am using lift-util-1.0.jar
and lift-webkit-1.0.jar, a bunch of the jetty jars, and any other jars
needed to resolve dependencies. I may be a sucker for punishment, but
everything works fine - the LiftServlet and LiftFilter are installed
into jetty, and when I surf to :
http://localhost:8081/lift/
I get a 'broken link' error response to the browser, and the scala
console outputs:
scala INFO - Service request (GET) /lift/ took 136 Milliseconds
So, it looks like it's getting to lift, but likely lift thinks that
there are no web apps, and hence the error (or something).
I have a directory containing a simple hello world lift app created
with maven archetype:generate, and I'd like to point the LiftServlet
to that, if at all possible. Or copy that project structure somewhere
underneath jetty...
I've tried copying the lift app to cwd, the classes directory, the lib
directory, etc to no avail.
Does anyone know how to get the LiftServlet to find the web apps?
Any help is appreciated.
brian...
--- x8 snip
import com.whatevernot.liaison.servlet.HelloServlet
import net.liftweb.http.
import org.eclipse.jetty.server.
import org.eclipse.jetty.servlet._
val server = new Server(8081)
val context = new
ServletContextHandler(ServletContextHandler.SESSIONS)
context.addFilter(new FilterHolder(new LiftFilter()), /lift/, 1)
context.addServlet(new ServletHolder(new HelloServlet()), /hello/)
context.addServlet(new ServletHolder(new LiftServlet()), /lift/*)
context.setContextPath(/)
server.setHandler(context)
server.start
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@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.
Re: [Lift] Re: S.params disappear?
Ha, ha. Brilliant. The writers of the Servlet Spec incorporated the short-sightedness of the browser makers, who saw no point in PUTs and DELETEs. Both POST and PUT methods include entities per RFC 2616, so why is PUT the poor step-sister? Maybe I'll take another look at virtual hosting in Jetty... They seem to have ignored the spec on this point. Chas. On Fri, Feb 5, 2010 at 6:34 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Crud. Can someone do a survey of how other JVM web frameworks handle the PUT inconsistencies on different containers? Does S.param map directly to the servletrequest getParameter? If so, I think the Servlet Spec explains it: The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] liftweb.vim plugin for vim development
Hello all, To ease my pain in using Lift with vim as my main text editor (getting Eclipse set up correctly with the Scala editor has been an exercise in futility thus far), I've developed a vim plugin for lift that is similar to, if far more limited in scope than, the rails.vim plugin. Its basic purpose is to simplify navigation within lift projects. You can find it at http://www.vim.org/scripts/script.php?script_id=2962 , and on github at http://github.com/Shadowfiend/liftweb-vim . Currently, it provides a few commands: * :Lmodel, Lsnippet, Lactor, Lcomet -- all take a class name and take you to the appropriate associated file * :Lview -- takes a class name and takes you to the appropriate view file * :Lspec or :Ltest -- when called from a class (e.g., GroupSnip), takes you to the associated test file (GroupSnipTest) * :Lclass -- the opposite of Lspec, takes you to the class for the current test Hope this proves useful to someone! Thanks, Antonio -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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] Comet making jetty take a long time to shutdown
Just a bit more on this: I've noticed that if all users have logged out then jetty shuts down quickly... Channing Walton wrote: Hi, I've added some comet-fu in my lift app but I've found that it now takes a minute or so for jetty to shut down. Is there something I should have done to enable things to shutdown quicker? Channing -- View this message in context: http://old.nabble.com/Comet-making-jetty-take-a-long-time-to-shutdown-tp27450451p27477445.html Sent from the liftweb mailing list archive at Nabble.com. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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: OSGi example, what to do to make it run?
Hi, I want to explain my desire for OSGi in Lift, I understand that Lift being split into modules and being able to load different modules is desirable. However what I want to be able to do is to dynamically compile Scala code, load into OSGi and use it from my liftweb application. I don't want to use JRebel as this is not for development, this is for my website. Why do I want to do that? I am making a code generator which generates Scala code, I want the user to be able to try out the Scala code. So some liftweb method would generate a .scala file and another would package it into a OSGi and load the OSGi. It seems not so difficult to do this, even to call OSGi API to reload a OSGi bundle from a path, but in general need Liftweb to be in OSGi if I am doing it in the same JVM. An alternative is that I provide it as a web-service from a OSGi and call from Liftweb. Oh if you know a different way achive my goal I am interested to hear. Phil On 2月6日, 上午5時16分, Heiko Seeberger heiko.seeber...@googlemail.com wrote: OK ;-) This is what I answered to Martin so far: I do not know such a tutorial, sorry. OSGi offers hot deployment out of the box, hence you do not need any JRebel or so. But by default (according to the spec) each bundle must be a JAR, hence you need a full build cycle. Eclipse Equinox allows for hosted deployment of usual PDE projects. Currently Lift's OSGi support is constrained to single bundle (module) applications. Of course this is already beneficial, because all the dependencies (including lift-webkit etc.) are deployed as separate modules and therefore can be updated separately. Also it should be possible to deploy different Lift apps to one OSGi container. But on the long run I would like to see real modular Lift applications: Where one Lift app is made up from several bundles. Maybe some of them are installed later and contribute to the menus, the mapper etc. OSGi and JEE integration, namely web app integration, has been quiet for some time, but recently there seems to be some process. I am not sure whether the spec will deal with composite web apps: If not, we could pioneer in this field. Any ideas or questions? Heiko On 5 February 2010 18:18, David Pollak feeder.of.the.be...@gmail.comwrote: On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: On 5 February 2010 15:05, Martin Ellis ellis@gmail.com wrote: Any offers/suggestions? (Sorry, I realise the question more about OSGI than lift) Indeed, let's discuss this off-list ... Can you discuss it on-list? I'd like to learn. Heiko Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com- . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- 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 lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com- . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Heiko Seeberger Work: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net- 隱藏被引用文字 - - 顯示被引用文字 - -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Upgrade to Flot 0.6
Peter Robinett pe...@bubblefoundry.com writes: Hi Aaron, I just added hoverable to my branch. Please let me know if you have any issues with it. As for plugins, I think it might take a little thinking to get right. Looking at the Flot plugin documentation (http://flot.googlecode.com/svn/trunk/PLUGINS.txt), a plugin registers itself by calling $.plot.plugins.push(pluginDefinitionObject). I think we could have a generic plugin trait and make individual instances for each specific plugin which would implement the minimum possible, which may simply be including the plugin javascript file on the page. However, including the plugin Javascript files could be tricky. Flot.init in boot.scala could be aggressive about including as many plugin files as possible, but that's not a particularly elegant way. However, including them elsewhere, for example as part of the Flot.render, would make uses like calling Flot.render in a CometActor tricky. Finally, I notice that plugins are allowed to add their own options to the new series option object we've been discussing. Because by their nature we can't anticipate all options, it may make sense that the series object should be some sort of Map. What do people think? I've also been thinking about this. I'm using jqPlot instead of Flot for various reasons and there the same issues arise. Also, several other jqQuery plugins are extendable with some sort of plugin mechanism and in much the same way. So maybe some of this could be made generic in some way? /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
Re: [Lift] Re: Lift-OpenID should default to openid_identifier for post param name
Erkki Lindpere vill...@gmail.com writes: Thanks! I'm now trying to customize the attribute-exchange and noticed that it is embedded in a longish method. I think it would be good if this was extracted to a method (maybe: def reqAttributeExchange: Option[FetchRequest] ?) so that ax info could be modified without digging into the rest of the logic or copy'n'pasting. Specifically, I think these lines could be extracted: // Attribute Exchange example: fetching the 'email' attribute val fetch = FetchRequest.createFetchRequest() fetch.addAttribute(email, // attribute alias http://schema.openid.net/contact/email;, // type URI true); // required I maybe about to look at the openid stuff for a project and will need this functionality as well :-) If you could open a ticket on Assembla (when it's availability has been announced) I'll have a look... /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@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.
