Re: [Lift] Re: Lift-OpenID should default to openid_identifier for post param name

[Jeppe Nejsum Madsen]

Erkki Lindpere  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.

Re: [Lift] Re: Upgrade to Flot 0.6

[Jeppe Nejsum Madsen]

Peter Robinett  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.

[Lift] Re: OSGi example, what to do to make it run?

[philip]

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 
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 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  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.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.
>
> --
> 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.

[Lift] Re: [lift] Comet making jetty take a long time to shutdown

[Channing Walton]

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] liftweb.vim plugin for vim development

[Antonio Salazar Cardozo]

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.

Re: [Lift] Re: S.params disappear?

[chas]

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
>  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] Re: Help embedding lift in jetty

[Alex Black]

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  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.

[Lift] URL Rewriting - 'nested' ParsePath?

[Alex Black]

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] Help embedding lift in jetty

[parki]

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] Re: Single Table Inheritance

[Mads Hartmann]

Ah! It seems to be working now - Thanks a lot :)


On Feb 5, 8:15 pm, Naftoli Gugenheim  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 Hartmann 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  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 Hartmann wrote:
>
> > Naftoli would you please re-post your solution :) I could really use
> > the help
>
> > On Feb 5, 6:56 pm, Naftoli Gugenheim  wrote:
>
> > > Peek --www.getpeek.com
> > > Please forward any bad messages to feedb...@getpeek.com
>
> > > -
>
> > > Ross Mellgren 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  wrote:
> > > >> Does my approach not work?
>
> > > >> -
>
> > > >> Mads Hartmann 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, 

Re: [Lift] Re: S.params disappear?

[David Pollak]

On Fri, Feb 5, 2010 at 1:03 PM, Jeppe Nejsum Madsen wrote:

> On Fri, Feb 5, 2010 at 6:34 PM, David Pollak
>  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.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: Upgrade to Flot 0.6

[Aaron Valade]

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  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  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  
>> 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  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  
>> >> 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  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.
>>
>> >> >>

Re: [Lift] Potential breakage: Choosing the default Lift logging backend

[Heiko Seeberger]

Hi,

On 5 February 2010 22:11, Jeppe Nejsum Madsen  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] OSGi example, what to do to make it run?

[Heiko Seeberger]

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 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  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.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.
>



-- 
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.

[Lift] Potential breakage: Choosing the default Lift logging backend

[Jeppe Nejsum Madsen]

(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.

[Lift] Re: Lift-OpenID should default to openid_identifier for post param name

[Erkki Lindpere]

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  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  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.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: S.params disappear?

[Jeppe Nejsum Madsen]

On Fri, Feb 5, 2010 at 6:34 PM, David Pollak
 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: Map to JsObj

[Peter Robinett]

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  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] Map to JsObj

[Ross Mellgren]

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 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] Map to JsObj

[Peter Robinett]

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 at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] UML Diagram from existing lift application

[Jeppe Nejsum Madsen]

David Pollak  writes:

> On Thu, Feb 4, 2010 at 11:44 PM, Dick Hirsch  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.

It's been a while since I've followed UML, but can it handle things
like traits and the corresponding linearization?

/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: Flot 0.6 Upgrade Breaking Change Question

[Peter Robinett]

True. Good solution.

On Feb 5, 11:29 am, Aaron Valade  wrote:
> 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  
> 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 
> > wrote:
> >> On Thu, Feb 4, 2010 at 4:07 PM, Peter Robinett 
> >> wrote:
>
> >> > 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.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 
> > 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.

[Lift] Re: Upgrade to Flot 0.6

[Peter Robinett]

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  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  
> 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  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  
> >> 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  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 
> >> >>  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  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  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 
> >> >> >> >  >> >> >> > > 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 
> >> >> >> >>  >> >> >> >> > wrote:
> >> >> >> >> Aaron, thanks so much for taking the initiative to upgrade 

Re: [Lift] Re: Flot 0.6 Upgrade Breaking Change Question

[Aaron Valade]

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  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 
> wrote:
>> On Thu, Feb 4, 2010 at 4:07 PM, Peter Robinett 
>> wrote:
>>
>> > 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.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: Flot 0.6 Upgrade Breaking Change Question

[Peter Robinett]

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 
wrote:
> On Thu, Feb 4, 2010 at 4:07 PM, Peter Robinett wrote:
>
> > 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.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: Single Table Inheritance

[Naftoli Gugenheim]

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 Hartmann 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  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 Hartmann wrote:
>
> Naftoli would you please re-post your solution :) I could really use
> the help
>
> On Feb 5, 6:56 pm, Naftoli Gugenheim  wrote:
>
>
>
>
>
> > Peek --www.getpeek.com
> > Please forward any bad messages to feedb...@getpeek.com
>
> > -
>
> > Ross Mellgren 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  wrote:
> > >> Does my approach not work?
>
> > >> -
>
> > >> Mads Hartmann 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 J

Re: [Lift] Re: S.params disappear?

[Timothy Perrett]

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!
>> 
>> -
>> chas 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  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 
> 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,  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

Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)

[Timothy Perrett]

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  
>> 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 t

Re: [Lift] Re: S.params disappear?

[Ross Mellgren]

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!
> 
> -
> chas 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  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 
 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,  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
>> somet

Re: [Lift] Re: S.params disappear?

[Naftoli Gugenheim]

If "any other proxy" includes nginx, then a lot of people!

-
chas 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  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 
>> > 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,  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,  wrote:
>> >>
>> > Thanks, David.
>> >>
>> > That's a non-trivial exercise for me, so let me chase down anoth

[Lift] Re: Single Table Inheritance

[Mads Hartmann]

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  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 Hartmann wrote:
>
> Naftoli would you please re-post your solution :) I could really use
> the help
>
> On Feb 5, 6:56 pm, Naftoli Gugenheim  wrote:
>
>
>
>
>
> > Peek --www.getpeek.com
> > Please forward any bad messages to feedb...@getpeek.com
>
> > -
>
> > Ross Mellgren 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  wrote:
> > >> Does my approach not work?
>
> > >> -
>
> > >> Mads Hartmann 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  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 
> > >>> wrote:
>
> >  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 

Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)

[Naftoli Gugenheim]

One advantage is setting the value only in a session, request, or local 
(doWith) scope.

-
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  
> 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 messa

Re: [Lift] Re: S.params disappear?

[chas]

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  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 
>> > 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,  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,  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
>> > som

Re: [Lift] LiftRules inconsistencies (including FactoryMaker grump)

[Ross Mellgren]

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  
> 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 t

Re: [Lift] Flot 0.6 Upgrade Breaking Change Question

[David Pollak]

On Thu, Feb 4, 2010 at 4:07 PM, Peter Robinett wrote:

> 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.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)

[David Pollak]

On Fri, Feb 5, 2010 at 7:35 AM, Timothy Perrett 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:

   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.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

[Naftoli Gugenheim]

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 Hartmann wrote:

Naftoli would you please re-post your solution :) I could really use
the help

On Feb 5, 6:56 pm, Naftoli Gugenheim  wrote:
> Peek --www.getpeek.com
> Please forward any bad messages to feedb...@getpeek.com
>
> -
>
> Ross Mellgren 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  wrote:
> >> Does my approach not work?
>
> >> -
>
> >> Mads Hartmann 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  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 
> >>> wrote:
>
>  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 f

Re: [Lift] UML Diagram from existing lift application

[David Pollak]

On Thu, Feb 4, 2010 at 11:44 PM, Dick Hirsch  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.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

[Mads Hartmann]

Naftoli would you please re-post your solution :) I could really use
the help

On Feb 5, 6:56 pm, Naftoli Gugenheim  wrote:
> Peek --www.getpeek.com
> Please forward any bad messages to feedb...@getpeek.com
>
> -
>
> Ross Mellgren 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  wrote:
> >> Does my approach not work?
>
> >> -
>
> >> Mads Hartmann 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  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 
> >>> wrote:
>
>  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  wrote:
>
>   Mads Hartmann  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 dire

Re: [Lift] Re: Single Table Inheritance

[Naftoli Gugenheim]

Peek -- www.getpeek.com
Please forward any bad messages to feedb...@getpeek.com

-
Ross Mellgren 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  wrote:
>> Does my approach not work?
>> 
>> -
>> 
>> Mads Hartmann 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  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 
>>> wrote:
>> 
 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  wrote:
>> 
  Mads Hartmann  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
>> th

[Lift] Re: OSGi example, what to do to make it run?

[pere.vill...@gmail.com]

+1

On Feb 5, 5:32 pm, Ross Mellgren  wrote:
> On Feb 5, 2010, at 12:18 PM, David Pollak wrote:
>
> > On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger 
> >  wrote:
> > On 5 February 2010 15:05, Martin Ellis  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?

[David Pollak]

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  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 
> > 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,  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,  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,  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 i

Re: [Lift] OSGi example, what to do to make it run?

[Ross Mellgren]

On Feb 5, 2010, at 12:18 PM, David Pollak wrote:
> On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger 
>  wrote:
> On 5 February 2010 15:05, Martin Ellis  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: Single Table Inheritance

[Ross Mellgren]

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  wrote:
>> Does my approach not work?
>> 
>> -
>> 
>> Mads Hartmann 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  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 
>>> wrote:
>> 
 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  wrote:
>> 
  Mads Hartmann  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 scienti

Re: [Lift] Re: S.params disappear?

[Ross Mellgren]

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 
> 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,  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,  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,  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).
>> 
>>>

Re: [Lift] OSGi example, what to do to make it run?

[David Pollak]

On Fri, Feb 5, 2010 at 9:06 AM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> On 5 February 2010 15:05, Martin Ellis  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.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] OSGi example, what to do to make it run?

[Heiko Seeberger]

On 5 February 2010 15:05, Martin Ellis  wrote:

>
> Any offers/suggestions?  (Sorry, I realise the question more about
> OSGI than lift)
>

Indeed, let's discuss this off-list ...

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] Suggestion to extend Comet (ListenerManager) to selectively update subscribers

[Heiko Seeberger]

OK, its on RB (http://reviewboard.liftweb.net/r/206/) => Take a look ...

Heiko

On 5 February 2010 01:07, Timothy Perrett  wrote:

> Probally helpful if you share your prototype code?
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 5 Feb 2010, at 00:05, Heiko Seeberger 
> 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: 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.
>
>  --
> 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.
>



-- 
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] OSGi example, what to do to make it run?

[Martin Ellis]

On 5 February 2010 05:00, philip  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
" 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.

[Lift] Re: S.params disappear?

[Leo Lännenmäki]

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 
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,  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,  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,  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.com
> > 
>
> > >> 
> > 
>
> > >> >> .
> > >> >> For more options, visit this group at
> > >> >>http://groups.google.com/group/lift

[Lift] Re: S.params disappear?

[Leo Lännenmäki]

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: Accessing innerHTML during bind?

[Tim Maxwell]

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  wrote:
> On Thu, Feb 4, 2010 at 7:32 AM, Ross Mellgren  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 => { > > product="+prod.product}>{x}}}
> > >      )
> > >    }
> > >  }
>
> > > 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  wrote:
> > >> On Wed, Feb 3, 2010 at 12:44 PM, Tim Maxwell 
> > 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:
>
> > >>> This is the link text our marketing dept.
> > >>> creates
>
> > >>> 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 =>  > >> href={"/forced?product="+Helpers.urlEncode(prod.product)}>{body})
>
> > >> 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.com > >>>  >
> >  > 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.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, 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: LiftRules inconsistencies (including FactoryMaker grump)

[Timothy Perrett]

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  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  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)

[Marius]

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  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] LiftRules inconsistencies (including FactoryMaker grump)

[Timothy Perrett]

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: Facebook Application

[Leo Lännenmäki]

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.0&api_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 
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.

Re: [Lift] Re: Upgrade to Flot 0.6

[Aaron Valade]

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  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  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  
>> 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  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  
>> >> 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  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  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 
>> >> >> > > >> >> > > 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 
>> >> >> >> > >> >> >> > 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  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
>>
>> >> >> >> >  wrote:
>> >> >> >> > > Peter,
>>
>> >> >> >> > > What do you think of the upgrade (given that you're the most
>> >> >> >> Flot-ish Lift
>> >> >> >> > > committer)?
>>
>> >> >> >> > > Thanks

Re: [Lift] Mapped(Date)(Time) formatter/parser

[Indrajit Raychaudhuri]

On 05/02/10 5:28 PM, Jeppe Nejsum Madsen wrote:

Naftoli Gugenheim  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] Mapped(Date)(Time) formatter/parser

[Jeppe Nejsum Madsen]

Naftoli Gugenheim  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.

[Lift] Re: Facebook Application

[Mads Hartmann]

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  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.