date:20100301

[Lift] how to override superUser.dbDisplay_? = false

2010-03-01 Thread wm

superUser is defined in ProtoUser.

class User extends ProtoUser[User] {
  // I cannot make it work
  //override def superUser = override def dbDisplay_? = false
}

-- 
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] what's the equivalent of php's var $_FILES in lift?

2010-03-01 Thread wm

http://php.net/manual/en/reserved.variables.files.php

i.e. the array of items uploaded to the current script via the HTTP
POST method.

I know there is FileParamHolder, but I want to get multiple files in
the array.

Thanks.

-- 
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] newbie question : get lift to actually run (AbstractMethodError)

2010-03-01 Thread Naftoli Gugenheim

I think that AbstractMethodError always means either mismatched scala version 
or out of date class file.

-
Jeppe Nejsum Madsen wrote:

On Mon, Mar 1, 2010 at 3:39 PM, ojonam  wrote:
> Hello all,
>
> I am trying to launch a lift web app on my computer, but trying to use
> Snapshot 2.0 instead of 1.0 (which seems to have some problems with
> Scala 2.7.7).
>
> I have taken the following steps :
>
> - tried to create a lift blank app with 2.0-snapshot, adapting the
> archetype:generate command from the book as required

Try to show the complete command. Or look in the ML for commands that
work with 2.0-SNAPSHOT

> - once that is done, I modify the version of scala in my pom.xml
> - then I type 'mvn jetty:run'

> - somehow maven still downloads *both* the 2.7.1 and 2.7.7 versions of
> scala, and I get the warning that both of them exist

This sounds bad

> when trying to look at the webpage on localhost:8080, I am given the
> following error :
>
>  Request for / failed net.liftweb.http.SessionMaster$.mailbox_
> $eq(Lscala/actors/MessageQueue;)V
> java.lang.AbstractMethodError: net.liftweb.http.SessionMaster$.mailbox_
> $eq(Lscala/actors/MessageQueue;)V
>        at scala.actors.Actor$class.$init$(Actor.scala:370)
>        at net.liftweb.http.SessionMaster$.(LiftSession.scala:47)
>        at net.liftweb.http.SessionMaster$.(LiftSession.scala)
>        at net.liftweb.http.LiftSession.setSession(LiftSession.scala:138)
>        at net.liftweb.http.LiftSession$.createSession(LiftSession.scala:34)
>        at net.liftweb.http.LiftSession$$anonfun$1.apply(LiftSession.scala:
> 36)
>        at net.liftweb.http.LiftSession$$anonfun$1.apply(LiftSession.scala:
> 36)
>        at net.liftweb.http.LiftSession$.apply(LiftSession.scala:39)
>
>
> I have not posted the whole stacktrace, but will do so if necessary.
> Googling for this error gives me messages that are very old, and they
> don't apply to me.

You may have old code laying around. If code mysteriously fails, "mvn
clean" is your friend. Try; mvn clean jetty:run

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

Re: [Lift] reload application.properties

2010-03-01 Thread Naftoli Gugenheim

Is a dynamic menu not advantageous for production apps (e.g., a CMS)?
Would changing setSiteMap (if that's what it's called) to take a call by name 
be a bad idea?

-
David Pollak wrote:

On Mon, Mar 1, 2010 at 12:30 PM, Jeppe Nejsum Madsen wrote:

> David Pollak  writes:
>
> > The Props.get stuff is frozen the first time its accessed.  This is a
> > philosophical issue for me.  The properties should be fixed at start-up
> > time.  If there are things to vary, build an administrative interface or
> > some other thingy (e.g., a separate HTTP listener) that allows you to
> > manipulate the mutable configuration.
>
> And I agree very much in this philosophywhen we're talking
> production.
>
> I'm interested if you feel the same way about this during development? If
> so,
> stop reading as the rest will just be a rant, if not read on :-)
>
> I think the static nature of some of Lift's internals is one of the
> greatest productivity killers when it comes to rapidly start up with a
> new app where you quickly iterate different ideas (or even do many small
> changes in an existing app).
>
> 1) Change the menu structure? Restart server
>

Yes.  This is a problem.


> 2) Change the menu text? Restart server (yes I use properties for text
> and yes I need an app in different languages, see other thread :-)
>

This is a problem as well.


> 3) Change something in a mapped field? Restart server
>

This is unavoidable.  If the model changes, you have to re-sync to the RDBMS
and this requires a restart.  In practice, how often do you change your
model?


> 4) Change a field label? Restart server
>

With JRebel, the change to a field label should be reflected immediately.


>
> Using JRebel doesn't really help in these scenarios as the values are
> fixed at start-up.
>
> There are probably others, but these are the ones I can recall. Perhaps
> I'm being hit harder than others since 1) We need different languages
> and 2) You need to be logged in to see the app. Or perhaps I just don't
> develop in an efficient way who knows?
>
> It would be really nice for some of this to be picked up automatically
> when running in development mode. I still remember some time ago when I
> did a project in PHP. I don't like the PHP language very much, but you
> can't really beat the instant gratification of a code change: Just
> reload the page!
>

The problem is two-fold: (1) Lift is stateful and trying to morph the state
based on change to logic is non-trivial and (2) the amount of logic you can
get into a line of PHP vs. a line of Scala is 2-3 orders of magnitude
different.


>
> I think some of these issues could be solved easily, some will require
> more work and some may be impossible.
>
> - Reloading properties if the file has changed should be easy.
>

What do you keep in your properties file?  I keep database connection info
and service endpoints (e.g., Amazon S3 urls and passwords).  Changing this
stuff should require an app restart.

What do you keep in your properties files that can change at runtime?


>
> - Rebooting lift on the fly may not be easy, but perhaps some things
>  could be made reloadable (sitemap?). If you then write a JRebel plugin
>  (not a hard task) that triggers the reload when a class change is
>  detected, you will be one step closer to RAD nirvana.
>

SiteMap is an easy case.  If you'd be so kind as to open a ticket and assign
it to me, I'll make SiteMap morphable in development mode.  What other
things need changing?  Maybe the LiftRules stuff can be more dynamic at
runtime.


>
> I'm interested to hear if others have the same pain points as me (if
> not, I don't see this changing soon :-) and if there are some ideas how
> to remedy this (either by changing Lift or changing my development
> process :-)
>
> /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.

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

Re: [Lift] Re: ByList using OR instead of IN?

2010-03-01 Thread Naftoli Gugenheim

Maybe there could be
case class Or(qps: QueryParam*) extends QueryParam
or something like it? This way ByList could use IN but one can also do OR?

-
aw wrote:

I was searching for a prior thread and couldn't find it last night,
but I think I found it today:

http://groups.google.com/group/liftweb/browse_thread/thread/1cf5c0e153e98b47/5b60451a961ad78d?lnk=gst&q=ByList#
Is this the thread you are referring to?

It leaves me with much to be desired since the precise issue is
unclear and limited to Postgres. (It sounds like the author might
have experienced the issue with the IN (select ...) construct which
isn't even the same thing.)

I like James Iry's idea that the final SQL would be dependent on the
database dialect (Driver, I guess). I know that different vendors
have different limits for the number of elements in an IN clause. If
we had a limit of 250, for example, but had 300 items, you could
transform it into:

where (a in (1, 2, 3, ..., 250) or a in (251, 252, ..., 300))

That would be clever (and probably necessary if the database vendor
has a relatively small number for the maximum number of IN clause
elements). I'm pretty sure that Oracle has a limit of 1,000 elements
for an IN clause, and I can't imagine requiring more than that.

For the average case (< 30 items), the IN clause is going to be easier
to read, faster to parse, and likely faster to execute on almost all
database vendors -- that is why I like it.

(I luckily don't have a large data set right now, so this won't bother
me too much.)

--
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] Running parallel site load balanced

2010-03-01 Thread Naftoli Gugenheim

When you bind a form, you write functions that handle parts of the form. They 
are stored in memory and when the form is submitted they are executed. They are 
triggered by assigning them a unique id and using it as the form element's 
name. There's no way to preserve the functions to survive a restart. So it may 
be a good idea to warn users in advance about maintenance and that form data 
won't be submitted if the page is loaded before and submitted after.
It would be a nice feature if Lift could somehow detect query params that look 
like they are bound to functions but are not actually, and give the app a 
chance to notify the user that the form was not submitted, if such a thing is 
possible.

-
John Pletka wrote:

The ProtoExtendedSession looks like it might match what I'm looking for.
With that, they won't have to re-login, right?  We're trying to avoid
multi-page state-full workflows so that is not a problem.  Are you saying if
they have a form up, then submit it (say to update a record), that will
fail?  Will it generate an error that could be caught and nicely handled by
the app?

On a related note, any recommendations about a open-source loadbalancer that
would allow you to take a server offline for new connections, but still
allow the old connections to flow through?

On Mon, Mar 1, 2010 at 5:39 PM, David Pollak
wrote:

>
>
> On Mon, Mar 1, 2010 at 1:19 PM, Jeppe Nejsum Madsen wrote:
>
>> Ahh just saw David beat me to it with the other reply :-)
>>
>> John Pletka  writes:
>>
>> > It is a business application - lots of forms, reports, data lookups.
>>  I'm
>> > not too concerned about the performance on a single node - at any given
>> time
>> > we'll probably have a max of 1000 requests a minute coming in which I've
>> > seen Lift handle easily.  The biggest problem is we need near 100%
>> up-time.
>>
>> But you can have near 100% uptime with sticky sessions. What you can't
>> have is High Availability (HA), ie. users won't notice when a server
>> breaks.
>>
>
> There are 3 scenarios:
>
>1. Unplanned fail-over.  Having a hot standby and extended login
>session (See ProtoExtendedSession).  The user would lose a stateful
>multi-page wizard and would lose input to the particular screen they were
>on.  It would appear as a "glitch"... not optimal, but not end of the 
> world.
>2. Planned transfer.  You could shuffle all new sessions off to the new
>machine and let the old sessions age on the old server.  With a little 
> extra
>work, you could demark when a user was done with a logic task (e.g., going
>back to the home page) and use that as the trigger to move the session to
>the new machine.
>3. Upgrade that breaks the DB schema.  You're going to have downtime.
>No way around it.
>
>
>
>>
>> > That means having at least a second server in hot-standby mode
>> > (preferably parallel production), and some way to do upgrades without
>> > bringing the whole site offline.
>>
>> Doing rolling upgrades is never easy, even if you don't share state. You
>> may have all this figured, but you need to account for different app
>> versions running simultaneously, expanding/shrinking db upgrades etc.
>>
>> /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.
>

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

Re: [Lift] Running parallel site load balanced

2010-03-01 Thread John Pletka

The ProtoExtendedSession looks like it might match what I'm looking for.
With that, they won't have to re-login, right?  We're trying to avoid
multi-page state-full workflows so that is not a problem.  Are you saying if
they have a form up, then submit it (say to update a record), that will
fail?  Will it generate an error that could be caught and nicely handled by
the app?

On a related note, any recommendations about a open-source loadbalancer that
would allow you to take a server offline for new connections, but still
allow the old connections to flow through?

On Mon, Mar 1, 2010 at 5:39 PM, David Pollak
wrote:

>
>
> On Mon, Mar 1, 2010 at 1:19 PM, Jeppe Nejsum Madsen wrote:
>
>> Ahh just saw David beat me to it with the other reply :-)
>>
>> John Pletka  writes:
>>
>> > It is a business application - lots of forms, reports, data lookups.
>>  I'm
>> > not too concerned about the performance on a single node - at any given
>> time
>> > we'll probably have a max of 1000 requests a minute coming in which I've
>> > seen Lift handle easily.  The biggest problem is we need near 100%
>> up-time.
>>
>> But you can have near 100% uptime with sticky sessions. What you can't
>> have is High Availability (HA), ie. users won't notice when a server
>> breaks.
>>
>
> There are 3 scenarios:
>
>1. Unplanned fail-over.  Having a hot standby and extended login
>session (See ProtoExtendedSession).  The user would lose a stateful
>multi-page wizard and would lose input to the particular screen they were
>on.  It would appear as a "glitch"... not optimal, but not end of the 
> world.
>2. Planned transfer.  You could shuffle all new sessions off to the new
>machine and let the old sessions age on the old server.  With a little 
> extra
>work, you could demark when a user was done with a logic task (e.g., going
>back to the home page) and use that as the trigger to move the session to
>the new machine.
>3. Upgrade that breaks the DB schema.  You're going to have downtime.
>No way around it.
>
>
>
>>
>> > That means having at least a second server in hot-standby mode
>> > (preferably parallel production), and some way to do upgrades without
>> > bringing the whole site offline.
>>
>> Doing rolling upgrades is never easy, even if you don't share state. You
>> may have all this figured, but you need to account for different app
>> versions running simultaneously, expanding/shrinking db upgrades etc.
>>
>> /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.
>

-- 
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: About the url rewrite (more thant one params and get 404 not found error)

2010-03-01 Thread Neil.Lv

OK, Got it, Thank you very much!

On Mar 2, 3:01 am, David Pollak  wrote:
> On Sun, Feb 28, 2010 at 8:28 PM, Neil.Lv  wrote:
> > Hi all,
>
> >  I have a silly question about the url rewrite in the lift.
> >  It has another two params in the url after the img.
>
> >  http://localhost:8080/show/img/version/id
>
> >  The url works fine.
> >  =>http://localhost:8080/show/img
> >  =>http://localhost:8080/show/img/v1/
> >  =>http://localhost:8080/show/img/v1/1
>
> >  Get 404 error if the "/" string is not added at the end of the url
> > (the id param isn't supplied)
> >  =>http://localhost:8080/show/img/v1
>
> >  So, how can i rewrite the url and set the sitemap can make this link
> > (  http://localhost:8080/show/img/v1 )
> >  works fine as (  http://localhost:8080/show/img/v1/ ) when the id
> > is not supplied.
>
> >  Here is the code:
>
> > ###
> >  case RewriteRequest(
> >  ParsePath(List("show", "img", version, id), _, _,_), _, _) =>
> >RewriteResponse(List("show", "img"),
> >  Map("version" -> version, "id" -> id)
> >  )
> > ###
>
> This is just basic pattern matching stuff.  So,
>
> case RewriteRequest(
>  ParsePath("show" :: "img" :: version :: rest, _, _,_), _, _) =>
> RewriteResponse(List("show", "img"),
>  Map("version" -> version, "id" -> (rest.firstOption getOrElse "N/A"))
>  )
>
> Please pick up a copy of one of the Scala books and look at the pattern
> matching section related to Lists.  There's a lot of flexibility that's no
> Lift-specific, but that Lift leverages.
>
> val entries = Menu(Loc("Home", List("index"), "Home")) ::
>
>
>
> > Menu(Loc("show", List("show"), "show", Hidden)) :: User.sitemap
>
> > ###
>
> >  BTW, I use the LiftView to handle the request.
>
> > ###
> > class show extends LiftView {
> >  def dispatch = {
> >case "img" => imgDispatch _
> >case _ => allDispatch _
> >  }
>
> >  def imgDispatch(): Box[NodeSeq] = {
> >...
> >  }
>
> >  def allDispatch(): Box[NodeSeq] = {
> >...
> >  }
> > }
> > ###
>
> >  Thanks very much!
>
> > Cheers,
> >  Neil
>
> > --
> > 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: New logging code is in master

2010-03-01 Thread aw

Very nice!  I am looking forward to this.

On Feb 28, 8:14 am, Jeppe Nejsum Madsen  wrote:
> The new logging code is now in master and should be fully usable.
> Therefore, the existing logging code has been deprecated.
>
> I've added a Wiki article 
> here:http://wiki.github.com/dpp/liftweb/logging-in-lift
>
> /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: ByList using OR instead of IN?

2010-03-01 Thread aw

I was searching for a prior thread and couldn't find it last night,
but I think I found it today:

http://groups.google.com/group/liftweb/browse_thread/thread/1cf5c0e153e98b47/5b60451a961ad78d?lnk=gst&q=ByList#
Is this the thread you are referring to?

where (a in (1, 2, 3, ..., 250) or a in (251, 252, ..., 300))

For the average case (< 30 items), the IN clause is going to be easier
to read, faster to parse, and likely faster to execute on almost all
database vendors -- that is why I like it.

(I luckily don't have a large data set right now, so this won't bother
me too much.)

67 matches

Mail list logo