[Lift] Re: Binding Problem - Help

[Oliver]

Thanks for all the help, it appears to all be working now - I had a
feeling I was going to be fed to the lions, wolves, tigers and bears
if I didn't find a fix, and quick.

One question, does the name generation have to be based on a random
number generator? I realize, with the length of the number I probably
won't see the same error in the life of the universe, but you never
know your luck.

On Mon, Dec 15, 2008 at 12:36 PM, David Pollak
 wrote:
>
>
> On Sun, Dec 14, 2008 at 5:06 PM, Oliver  wrote:
>>
>> David
>>
>> Thanks for the prompt reply.
>>
>> I'll upgrade to the latest version of lift so I can use the fix when
>> it comes in. Is everything relatively stable at the current snapshot?
>
> I've pushed the change.  Give it an hour or so to get built in Maven.
> The APIs are changing right now, but the code itself is stable (the APIs
> changes have not introduced defects.)
> Thanks,
> David
>
>>
>> cheers
>> Oliver
>>
>> On Mon, Dec 15, 2008 at 11:47 AM, David Pollak
>>  wrote:
>> > Okay,
>> > The problem is that your computer is too fast. :-)
>> > Lift assigns function names based on the nano time.  It turns out that
>> > the
>> > methods are getting called so fast, there's no nano tick and the order
>> > of
>> > the function creation is not reflected in the function name.
>> > I've got a fix.  I'll roll it into Lift tonight or tomorrow.
>> > Thanks,
>> > David
>> >
>> > On Sun, Dec 14, 2008 at 3:44 PM, Oliver  wrote:
>> >>
>> >> Hi,
>> >>
>> >> Its Ubuntu Gutsy running a virtual vsx.
>> >> The processor is a dual cpu 2.8
>> >> Theres 2GB of memory, but Apache tomcat has 500MB.
>> >>
>> >> I'm running on a snapshot of lift webkit frozen at
>> >> 0.10-20080930.234135-129
>> >>
>> >> I'll send the html in a moment.
>> >> Cheers
>> >> Oliver
>> >>
>> >> On Mon, Dec 15, 2008 at 10:28 AM, David Pollak
>> >>  wrote:
>> >> >
>> >> >
>> >> > On Sun, Dec 14, 2008 at 3:17 PM, Oliver  wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> I've got a error on one of our Apache/Tomcat servers with binding,
>> >> >> it
>> >> >> works in Jetty and another Apache/Tomcat server.
>> >> >>
>> >> >> It looks like lift is calling some of the function setters after
>> >> >> calling a method on a StatefullSnippet. For example,
>> >> >> in the example below, v => who(Full(v)) would be getting called
>> >> >> after
>> >> >> doProcess() is called
>> >> >>bind("hello", xhtml, "whoField" --> text(who.openOr(""),
>> >> >> v
>> >> >> => who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
>> >> >> doProcess() ) )
>> >> >>
>> >> >> Has anyone got any idea what might be going on?
>> >> >
>> >> > What kind of machine is the problem happening on (OS, processor,
>> >> > speed,
>> >> > number of processors)?
>> >> > Can you send me the static HTML generated by a page that's causing
>> >> > the
>> >> > problem?
>> >> > Thanks,
>> >> > David
>> >> >
>> >> >>
>> >> >> cheers
>> >> >> Oliver
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Lift, the simply functional web framework http://liftweb.net
>> >> > Collaborative Task Management http://much4.us
>> >> > Follow me: http://twitter.com/dpp
>> >> > Git some: http://github.com/dpp
>> >> >
>> >> > >
>> >> >
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Lift, the simply functional web framework http://liftweb.net
>> > Collaborative Task Management http://much4.us
>> > Follow me: http://twitter.com/dpp
>> > Git some: http://github.com/dpp
>> >
>> > >
>> >
>>
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Working CRUD based on "To Do" tutorial

[Stefan Scott]

OK, I've gotten through the tutorial (page 23).

I was doing a bit of testing - I tried putting a string of length 2
into field 'desc' (which is supposed to be at least 3 characters
long), and I didn't get an error message.

Too tired now to check to see if the validation code for 'desc' is
actually getting called - will look later.


I also added another field ('location', varchar(63)) which accepts
null values, and used  rather than  so as to display rows
with aligned columns. While clicking around some more I noticed that
if the record has been saved and the 'location' field is null there's
nothing to click on to make it "swap" from a displayed field to an
editable field - in case you wanted to enter a 'location' later.


Next I'll probably want to poke around and see what lines I have to
change to try it with H2 instead of Derby.


All in all, very exciting to have a working Ajaxified CRUD web-db in
so few lines of code in a compiled, type-safe language.


- Stefan Scott




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Binding Problem - Help

[David Pollak]

On Sun, Dec 14, 2008 at 5:06 PM, Oliver  wrote:

>
> David
>
> Thanks for the prompt reply.
>
> I'll upgrade to the latest version of lift so I can use the fix when
> it comes in. Is everything relatively stable at the current snapshot?


I've pushed the change.  Give it an hour or so to get built in Maven.

The APIs are changing right now, but the code itself is stable (the APIs
changes have not introduced defects.)

Thanks,

David


>
>
> cheers
> Oliver
>
> On Mon, Dec 15, 2008 at 11:47 AM, David Pollak
>  wrote:
> > Okay,
> > The problem is that your computer is too fast. :-)
> > Lift assigns function names based on the nano time.  It turns out that
> the
> > methods are getting called so fast, there's no nano tick and the order of
> > the function creation is not reflected in the function name.
> > I've got a fix.  I'll roll it into Lift tonight or tomorrow.
> > Thanks,
> > David
> >
> > On Sun, Dec 14, 2008 at 3:44 PM, Oliver  wrote:
> >>
> >> Hi,
> >>
> >> Its Ubuntu Gutsy running a virtual vsx.
> >> The processor is a dual cpu 2.8
> >> Theres 2GB of memory, but Apache tomcat has 500MB.
> >>
> >> I'm running on a snapshot of lift webkit frozen at
> >> 0.10-20080930.234135-129
> >>
> >> I'll send the html in a moment.
> >> Cheers
> >> Oliver
> >>
> >> On Mon, Dec 15, 2008 at 10:28 AM, David Pollak
> >>  wrote:
> >> >
> >> >
> >> > On Sun, Dec 14, 2008 at 3:17 PM, Oliver  wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> I've got a error on one of our Apache/Tomcat servers with binding, it
> >> >> works in Jetty and another Apache/Tomcat server.
> >> >>
> >> >> It looks like lift is calling some of the function setters after
> >> >> calling a method on a StatefullSnippet. For example,
> >> >> in the example below, v => who(Full(v)) would be getting called after
> >> >> doProcess() is called
> >> >>bind("hello", xhtml, "whoField" --> text(who.openOr(""), v
> >> >> => who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
> >> >> doProcess() ) )
> >> >>
> >> >> Has anyone got any idea what might be going on?
> >> >
> >> > What kind of machine is the problem happening on (OS, processor,
> speed,
> >> > number of processors)?
> >> > Can you send me the static HTML generated by a page that's causing the
> >> > problem?
> >> > Thanks,
> >> > David
> >> >
> >> >>
> >> >> cheers
> >> >> Oliver
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Lift, the simply functional web framework http://liftweb.net
> >> > Collaborative Task Management http://much4.us
> >> > Follow me: http://twitter.com/dpp
> >> > Git some: http://github.com/dpp
> >> >
> >> > >
> >> >
> >>
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Collaborative Task Management http://much4.us
> > Follow me: http://twitter.com/dpp
> > Git some: http://github.com/dpp
> >
> > >
> >
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Key phrase from the "To Do" tutorial

[David Pollak]

On Sun, Dec 14, 2008 at 3:14 PM, Stefan Scott wrote:

>
> "In Lift, the snippet is the equivalent of a Rails controller: it is
> the instantiation of a class and invocation of a method on the class.
> Because you can have multiple snippets on a page, you can call out
> multiple logic streams on a given page and there's no need to choose
> the 'primary' logic stream." (page 12)
>
> (quotes added around the 'primary')
>
> 
>
> Getting these kind of "many"-or-"one" design decisions right is
> crucial for a web app framework - and /lift/ (influenced by Seaside's
> "multiple control flow"?) definitely got this one right!


Thanks!

We aim to please (and to get design decisions right)


>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.

[David Pollak]

Mike,
There was a recent breaking change to Lift (Marius and I are doing major
code cleanup and this means lots of breaks to the APIs... this will all end
by the end of the month.)

Any of the LiftRules stuff that contains append/prepend has a new form:

LiftRules.appendEarly(makeUtf8)

becomes:

LiftRules.early.append(makeUtf8)

Thanks,

David

On Sun, Dec 14, 2008 at 5:09 PM, mike beckerle  wrote:

>
> Certainly there is nothing blocking java in any way.
>
> However, just trying again, this time it is working better. Somebody
> has fixed something on the server end I'm sure.  I'm doing the exact
> same thing, but it seems to be able to communicate properly with the
> associated servers..
>
> However, mvn jetty:run -U still fails
>
> Downloading:
> http://scala-tools.org/repo-snapshots/net/liftweb/lift-widgets/0.10-SNAPSHOT/lift-widgets-0.10-SNAPSHOT.jar
> 243Kdownloaded
> [INFO] [compiler:compile]
> [INFO] Nothing to compile - all classes are up to date
> [INFO] [scala:compile {execution: default}]
> [INFO] suggestion: remove the scalaVersion from pom.xml
> [ERROR] /home/mbeckerle/todo/src/main/scala
> [INFO] Compiling 3 source files to /home/mbeckerle/todo/target/classes
> Downloading:
> http://scala-tools.org/repo-releases/org/scala-lang/scala-compiler/2.7.2/scala-compiler-2.7.2.jar
> 6083Kdownloaded
> [WARNING] /home/mbeckerle/todo/src/main/scala/bootstrap/liftweb/
> Boot.scala:42: error: value appendEarly is not a member of object
> net.liftweb.http.LiftRules
> [WARNING] LiftRules.appendEarly(makeUtf8)
> [WARNING]   ^
> [WARNING] one error found
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO] --
>
>
> On Dec 14, 2:11 pm, Josh Suereth  wrote:
> > Is your firewall blocking java?  This would cause maven to be unable
> > to download dependencies.
> >
> > Sent from my iPhone
> >
> > On Dec 14, 2008, at 1:13 PM, mike beckerle  wrote:
> >
> >
> >
> > > I can browse to the location just fine. There is no proxy or other
> > > wierdness between me and the internet. Just the usual home firewall
> > > (NAT) device.
> >
> > > On Dec 13, 1:45 pm, "David Pollak" 
> > > wrote:
> > >> On Sat, Dec 13, 2008 at 10:34 AM, mike beckerle
> > >>  wrote:
> >
> > >>> This did not work. Still failed.
> >
> > >>> There are disturbing messages in here about blacklisting sites due
> > >>> to
> > >>> errors and such.
> >
> > >>> becke...@ubuntu810desktop:~/todo$ mvn jetty:run -U
> > >>> [INFO] Scanning for projects...
> > >>> [INFO] Searching repository for plugin with prefix: 'jetty'.
> > >>> [INFO] org.apache.maven.plugins: checking for updates from scala-
> > >>> tools.org
> > >>> [WARNING] repository metadata for: 'org.apache.maven.plugins' could
> > >>> not be retrieved from repository: scala-tools.org due to an error:
> > >>> Error transferring file
> > >>> [INFO] Repository 'scala-tools.org' will be blacklisted
> >
> > >> This is the problem.  For some reason, you're not able to connect to
> > >> scala-tools.org.
> >
> > >> Are you behind an HTTP proxy?
> >
> > >> Does the proxy have whitelist/blacklist of sites and/or IP addresses?
> >
> > >> Can you browse tohttp://scala-tools.org/repo-snapshots/net/liftweb/
> > >> with
> > >> your web browser?
> >
> > >>> [INFO] org.apache.maven.plugins: checking for updates from central
> > >>> [INFO] org.codehaus.mojo: checking for updates from central
> > >>> [INFO] artifact org.scala-tools:maven-scala-plugin: checking for
> > >>> updates from central
> > >>> [INFO]
> > >>> ---
> > >>> ---
> > >>> --
> > >>> [ERROR] BUILD ERROR
> > >>> [INFO]
> > >>> ---
> > >>> ---
> > >>> --
> > >>> [INFO] The plugin 'org.scala-tools:maven-scala-plugin' does not
> > >>> exist
> > >>> or no valid version could be found
> > >>> [INFO]
> > >>> ---
> > >>> ---
> > >>> --
> > >>> [INFO] For more information, run Maven with the -e switch
> > >>> [INFO]
> > >>> ---
> > >>> ---
> > >>> --
> > >>> [INFO] Total time: 26 seconds
> > >>> [INFO] Finished at: Sat Dec 13 13:29:24 EST 2008
> > >>> [INFO] Final Memory: 1M/4M
> > >>> [INFO]
> > >>> ---
> > >>> ---
> > >>> --
> > >>> mbecke...@ubuntu810desktop:~/todo$
> >
> > >>> On Dec 11, 7:57 am, "David Bernard" 
> > >>> wrote:
> >  The first time you run jetty :
> >
> >  mvn jetty:run -U
> >
> >  I learn a way to avoid this problem (for futur archetype, I'll
> >  try it
> >  next week-end)
> >
> >  /dav

[Lift] Key phrase from the "To Do" tutorial

[Stefan Scott]

"In Lift, the snippet is the equivalent of a Rails controller: it is
the instantiation of a class and invocation of a method on the class.
Because you can have multiple snippets on a page, you can call out
multiple logic streams on a given page and there’s no need to choose
the 'primary' logic stream." (page 12)

(quotes added around the 'primary')



Getting these kind of "many"-or-"one" design decisions right is
crucial for a web app framework - and /lift/ (influenced by Seaside's
"multiple control flow"?) definitely got this one right!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.

[mike beckerle]

Certainly there is nothing blocking java in any way.

However, just trying again, this time it is working better. Somebody
has fixed something on the server end I'm sure.  I'm doing the exact
same thing, but it seems to be able to communicate properly with the
associated servers..

However, mvn jetty:run -U still fails

Downloading: 
http://scala-tools.org/repo-snapshots/net/liftweb/lift-widgets/0.10-SNAPSHOT/lift-widgets-0.10-SNAPSHOT.jar
243K downloaded
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [scala:compile {execution: default}]
[INFO] suggestion: remove the scalaVersion from pom.xml
[ERROR] /home/mbeckerle/todo/src/main/scala
[INFO] Compiling 3 source files to /home/mbeckerle/todo/target/classes
Downloading: 
http://scala-tools.org/repo-releases/org/scala-lang/scala-compiler/2.7.2/scala-compiler-2.7.2.jar
6083K downloaded
[WARNING] /home/mbeckerle/todo/src/main/scala/bootstrap/liftweb/
Boot.scala:42: error: value appendEarly is not a member of object
net.liftweb.http.LiftRules
[WARNING] LiftRules.appendEarly(makeUtf8)
[WARNING]   ^
[WARNING] one error found
[INFO]

[ERROR] BUILD FAILURE
[INFO] --


On Dec 14, 2:11 pm, Josh Suereth  wrote:
> Is your firewall blocking java?  This would cause maven to be unable  
> to download dependencies.
>
> Sent from my iPhone
>
> On Dec 14, 2008, at 1:13 PM, mike beckerle  wrote:
>
>
>
> > I can browse to the location just fine. There is no proxy or other
> > wierdness between me and the internet. Just the usual home firewall
> > (NAT) device.
>
> > On Dec 13, 1:45 pm, "David Pollak" 
> > wrote:
> >> On Sat, Dec 13, 2008 at 10:34 AM, mike beckerle  
> >>  wrote:
>
> >>> This did not work. Still failed.
>
> >>> There are disturbing messages in here about blacklisting sites due  
> >>> to
> >>> errors and such.
>
> >>> becke...@ubuntu810desktop:~/todo$ mvn jetty:run -U
> >>> [INFO] Scanning for projects...
> >>> [INFO] Searching repository for plugin with prefix: 'jetty'.
> >>> [INFO] org.apache.maven.plugins: checking for updates from scala-
> >>> tools.org
> >>> [WARNING] repository metadata for: 'org.apache.maven.plugins' could
> >>> not be retrieved from repository: scala-tools.org due to an error:
> >>> Error transferring file
> >>> [INFO] Repository 'scala-tools.org' will be blacklisted
>
> >> This is the problem.  For some reason, you're not able to connect to
> >> scala-tools.org.
>
> >> Are you behind an HTTP proxy?
>
> >> Does the proxy have whitelist/blacklist of sites and/or IP addresses?
>
> >> Can you browse tohttp://scala-tools.org/repo-snapshots/net/liftweb/ 
> >> with
> >> your web browser?
>
> >>> [INFO] org.apache.maven.plugins: checking for updates from central
> >>> [INFO] org.codehaus.mojo: checking for updates from central
> >>> [INFO] artifact org.scala-tools:maven-scala-plugin: checking for
> >>> updates from central
> >>> [INFO]
> >>> ---
> >>> ---
> >>> --
> >>> [ERROR] BUILD ERROR
> >>> [INFO]
> >>> ---
> >>> ---
> >>> --
> >>> [INFO] The plugin 'org.scala-tools:maven-scala-plugin' does not  
> >>> exist
> >>> or no valid version could be found
> >>> [INFO]
> >>> ---
> >>> ---
> >>> --
> >>> [INFO] For more information, run Maven with the -e switch
> >>> [INFO]
> >>> ---
> >>> ---
> >>> --
> >>> [INFO] Total time: 26 seconds
> >>> [INFO] Finished at: Sat Dec 13 13:29:24 EST 2008
> >>> [INFO] Final Memory: 1M/4M
> >>> [INFO]
> >>> ---
> >>> ---
> >>> --
> >>> mbecke...@ubuntu810desktop:~/todo$
>
> >>> On Dec 11, 7:57 am, "David Bernard" 
> >>> wrote:
>  The first time you run jetty :
>
>  mvn jetty:run -U
>
>  I learn a way to avoid this problem (for futur archetype, I'll  
>  try it
>  next week-end)
>
>  /davidB
>
>  On Thu, Dec 11, 2008 at 13:31, Josh Suereth  
>  
> >>> wrote:
> > Thanks, and sorry for the typos.
>
> > What you want (in either your ~/.m2/settings.xml or
> >>> ${project.dir}/pom.xml)
> > is the following:
>
> > 
> >     
> >       scala-tools.org
>
> >       Scala-tools Maven2 Repository
> >       http://scala-tools.org/repo-releases
> >     
> >     
>
> >       snapshots.scala-tools.org
> >       Scala-tools Maven2 Snapshot Repository
> >       http://scala-tools.org/repo-snapshots
>
> >     
> >   
>
> > On Thu, Dec 11, 2008 at 7:24 AM, Tim Perrett  
> > 
> >>> wrote:
>
> >> I think Josh meant to say "defined in your pom.xml"
>
> >> On Dec 11, 12:14 pm, Josh Suereth   
> >> wrote:
> >>> Make sure the scala-tools snapshot repository

[Lift] Re: Binding Problem - Help

[Oliver]

David

Thanks for the prompt reply.

I'll upgrade to the latest version of lift so I can use the fix when
it comes in. Is everything relatively stable at the current snapshot?

cheers
Oliver

On Mon, Dec 15, 2008 at 11:47 AM, David Pollak
 wrote:
> Okay,
> The problem is that your computer is too fast. :-)
> Lift assigns function names based on the nano time.  It turns out that the
> methods are getting called so fast, there's no nano tick and the order of
> the function creation is not reflected in the function name.
> I've got a fix.  I'll roll it into Lift tonight or tomorrow.
> Thanks,
> David
>
> On Sun, Dec 14, 2008 at 3:44 PM, Oliver  wrote:
>>
>> Hi,
>>
>> Its Ubuntu Gutsy running a virtual vsx.
>> The processor is a dual cpu 2.8
>> Theres 2GB of memory, but Apache tomcat has 500MB.
>>
>> I'm running on a snapshot of lift webkit frozen at
>> 0.10-20080930.234135-129
>>
>> I'll send the html in a moment.
>> Cheers
>> Oliver
>>
>> On Mon, Dec 15, 2008 at 10:28 AM, David Pollak
>>  wrote:
>> >
>> >
>> > On Sun, Dec 14, 2008 at 3:17 PM, Oliver  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I've got a error on one of our Apache/Tomcat servers with binding, it
>> >> works in Jetty and another Apache/Tomcat server.
>> >>
>> >> It looks like lift is calling some of the function setters after
>> >> calling a method on a StatefullSnippet. For example,
>> >> in the example below, v => who(Full(v)) would be getting called after
>> >> doProcess() is called
>> >>bind("hello", xhtml, "whoField" --> text(who.openOr(""), v
>> >> => who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
>> >> doProcess() ) )
>> >>
>> >> Has anyone got any idea what might be going on?
>> >
>> > What kind of machine is the problem happening on (OS, processor, speed,
>> > number of processors)?
>> > Can you send me the static HTML generated by a page that's causing the
>> > problem?
>> > Thanks,
>> > David
>> >
>> >>
>> >> cheers
>> >> Oliver
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Lift, the simply functional web framework http://liftweb.net
>> > Collaborative Task Management http://much4.us
>> > Follow me: http://twitter.com/dpp
>> > Git some: http://github.com/dpp
>> >
>> > >
>> >
>>
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Binding Problem - Help

[David Pollak]

Okay,
The problem is that your computer is too fast. :-)

Lift assigns function names based on the nano time.  It turns out that the
methods are getting called so fast, there's no nano tick and the order of
the function creation is not reflected in the function name.

I've got a fix.  I'll roll it into Lift tonight or tomorrow.

Thanks,

David

On Sun, Dec 14, 2008 at 3:44 PM, Oliver  wrote:

>
> Hi,
>
> Its Ubuntu Gutsy running a virtual vsx.
> The processor is a dual cpu 2.8
> Theres 2GB of memory, but Apache tomcat has 500MB.
>
> I'm running on a snapshot of lift webkit frozen at 0.10-20080930.234135-129
>
> I'll send the html in a moment.
> Cheers
> Oliver
>
> On Mon, Dec 15, 2008 at 10:28 AM, David Pollak
>  wrote:
> >
> >
> > On Sun, Dec 14, 2008 at 3:17 PM, Oliver  wrote:
> >>
> >> Hi,
> >>
> >> I've got a error on one of our Apache/Tomcat servers with binding, it
> >> works in Jetty and another Apache/Tomcat server.
> >>
> >> It looks like lift is calling some of the function setters after
> >> calling a method on a StatefullSnippet. For example,
> >> in the example below, v => who(Full(v)) would be getting called after
> >> doProcess() is called
> >>bind("hello", xhtml, "whoField" --> text(who.openOr(""), v
> >> => who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
> >> doProcess() ) )
> >>
> >> Has anyone got any idea what might be going on?
> >
> > What kind of machine is the problem happening on (OS, processor, speed,
> > number of processors)?
> > Can you send me the static HTML generated by a page that's causing the
> > problem?
> > Thanks,
> > David
> >
> >>
> >> cheers
> >> Oliver
> >>
> >>
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Collaborative Task Management http://much4.us
> > Follow me: http://twitter.com/dpp
> > Git some: http://github.com/dpp
> >
> > >
> >
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Dano]

Marius,

Is there someway you can communicate what the 'from' and 'to' changes
are so that I can have a chance at being able to fix my now broken
code?


Dan

On Dec 13, 12:31 pm, Marius  wrote:
> All,
>
> I committed a bunch of changes inLiftRules. In a previous thread
> Jorge suggested the abstraction ofLiftRulesvariables. Lists of
> functions are now abstracted by RulesSeq trait, which contains prepend
> and append functions. Note that if you're calling prepend/append
> functions after boot they will throw an exception. If there are
> compelling reasons not to do this please let us know. This is just a
> mechanism to enforce the use of these functions on startup.
>
> Br's,
> Marius
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Binding Problem - Help

[Oliver]

Hi,

Its Ubuntu Gutsy running a virtual vsx.
The processor is a dual cpu 2.8
Theres 2GB of memory, but Apache tomcat has 500MB.

I'm running on a snapshot of lift webkit frozen at 0.10-20080930.234135-129

I'll send the html in a moment.
Cheers
Oliver

On Mon, Dec 15, 2008 at 10:28 AM, David Pollak
 wrote:
>
>
> On Sun, Dec 14, 2008 at 3:17 PM, Oliver  wrote:
>>
>> Hi,
>>
>> I've got a error on one of our Apache/Tomcat servers with binding, it
>> works in Jetty and another Apache/Tomcat server.
>>
>> It looks like lift is calling some of the function setters after
>> calling a method on a StatefullSnippet. For example,
>> in the example below, v => who(Full(v)) would be getting called after
>> doProcess() is called
>>bind("hello", xhtml, "whoField" --> text(who.openOr(""), v
>> => who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
>> doProcess() ) )
>>
>> Has anyone got any idea what might be going on?
>
> What kind of machine is the problem happening on (OS, processor, speed,
> number of processors)?
> Can you send me the static HTML generated by a page that's causing the
> problem?
> Thanks,
> David
>
>>
>> cheers
>> Oliver
>>
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Binding Problem - Help

[David Pollak]

On Sun, Dec 14, 2008 at 3:17 PM, Oliver  wrote:

>
> Hi,
>
> I've got a error on one of our Apache/Tomcat servers with binding, it
> works in Jetty and another Apache/Tomcat server.
>
> It looks like lift is calling some of the function setters after
> calling a method on a StatefullSnippet. For example,
> in the example below, v => who(Full(v)) would be getting called after
> doProcess() is called
>bind("hello", xhtml, "whoField" --> text(who.openOr(""), v
> => who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
> doProcess() ) )
>
> Has anyone got any idea what might be going on?


What kind of machine is the problem happening on (OS, processor, speed,
number of processors)?

Can you send me the static HTML generated by a page that's causing the
problem?

Thanks,

David


>
>
> cheers
> Oliver
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: new to lift ... horizontal scaling of databases?

[David Pollak]

On Sun, Dec 14, 2008 at 2:26 PM, Baconeater  wrote:

>
> On Dec 1, 11:30 am, "David Pollak" 
> wrote:
> > Lift has built in DB sharding.  You can have multiple RDBMS connection
> > identifiers.  Each record has its connection identifier associated with
> it
> > (where it came from) and there's a place in each MetaModel to insert a
> > function to calculate the connection identifier given a record to be
> saved
> > or a primary key to be recalled.
>
> Revisiting this question from a few weeks ago.  Very interesting to
> hear that Lift has thought of this ahead of time.


Not really.  The feature grew out of a car ride with Alex 
Payne  .


>
>
> Had to work through the ToDo tutorial to learn a little more Lift
> before posting.
>
> Is the idea to put something in
> net.liftweb.mapper.DefaultConnectionIdentifier to handle the sharding
> for me?


No.  You're going to have to handle the sharding decisions yourself by
overriding appropriate methods on the meta model to make the sharing
decisions.


>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Binding Problem - Help

[Oliver]

Hi,

I've got a error on one of our Apache/Tomcat servers with binding, it
works in Jetty and another Apache/Tomcat server.

It looks like lift is calling some of the function setters after
calling a method on a StatefullSnippet. For example,
in the example below, v => who(Full(v)) would be getting called after
doProcess() is called
bind("hello", xhtml, "whoField" --> text(who.openOr(""), v
=> who(Full(v)) ), "submit" --> submit(?("Send"), ignore =>
doProcess() ) )

Has anyone got any idea what might be going on?

cheers
Oliver

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] PROBLEM GONE: XML problems in ToDo tutorial?

[Stefan Scott]

"Problem" gone now.

After a good night's sleep I just repeated your steps exactly as in
the tutorial (only adding the 'cd todo' before the first 'mvn
jetty:run' as already mentioned) and this everything worked fine.

I'm new to Maven and I was trying it out on various projects from
other (older) /lift/ tutorials as well, so the wires must've gotten
crossed somewhere.

Thanks.

- Stefan Scott



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: new to lift ... horizontal scaling of databases?

[Baconeater]

On Dec 1, 11:30 am, "David Pollak" 
wrote:
> Lift has built in DB sharding.  You can have multiple RDBMS connection
> identifiers.  Each record has its connection identifier associated with it
> (where it came from) and there's a place in each MetaModel to insert a
> function to calculate the connection identifier given a record to be saved
> or a primary key to be recalled.

Revisiting this question from a few weeks ago.  Very interesting to
hear that Lift has thought of this ahead of time.

Had to work through the ToDo tutorial to learn a little more Lift
before posting.

Is the idea to put something in
net.liftweb.mapper.DefaultConnectionIdentifier to handle the sharding
for me?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Marius]

So LiftConfig would take the role of LiftRules from API perspective
meaning that LiftRules could be completely hidden from Lift users but
available internally to Lift only ?

Still from maintainability perspective initializing LifRules with a
LiftConfig may imply lots of assignments (unless LiftRules will
reference a LiftConfig in which case LiftRules code needs to change to
use LiftConfig) or when we'd want to expose some new stuff we'd have
to add it in two different places LiftConfig toexpose it to users and
LiftRules so that Lift code to use that.

Otherwise not a bad idea ...

Br's,
Marius

On Dec 14, 5:21 pm, "Viktor Klang"  wrote:
> On Sun, Dec 14, 2008 at 4:01 PM, David Pollak 
>
>
> > wrote:
>
> > On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang wrote:
>
> >> David,
>
> >> sounds reasonable.
>
> >> So being able to call prepend/append after boot() makes no sense.
>
> >> In the light of htis, it shouldn't be possible to call the prepend/append
> >> outside of boot.
> >> I suggest my approach described previously. (Injecting an initialization
> >> context into boot and use that to configure LiftRules, then we don't expose
> >> the mutativity in LiftRules.
> >> Result: No runtime exceptions, no confusion on when to configure the
> >> webapp etc.
>
> > I have no idea what this means or how to translate it into code.  Can you
> > give me an example of code that "injects an initialization context into
> > boot"?
>
> class Boot
> {
>    def boot(val lc: LiftConfig) =
>    {
>           add all configuration to LiftConfig
>    }
>
> }
>
> and then in the code that lookups, creates and calls Boot.boot (haven't got
> access to the repository on this machine)
>
> just add/modify the code in the bootstrap loader:
>
> {
>  val boot = ...//Lookup and create Boot instance
>  val lc = LiftConfig() //(1)
>  boot.boot(lc) //(2)
>  LiftRules.init(lc) //(3)
>
> }
>
> (1) : Must create LiftConfig (this object is the placeholder of the
> configuration=
> (2) : Pass it into the boot-call
> (3) : Initialize LiftRules with the configuration prepared by the boot-call
>
> result:
>
> No need to expose mutability in LiftRules (since we discovered that changing
> stuff while the webserver was up and running had few applications at best)
>
> More clear now?
>
> Remeber that this is only a friendly suggestion to an issue brought up by
> someone else in this thread.
> If such suggestions are superflous, please just tell me so and I'll keep my
> trap shut.
>
> Cheers,
> Viktor
>
>
>
>
>
> >> Input?
>
> >> Cheers,
> >> Viktor
>
> >> On Sun, Dec 14, 2008 at 3:41 PM, David Pollak <
> >> feeder.of.the.be...@gmail.com> wrote:
>
> >>> Folks,
>
> >>> I have not had a single instance of wanting to change global application
> >>> behavior at runtime.  I cannot think of use case for such a feature.
>
> >>> On the other hand, the idea that your program behavior is stable from the
> >>> first HTTP request on makes a lot of sense to me.  It means tests work
> >>> because the tests don't have to worry about the behavior of the program
> >>> changing.  The same n steps will lead to the same result.
>
> >>> If anyone can come up with a use case for globally changing program
> >>> behavior during program execution, I'm all ears, but barring that, once 
> >>> the
> >>> boot phase is over, the stuff in LiftRules should be frozen.
>
> >>> Thanks,
>
> >>> David
>
> >>> On Sun, Dec 14, 2008 at 3:54 AM, Marius  wrote:
>
>  On Dec 14, 12:53 pm, "Viktor Klang"  wrote:
>  > On Sun, Dec 14, 2008 at 11:42 AM, Marius 
>  wrote:
>
>  > > On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
>  > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius 
>  wrote:
>
>  > > > > On Dec 14, 3:02 am, "Jorge Ortiz" 
>  wrote:
>  > > > > > Not to beat a dead horse, but... what's the rationale, again,
>  for
>  > > > > throwing
>  > > > > > an exception after boot? Is there a real danger to some or all
>  > > RulesSeqs
>  > > > > > being mutable after boot? If some, then those rules should
>  > > selectively be
>  > > > > > protected. Even if they're all dangerous, there are better
>  (i.e.,
>  > > type
>  > > > > safe)
>  > > > > > ways of protecting RulesSeqs from mutation than just throwing
>  an
>  > > > > exception.
>
>  > > > > This was actually DPP's suggestion. I'm not sure why would
>  someone
>  > > > > mutate them after boot but I'm totally opened if there is a
>  strong
>  > > > > case for allowing that. I do not have strong feelings about this
>  so
>  > > > > changing it would be trivial. Still I kind of like it this way.
>  What
>  > > > > other ways of protecting mutations after boot are you referring?
>  ...
>  > > > > something like ignore it and do nothing?
>
>  > > > Hmm, how about "locking" them by havign a paralell lazy val?
>
>  > > > val somePf : RuleSeq = Nil;
>
>  > > > lazy val runtimeSomePf = somePf.toList
>
>  > > > Th

[Lift] Re: ToDo Tutorial - Layout for added column

[Stefan Scott]

Thanks David - I'm not an HTML guy myself either - I've avoided web
apps for years because my mind turns to mush when confronted with
"dynamic typing" - I *love* Scala's type system and what you're doing
with it...

Anyways I was just going to post that I did take a stab at the same
solution you offered - and it worked!



In file ~\webapps\todo\src\main\webapp\index.html I simply changed
tags:

 ... 
-->
 ... 

 ... 
-->
 ... 

 ...  
-->
  ...   


in:


  

  Location
  
  
1
  
  To Do

  



yielding:


  

  
Location
  
  

  
  

  1

  
  To Do

  


It looks like /lift/ really does keep the markup separate from the
logic (ie the curried Ajax methods to edit, validate and format
individual fields) - if a relative HTML novice like me from the object-
oriented / functional world (the language I'm most comfortable with is
Maude) could get it right on the first guess!

- Stefan Scott


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Okay... Hudson is building again

[David Pollak]

Folks,
Hudson is building again.  All the breaking changes that were made in the
last week are going to hit you next time you do an mvn -U clean install.

Thanks,

David

-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.

[Josh Suereth]

Is your firewall blocking java?  This would cause maven to be unable  
to download dependencies.

Sent from my iPhone

On Dec 14, 2008, at 1:13 PM, mike beckerle  wrote:

>
> I can browse to the location just fine. There is no proxy or other
> wierdness between me and the internet. Just the usual home firewall
> (NAT) device.
>
> On Dec 13, 1:45 pm, "David Pollak" 
> wrote:
>> On Sat, Dec 13, 2008 at 10:34 AM, mike beckerle  
>>  wrote:
>>
>>> This did not work. Still failed.
>>
>>> There are disturbing messages in here about blacklisting sites due  
>>> to
>>> errors and such.
>>
>>> becke...@ubuntu810desktop:~/todo$ mvn jetty:run -U
>>> [INFO] Scanning for projects...
>>> [INFO] Searching repository for plugin with prefix: 'jetty'.
>>> [INFO] org.apache.maven.plugins: checking for updates from scala-
>>> tools.org
>>> [WARNING] repository metadata for: 'org.apache.maven.plugins' could
>>> not be retrieved from repository: scala-tools.org due to an error:
>>> Error transferring file
>>> [INFO] Repository 'scala-tools.org' will be blacklisted
>>
>> This is the problem.  For some reason, you're not able to connect to
>> scala-tools.org.
>>
>> Are you behind an HTTP proxy?
>>
>> Does the proxy have whitelist/blacklist of sites and/or IP addresses?
>>
>> Can you browse tohttp://scala-tools.org/repo-snapshots/net/liftweb/  
>> with
>> your web browser?
>>
>>
>>
>>
>>
>>> [INFO] org.apache.maven.plugins: checking for updates from central
>>> [INFO] org.codehaus.mojo: checking for updates from central
>>> [INFO] artifact org.scala-tools:maven-scala-plugin: checking for
>>> updates from central
>>> [INFO]
>>> --- 
>>> --- 
>>> --
>>> [ERROR] BUILD ERROR
>>> [INFO]
>>> --- 
>>> --- 
>>> --
>>> [INFO] The plugin 'org.scala-tools:maven-scala-plugin' does not  
>>> exist
>>> or no valid version could be found
>>> [INFO]
>>> --- 
>>> --- 
>>> --
>>> [INFO] For more information, run Maven with the -e switch
>>> [INFO]
>>> --- 
>>> --- 
>>> --
>>> [INFO] Total time: 26 seconds
>>> [INFO] Finished at: Sat Dec 13 13:29:24 EST 2008
>>> [INFO] Final Memory: 1M/4M
>>> [INFO]
>>> --- 
>>> --- 
>>> --
>>> mbecke...@ubuntu810desktop:~/todo$
>>
>>> On Dec 11, 7:57 am, "David Bernard" 
>>> wrote:
 The first time you run jetty :
>>
 mvn jetty:run -U
>>
 I learn a way to avoid this problem (for futur archetype, I'll  
 try it
 next week-end)
>>
 /davidB
>>
 On Thu, Dec 11, 2008 at 13:31, Josh Suereth  
 
>>> wrote:
> Thanks, and sorry for the typos.
>>
> What you want (in either your ~/.m2/settings.xml or
>>> ${project.dir}/pom.xml)
> is the following:
>>
> 
> 
>   scala-tools.org
>>
>   Scala-tools Maven2 Repository
>   http://scala-tools.org/repo-releases
> 
> 
>>
>   snapshots.scala-tools.org
>   Scala-tools Maven2 Snapshot Repository
>   http://scala-tools.org/repo-snapshots
>>
> 
>   
>>
> On Thu, Dec 11, 2008 at 7:24 AM, Tim Perrett  
> 
>>> wrote:
>>
>> I think Josh meant to say "defined in your pom.xml"
>>
>> On Dec 11, 12:14 pm, Josh Suereth   
>> wrote:
>>> Make sure the scala-tools snapshot repository is defined in  
>>> your ppm
>>
>> --
>> Lift, the simply functional web frameworkhttp://liftweb.net
>> Collaborative Task Managementhttp://much4.us
>> Follow me:http://twitter.com/dpp
>> Git some:http://github.com/dpp
>
> >

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: maven problem - can't make ToDo example work - or even get off the ground.

[mike beckerle]

I can browse to the location just fine. There is no proxy or other
wierdness between me and the internet. Just the usual home firewall
(NAT) device.

On Dec 13, 1:45 pm, "David Pollak" 
wrote:
> On Sat, Dec 13, 2008 at 10:34 AM, mike beckerle  wrote:
>
> > This did not work. Still failed.
>
> > There are disturbing messages in here about blacklisting sites due to
> > errors and such.
>
> > becke...@ubuntu810desktop:~/todo$ mvn jetty:run -U
> > [INFO] Scanning for projects...
> > [INFO] Searching repository for plugin with prefix: 'jetty'.
> > [INFO] org.apache.maven.plugins: checking for updates from scala-
> > tools.org
> > [WARNING] repository metadata for: 'org.apache.maven.plugins' could
> > not be retrieved from repository: scala-tools.org due to an error:
> > Error transferring file
> > [INFO] Repository 'scala-tools.org' will be blacklisted
>
> This is the problem.  For some reason, you're not able to connect to
> scala-tools.org.
>
> Are you behind an HTTP proxy?
>
> Does the proxy have whitelist/blacklist of sites and/or IP addresses?
>
> Can you browse tohttp://scala-tools.org/repo-snapshots/net/liftweb/ with
> your web browser?
>
>
>
>
>
> > [INFO] org.apache.maven.plugins: checking for updates from central
> > [INFO] org.codehaus.mojo: checking for updates from central
> > [INFO] artifact org.scala-tools:maven-scala-plugin: checking for
> > updates from central
> > [INFO]
> > 
> > [ERROR] BUILD ERROR
> > [INFO]
> > 
> > [INFO] The plugin 'org.scala-tools:maven-scala-plugin' does not exist
> > or no valid version could be found
> > [INFO]
> > 
> > [INFO] For more information, run Maven with the -e switch
> > [INFO]
> > 
> > [INFO] Total time: 26 seconds
> > [INFO] Finished at: Sat Dec 13 13:29:24 EST 2008
> > [INFO] Final Memory: 1M/4M
> > [INFO]
> > 
> > mbecke...@ubuntu810desktop:~/todo$
>
> > On Dec 11, 7:57 am, "David Bernard" 
> > wrote:
> > > The first time you run jetty :
>
> > > mvn jetty:run -U
>
> > > I learn a way to avoid this problem (for futur archetype, I'll try it
> > > next week-end)
>
> > > /davidB
>
> > > On Thu, Dec 11, 2008 at 13:31, Josh Suereth 
> > wrote:
> > > > Thanks, and sorry for the typos.
>
> > > > What you want (in either your ~/.m2/settings.xml or
> > ${project.dir}/pom.xml)
> > > > is the following:
>
> > > > 
> > > >     
> > > >       scala-tools.org
>
> > > >       Scala-tools Maven2 Repository
> > > >       http://scala-tools.org/repo-releases
> > > >     
> > > >     
>
> > > >       snapshots.scala-tools.org
> > > >       Scala-tools Maven2 Snapshot Repository
> > > >       http://scala-tools.org/repo-snapshots
>
> > > >     
> > > >   
>
> > > > On Thu, Dec 11, 2008 at 7:24 AM, Tim Perrett 
> > wrote:
>
> > > >> I think Josh meant to say "defined in your pom.xml"
>
> > > >> On Dec 11, 12:14 pm, Josh Suereth  wrote:
> > > >> > Make sure the scala-tools snapshot repository is defined in your ppm
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Collaborative Task Managementhttp://much4.us
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Viktor Klang]

On Sun, Dec 14, 2008 at 4:01 PM, David Pollak  wrote:

>
>
> On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang wrote:
>
>> David,
>>
>> sounds reasonable.
>>
>> So being able to call prepend/append after boot() makes no sense.
>>
>> In the light of htis, it shouldn't be possible to call the prepend/append
>> outside of boot.
>> I suggest my approach described previously. (Injecting an initialization
>> context into boot and use that to configure LiftRules, then we don't expose
>> the mutativity in LiftRules.
>> Result: No runtime exceptions, no confusion on when to configure the
>> webapp etc.
>
>
> I have no idea what this means or how to translate it into code.  Can you
> give me an example of code that "injects an initialization context into
> boot"?
>
>

class Boot
{
   def boot(val lc: LiftConfig) =
   {
  add all configuration to LiftConfig
   }
}

and then in the code that lookups, creates and calls Boot.boot (haven't got
access to the repository on this machine)

just add/modify the code in the bootstrap loader:

{
 val boot = ...//Lookup and create Boot instance
 val lc = LiftConfig() //(1)
 boot.boot(lc) //(2)
 LiftRules.init(lc) //(3)
}

(1) : Must create LiftConfig (this object is the placeholder of the
configuration=
(2) : Pass it into the boot-call
(3) : Initialize LiftRules with the configuration prepared by the boot-call

result:

No need to expose mutability in LiftRules (since we discovered that changing
stuff while the webserver was up and running had few applications at best)

More clear now?

Remeber that this is only a friendly suggestion to an issue brought up by
someone else in this thread.
If such suggestions are superflous, please just tell me so and I'll keep my
trap shut.


Cheers,
Viktor




>
>>
>> Input?
>>
>> Cheers,
>> Viktor
>>
>> On Sun, Dec 14, 2008 at 3:41 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>> Folks,
>>>
>>> I have not had a single instance of wanting to change global application
>>> behavior at runtime.  I cannot think of use case for such a feature.
>>>
>>> On the other hand, the idea that your program behavior is stable from the
>>> first HTTP request on makes a lot of sense to me.  It means tests work
>>> because the tests don't have to worry about the behavior of the program
>>> changing.  The same n steps will lead to the same result.
>>>
>>> If anyone can come up with a use case for globally changing program
>>> behavior during program execution, I'm all ears, but barring that, once the
>>> boot phase is over, the stuff in LiftRules should be frozen.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>>
>>>
>>> On Sun, Dec 14, 2008 at 3:54 AM, Marius  wrote:
>>>



 On Dec 14, 12:53 pm, "Viktor Klang"  wrote:
 > On Sun, Dec 14, 2008 at 11:42 AM, Marius 
 wrote:
 >
 > > On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
 > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius 
 wrote:
 >
 > > > > On Dec 14, 3:02 am, "Jorge Ortiz" 
 wrote:
 > > > > > Not to beat a dead horse, but... what's the rationale, again,
 for
 > > > > throwing
 > > > > > an exception after boot? Is there a real danger to some or all
 > > RulesSeqs
 > > > > > being mutable after boot? If some, then those rules should
 > > selectively be
 > > > > > protected. Even if they're all dangerous, there are better
 (i.e.,
 > > type
 > > > > safe)
 > > > > > ways of protecting RulesSeqs from mutation than just throwing
 an
 > > > > exception.
 >
 > > > > This was actually DPP's suggestion. I'm not sure why would
 someone
 > > > > mutate them after boot but I'm totally opened if there is a
 strong
 > > > > case for allowing that. I do not have strong feelings about this
 so
 > > > > changing it would be trivial. Still I kind of like it this way.
 What
 > > > > other ways of protecting mutations after boot are you referring?
 ...
 > > > > something like ignore it and do nothing?
 >
 > > > Hmm, how about "locking" them by havign a paralell lazy val?
 >
 > > > val somePf : RuleSeq = Nil;
 >
 > > > lazy val runtimeSomePf = somePf.toList
 >
 > > > Then prepending/appending on the somePf AFTER runtimeSomePf has
 been
 > > > dereferenced won't make a difference.
 > > > (runtimeSomePf would be used by Lift internally if that isn't
 clear
 > > enough
 > > > :) )
 >
 > > Still we'd allow useless strong references on those lists.
 >
 > > > Or another, perhaps more suitable suggestion:
 >
 > > > make boot() have an InitializationContext parameter that's only
 available
 > > in
 > > > the scope of boot, and then the problem should disappear?
 >
 > > How would the problem disappear? ... I mean after boot people would
 > > still be able to add their functions (from API perspective) and they
 > > would be surprised that their functions are not called and yet l

[Lift] Re: Hooking into /user_mgt

[Erick Fleming]

I agree with david, in fact protouser contains several things I don't
need (not a public website) and it's pretty easy to make your own.

On 12/14/08, David Pollak  wrote:
> ProtoUser is designed to allow people to get a project up and running
> quickly.
>
> In all my moderately complex projects, I've subclassed so many fields in
> ProtoUser/MegaProtoUser that I might as well have copied and pasted the code
> from ProtoUser into my application.
>
> If you want to do things that go beyond the facilities in ProtoUser, I'd
> strongly suggest just copy/pasting the code from ProtoUser into your
> User.scala code and do whatever you need to do in your own code.
>
> Thanks,
>
> David
>
> On Sat, Dec 13, 2008 at 11:26 PM, Juha L  wrote:
>
>>
>> There already seems to be hooks for login & logout (onLogIn/onLogOut)
>> in the MetaMegaProtoUser. Would it be possible to also add onSignUp
>> which would be called when user has been successfully created &
>> validated? That would make it trivial to do basic initializations for
>> the new users.
>>
>> // Juha
>>
>> On Dec 14, 6:18 am, "Derek Chen-Becker"  wrote:
>> > /user_mgt is handled via MetaMegaProtoUser. You may be able to override
>> some
>> > things there.
>> >
>> > Derek
>> >
>> > On Sat, Dec 13, 2008 at 2:03 PM, Juha L  wrote:
>> >
>> > > Hi again,
>> >
>> > > I have need to hook some extra code into user sign up, login, and
>> > > logout. In archetype-basic project all things related to user
>> > > management seem to happen in magical "/user_mgt", and I couldn't
>> > > really find any good information about how I could alter what happens
>> > > there. Could anyone provide me pointers or examples?
>> >
>> > > // Juha
>>
>> >
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

-- 
Sent from my mobile device

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[David Pollak]

On Sun, Dec 14, 2008 at 6:51 AM, Viktor Klang wrote:

> David,
>
> sounds reasonable.
>
> So being able to call prepend/append after boot() makes no sense.
>
> In the light of htis, it shouldn't be possible to call the prepend/append
> outside of boot.
> I suggest my approach described previously. (Injecting an initialization
> context into boot and use that to configure LiftRules, then we don't expose
> the mutativity in LiftRules.
> Result: No runtime exceptions, no confusion on when to configure the webapp
> etc.


I have no idea what this means or how to translate it into code.  Can you
give me an example of code that "injects an initialization context into
boot"?


>
>
> Input?
>
> Cheers,
> Viktor
>
> On Sun, Dec 14, 2008 at 3:41 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
>
>> Folks,
>>
>> I have not had a single instance of wanting to change global application
>> behavior at runtime.  I cannot think of use case for such a feature.
>>
>> On the other hand, the idea that your program behavior is stable from the
>> first HTTP request on makes a lot of sense to me.  It means tests work
>> because the tests don't have to worry about the behavior of the program
>> changing.  The same n steps will lead to the same result.
>>
>> If anyone can come up with a use case for globally changing program
>> behavior during program execution, I'm all ears, but barring that, once the
>> boot phase is over, the stuff in LiftRules should be frozen.
>>
>> Thanks,
>>
>> David
>>
>>
>>
>> On Sun, Dec 14, 2008 at 3:54 AM, Marius  wrote:
>>
>>>
>>>
>>>
>>> On Dec 14, 12:53 pm, "Viktor Klang"  wrote:
>>> > On Sun, Dec 14, 2008 at 11:42 AM, Marius 
>>> wrote:
>>> >
>>> > > On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
>>> > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius 
>>> wrote:
>>> >
>>> > > > > On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
>>> > > > > > Not to beat a dead horse, but... what's the rationale, again,
>>> for
>>> > > > > throwing
>>> > > > > > an exception after boot? Is there a real danger to some or all
>>> > > RulesSeqs
>>> > > > > > being mutable after boot? If some, then those rules should
>>> > > selectively be
>>> > > > > > protected. Even if they're all dangerous, there are better
>>> (i.e.,
>>> > > type
>>> > > > > safe)
>>> > > > > > ways of protecting RulesSeqs from mutation than just throwing
>>> an
>>> > > > > exception.
>>> >
>>> > > > > This was actually DPP's suggestion. I'm not sure why would
>>> someone
>>> > > > > mutate them after boot but I'm totally opened if there is a
>>> strong
>>> > > > > case for allowing that. I do not have strong feelings about this
>>> so
>>> > > > > changing it would be trivial. Still I kind of like it this way.
>>> What
>>> > > > > other ways of protecting mutations after boot are you referring?
>>> ...
>>> > > > > something like ignore it and do nothing?
>>> >
>>> > > > Hmm, how about "locking" them by havign a paralell lazy val?
>>> >
>>> > > > val somePf : RuleSeq = Nil;
>>> >
>>> > > > lazy val runtimeSomePf = somePf.toList
>>> >
>>> > > > Then prepending/appending on the somePf AFTER runtimeSomePf has
>>> been
>>> > > > dereferenced won't make a difference.
>>> > > > (runtimeSomePf would be used by Lift internally if that isn't clear
>>> > > enough
>>> > > > :) )
>>> >
>>> > > Still we'd allow useless strong references on those lists.
>>> >
>>> > > > Or another, perhaps more suitable suggestion:
>>> >
>>> > > > make boot() have an InitializationContext parameter that's only
>>> available
>>> > > in
>>> > > > the scope of boot, and then the problem should disappear?
>>> >
>>> > > How would the problem disappear? ... I mean after boot people would
>>> > > still be able to add their functions (from API perspective) and they
>>> > > would be surprised that their functions are not called and yet lift
>>> > > just allowed them to do that.
>>> >
>>> > I meant something like:
>>> >
>>> > def boot(val lc : LiftContext) =
>>> > {
>>> >  //prepend/append,configure everything on lc
>>> >
>>> > }
>>> >
>>> > And then when the LiftFilter runt boot:
>>> >
>>> > {
>>> >val lc = LiftContext(/*servletContext and stuff goes here*/)
>>> >boot(lc)
>>> >LiftRules.init(lc)
>>> >
>>> > }
>>> >
>>> > And then only have non-append/prependable stuff in LiftRules?
>>> >
>>> > But really, what is it a problem that lift is reconfigurable during
>>> runtime?
>>> > I thought that was kind of cool?
>>>
>>> As I said I don't have strong opinions on this. It was DPP's
>>> suggestion and personally I kind of like it which does not mean that
>>> things can not change :) ... AFAIC reconfiguration at runtime does not
>>> make a whole lot of sense because:
>>>
>>> 1. We'd have to expose other functions to allow people to also remove
>>> their function not only prepend & append them
>>> 2. I do not see what kinds of problems runtime reconfiguration really
>>> solve (I'm only referring on the current RulesSeq members). I haven't
>>> encounter a practical need but if you have

[Lift] Re: Hooking into /user_mgt

[David Pollak]

ProtoUser is designed to allow people to get a project up and running
quickly.

In all my moderately complex projects, I've subclassed so many fields in
ProtoUser/MegaProtoUser that I might as well have copied and pasted the code
from ProtoUser into my application.

If you want to do things that go beyond the facilities in ProtoUser, I'd
strongly suggest just copy/pasting the code from ProtoUser into your
User.scala code and do whatever you need to do in your own code.

Thanks,

David

On Sat, Dec 13, 2008 at 11:26 PM, Juha L  wrote:

>
> There already seems to be hooks for login & logout (onLogIn/onLogOut)
> in the MetaMegaProtoUser. Would it be possible to also add onSignUp
> which would be called when user has been successfully created &
> validated? That would make it trivial to do basic initializations for
> the new users.
>
> // Juha
>
> On Dec 14, 6:18 am, "Derek Chen-Becker"  wrote:
> > /user_mgt is handled via MetaMegaProtoUser. You may be able to override
> some
> > things there.
> >
> > Derek
> >
> > On Sat, Dec 13, 2008 at 2:03 PM, Juha L  wrote:
> >
> > > Hi again,
> >
> > > I have need to hook some extra code into user sign up, login, and
> > > logout. In archetype-basic project all things related to user
> > > management seem to happen in magical "/user_mgt", and I couldn't
> > > really find any good information about how I could alter what happens
> > > there. Could anyone provide me pointers or examples?
> >
> > > // Juha
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: XML problems in ToDo tutorial?

[David Pollak]

For some reason, the index.html file is not valid XML.

What development tool/environment are you using?  What character encoding
are you using (UTF-8 is the preferred encoding)?

Please attach the failing file to your response so that I can see the exact
problem.

On Sat, Dec 13, 2008 at 10:25 PM, Stefan Scott
wrote:

>
> Hi -
>
> On page 14 of the ToDo tutorial here:
>
>
> http://groups.google.com/group/liftweb/browse_thread/thread/0d99974c622262d5#
>
> after I edit the file 'src/main/webapp/index.html' so that it now
> reads:
>
> 
> Please
> Log In
> 
> 
>
> and I stop jetty (Ctl-C) and then recompile/restart with 'mvn
> jetty:run'...
>
> I get the following error in the browser on the first screen:
>
> 
> XML Parsing Error: syntax error
> Location: http://localhost:8080/
> Line Number 4, Column 1:Please
> 
>
>
> If I remove the word "Please" from that file, I get a different error:
>
> 
> This XML file does not appear to have any style information associated
> with it.
> The document tree is shown below.
>
> Please Log In
> 
>
>
> If I replace my '~\jetty\webapps\todo' directory with the *completed*
> todo.tgz archive supplied with the tutorial (thereby skipping ahead a
> few steps in the tutorial) and recompile/restart, it works fine. But
> if I create these steps myself, I keep getting these XML errors.
>
> Any suggestions? Am I missing a file somewhere?
>
> Thanks!
>
> - Stefan Scott
>
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Comment on net.liftweb.sitemap.Loc.Title

[Derek Chen-Becker]

I'm doing our SiteMap chapter right now and it strikes me as a little odd
that the default Title for a Loc is the name of the Loc instead of the Loc
text. That means that if I do something like:

def userMenuText = User.name + "'s profile"
val userMenu = Menu(Loc("usermenu", "user" :: "profile" :: Nil,
userMenuText))

then the default title of the page is going to be "usermenu", if I'm reading
the code correctly. It just seems redundant to have to provide a custom
Title as well as custom Link text, even if technically they could use the
same underlying code for text calculation.

Cheers,

Derek

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Viktor Klang]

David,

sounds reasonable.

So being able to call prepend/append after boot() makes no sense.

In the light of htis, it shouldn't be possible to call the prepend/append
outside of boot.
I suggest my approach described previously. (Injecting an initialization
context into boot and use that to configure LiftRules, then we don't expose
the mutativity in LiftRules.
Result: No runtime exceptions, no confusion on when to configure the webapp
etc.

Input?

Cheers,
Viktor

On Sun, Dec 14, 2008 at 3:41 PM, David Pollak  wrote:

> Folks,
>
> I have not had a single instance of wanting to change global application
> behavior at runtime.  I cannot think of use case for such a feature.
>
> On the other hand, the idea that your program behavior is stable from the
> first HTTP request on makes a lot of sense to me.  It means tests work
> because the tests don't have to worry about the behavior of the program
> changing.  The same n steps will lead to the same result.
>
> If anyone can come up with a use case for globally changing program
> behavior during program execution, I'm all ears, but barring that, once the
> boot phase is over, the stuff in LiftRules should be frozen.
>
> Thanks,
>
> David
>
>
>
> On Sun, Dec 14, 2008 at 3:54 AM, Marius  wrote:
>
>>
>>
>>
>> On Dec 14, 12:53 pm, "Viktor Klang"  wrote:
>> > On Sun, Dec 14, 2008 at 11:42 AM, Marius 
>> wrote:
>> >
>> > > On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
>> > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius 
>> wrote:
>> >
>> > > > > On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
>> > > > > > Not to beat a dead horse, but... what's the rationale, again,
>> for
>> > > > > throwing
>> > > > > > an exception after boot? Is there a real danger to some or all
>> > > RulesSeqs
>> > > > > > being mutable after boot? If some, then those rules should
>> > > selectively be
>> > > > > > protected. Even if they're all dangerous, there are better
>> (i.e.,
>> > > type
>> > > > > safe)
>> > > > > > ways of protecting RulesSeqs from mutation than just throwing an
>> > > > > exception.
>> >
>> > > > > This was actually DPP's suggestion. I'm not sure why would someone
>> > > > > mutate them after boot but I'm totally opened if there is a strong
>> > > > > case for allowing that. I do not have strong feelings about this
>> so
>> > > > > changing it would be trivial. Still I kind of like it this way.
>> What
>> > > > > other ways of protecting mutations after boot are you referring?
>> ...
>> > > > > something like ignore it and do nothing?
>> >
>> > > > Hmm, how about "locking" them by havign a paralell lazy val?
>> >
>> > > > val somePf : RuleSeq = Nil;
>> >
>> > > > lazy val runtimeSomePf = somePf.toList
>> >
>> > > > Then prepending/appending on the somePf AFTER runtimeSomePf has been
>> > > > dereferenced won't make a difference.
>> > > > (runtimeSomePf would be used by Lift internally if that isn't clear
>> > > enough
>> > > > :) )
>> >
>> > > Still we'd allow useless strong references on those lists.
>> >
>> > > > Or another, perhaps more suitable suggestion:
>> >
>> > > > make boot() have an InitializationContext parameter that's only
>> available
>> > > in
>> > > > the scope of boot, and then the problem should disappear?
>> >
>> > > How would the problem disappear? ... I mean after boot people would
>> > > still be able to add their functions (from API perspective) and they
>> > > would be surprised that their functions are not called and yet lift
>> > > just allowed them to do that.
>> >
>> > I meant something like:
>> >
>> > def boot(val lc : LiftContext) =
>> > {
>> >  //prepend/append,configure everything on lc
>> >
>> > }
>> >
>> > And then when the LiftFilter runt boot:
>> >
>> > {
>> >val lc = LiftContext(/*servletContext and stuff goes here*/)
>> >boot(lc)
>> >LiftRules.init(lc)
>> >
>> > }
>> >
>> > And then only have non-append/prependable stuff in LiftRules?
>> >
>> > But really, what is it a problem that lift is reconfigurable during
>> runtime?
>> > I thought that was kind of cool?
>>
>> As I said I don't have strong opinions on this. It was DPP's
>> suggestion and personally I kind of like it which does not mean that
>> things can not change :) ... AFAIC reconfiguration at runtime does not
>> make a whole lot of sense because:
>>
>> 1. We'd have to expose other functions to allow people to also remove
>> their function not only prepend & append them
>> 2. I do not see what kinds of problems runtime reconfiguration really
>> solve (I'm only referring on the current RulesSeq members). I haven't
>> encounter a practical need but if you have please let me know.
>> 3. Dynamic behavior can happen inside user's functions without
>> allowing runtime reconfiguration.
>>
>> Just my 2 cents ...
>>
>> P.S.
>> If the general consensus is to remove this restriction I have no
>> problem removing it ... so more thoughts/perspectives on this are
>> welcomed.
>>
>>
>>
>> >
>> > Cheers,
>> > Viktor
>> >
>> >
>> >
>> >
>> >
>> > > > Cheers,
>> > > > Viktor
>> >
>>

[Lift] Re: ToDo Tutorial - Layout for added column

[David Pollak]

On Sat, Dec 13, 2008 at 10:05 PM, Stefan Scott
wrote:

>
> Hi -
>
> I'm about halfway through the new ToDo Tutorial available here:
>
>
> http://groups.google.com/group/liftweb/browse_thread/thread/0d99974c622262d5#
>
> and I wanted to try adding a new column "loc" ("Location").
>
> (NOTE: As pointed out in another threads here today, you have to do
> 'cd todo' before doing 'mvn jetty:run' on page 6 of the tutorial.)
>
> I added my new column "loc" ("Location") to the model, and it displays
> on the screen (in the list of existing ToDo's, and below in the form
> for adding a new ToDo), but I can't control the formatting - my
> columns aren't straight.


The example code formats using ...  If you want columns to
line up, you'll want to use a  thus:

 
   
 Location
 
 
   1

>  
>  To Do
>
>  
>


becomes:












There may be other ways to lay things out.  I'm not an HTML guy... but the
key take-away is that in the snippet code, you only worry about bind-points
and not the html.  You can change the view up any way you like.

Thanks,

David



>
> (They just happened to be straight in the *basic* tutorial because the
> "desc" or "Description" happens to be the last column, and all the
> preceding columns are either Boolean or drop-down menu, which are
> fixed width.)
>
> Anybody have an example of this? Between the currying and the Ajax, I
> can't quite wrap my mind around how the html is being generated.
>
> Thanks. I'm very exciteds about Scala and /lift/ !
>
> - Stefan Scott
>
>
> Here are the 3 files I've updated:
>
>
> C:\www\jetty\webapps\todo\src\main\webapp\ToDo.scala
>
> 
>  
>
>  
>Exclude done 
>
>  
>
>  Location
>  
>  
>1
>  
>  To Do
>
>  
>
>  
>
>
>
>
>  
>
>  Location:
>  Location
>
>
>  Description:
>  To Do
>
>
>  
>Priority
>  
>  
>
>  1
>
>  
>
>
>   
>  
>
>  New
>
>  
>
>  
>
>  
>
>
>  Please
>Log In
>  
> 
>
> ==
>
> C:\www\jetty\webapps\todo\src\main\scala\com\liftworkshop\model
> \ToDo.scala
>
> package com.liftworkshop.model
>
> import net.liftweb._
> import mapper._
> import http._
> import SHtml._
> import util._
>
> class ToDo extends LongKeyedMapper[ToDo] with IdPK {
>  def getSingleton = ToDo
>
>  object done extends MappedBoolean(this)
>
>  object owner extends MappedLongForeignKey(this, User)
>
>  object priority extends MappedInt(this) {
>override def defaultValue = 5
>override def validations = validPriority _ :: super.validations
>def validPriority(in: Int): List[FieldError] =
>if (in > 0 && in <= 10) Nil
>else List(FieldError(this, Priority must be 1-10))
>override def _toForm = Full(select(ToDo.priorityList,
>   Full(is.toString),
>   f => set(f.toInt)))
>  }
>
>  object desc extends MappedPoliteString(this, 128) {
>override def validations =
>valMinLen(3, "Description must be 3 characters") _ ::
>super.validations
>  }
>
>  object loc extends MappedPoliteString(this, 63) {
>override def validations =
>valMinLen(3, "Location must be 3 characters") _ ::
>super.validations
>  }
> }
>
> object ToDo extends ToDo with LongKeyedMetaMapper[ToDo] {
>  lazy val priorityList = (1 to 10).
>  map(v => (v.toString, v.toString))
> }
>
> ==
>
> C:\www\jetty\webapps\todo\src\main\scala\com\liftworkshop\snippet
> \TD.scala
>
> package com.liftworkshop.snippet
> import com.liftworkshop._
> import model._
> import net.liftweb._
> import http._
> import SHtml._
> import S._
> import js._
> import JsCmds._
> import mapper._
> import util._
> import Helpers._
> import scala.xml.{NodeSeq, Text}
>
> class TD {
>  def add(form: NodeSeq) = {
>val todo = ToDo.create.owner(User.currentUser)
>def checkAndSave(): Unit =
>todo.validate match {
>  case Nil => todo.save ; S.notice("Added "+todo.desc)
>  case xs => S.error(xs) ; S.mapSnippet("TD.add", doBind)
>}
>def doBind(form: NodeSeq) =
>bind("todo", form,
> "priority" -> todo.priority.toForm,
> "desc" -> todo.desc.toForm,
> "loc" -> todo.loc.toForm,
> "submit" -> submit("New", checkAndSave))
>doBind(form)
>  }
>
>  private def toShow =
>  ToDo.findAll(By(ToDo.owner, User.currentUser),
>   if (QueryNotDone) By(ToDo.done, false)
>   else Ignore[ToDo],
>   OrderBy(ToDo.done, Ascending),
>

[Lift] Re: More JPA goodness

[Derek Chen-Becker]

It doesn't; that's not the point of this module. Record will have its own
semantics for accessing data, and I think we'll have a backend that hooks
into JPA if desired, but the point of the code I'm posting now is for people
who want to use JPA directly.

Derek

On Sat, Dec 13, 2008 at 6:49 PM, philip  wrote:

>
> How does it relate to the new "record" way of accessing database?
>
> On Dec 14, 6:19 am, "Derek Chen-Becker"  wrote:
> > OK, party people. I've broken out behaviors into a number of traits.
> Since
> > I'm coming at this from Lift, I've also added a nice trait to make using
> JPA
> > from Lift nice and simple. For now I'll host the scaladocs up on my own
> > website:
> >
> > http://chen-becker.org/scalajpa/scaladocs/index.html
> >
> > The code is available on git:
> >
> > http://github.com/dchenbecker/scalajpa/tree/master
> >
> > Just to give you a sample of what this can do, here's how we define a
> Local
> > JPA module:
> >
> > object Model extends LocalEM("mypersistenceunit") with RequestVarEM
> >
> > Ta da! That's it; oyu no longer have to code up the request var stuff, or
> > even transaction handling (it's optional on the LocalEM trait, but JNDI
> > generally requires JTA). If you want JNDI instead:
> >
> > object Model extends JndiEM("java:/MyUnitEM") with RequestVarEM
> >
> > If you'd rather manage the EMs yourself, just drop the RequestVarEM:
> >
> > object Model extends LocalEM("foo")
> >
> > and in your code:
> >
> > val em = Model.newEM
> > em.findAll(...)
> > em.close()
> >
> > The RequestVarEM (and ThreadLocalEM, for use outside of Lift) can be used
> to
> > make your object a singleton ScalaEntityManager, so the EM methods are
> > called directly on your object:
> >
> > Model.createNamedQuery(...)
> > Model.lock(...)
> >
> > I think that with this design we get maximum flexibility by using the
> traits
> > to control independent behaviors, but as always I'm open to suggestions.
> One
> > thing I've been vacillating on is naming things like RequestVarEM
> > RequestVarSingleton to explicitly show that it makes the object a
> singleton
> > EM, but I don't know that it makes a huge difference either way.
> >
> > Cheers,
> >
> > Derek
> >
> > PS - I'll discuss getting this up on scala-tools.org with David B. so
> that
> > it's in the repos soon.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: todo_steps feedback

[David Pollak]

Thanks!  I'll make the change.

On Sat, Dec 13, 2008 at 7:44 PM, mal3  wrote:

>
> David,
>
> I'm not sure where to send feedback on the todo_steps book. I'm
> working my way through the todo
> project, and I my feedback may be at times very minor in the interests
> of doing my bit to help with
> the final book product.
>
> There was a warning with the first mvn command:
>
> [INFO] [archetype:create]
> [WARNING] This goals is deprecated. Please use mvn archetype:generate
> instead
>
> mvn archetype:generate seemed to work just as well. If there's no
> reason to use create rather than generate,
> maybe change it to generate in the book.
>
> Mal.
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Crashing CometActor

[David Pollak]

On Sat, Dec 13, 2008 at 4:48 PM, Michael  wrote:

>
> Looks like Hudson was up again, so I pulled in the latest snapshot
> from scala-tools and added the log level statement.


Hudson's not back.  Lift has not been built in a week.  I've got an
emergency message out to DavidB to look into it, but we're still running on
an old version of Lift. :-(


> It didn't seem to
> matter much though:
>
> INFO - Service request (GET) / took 35 Milliseconds
> Listener added
> INFO - Service request (GET) /details.html took 162 Milliseconds
> INFO - Service request (GET) /ajax_request/liftAjax.js took 1
> Milliseconds
> INFO - Service request (GET) /comet_request/5gbp8rg1wko7/cometAjax.js
> took 6 Milliseconds
> TRACE - About to suspend continuation
> ERROR - The ActorWatcher restarted
> org.developerworks.comet.auctionac...@12cdd20 because
> scala.MatchError: None
> scala.MatchError: None
>at net.liftweb.mapper.DB$.releaseConnectionNamed(DB.scala:127)
>at net.liftweb.mapper.DB$.use(DB.scala:283)
>at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$
> $doWith(DB.scala:109)
>at net.liftweb.mapper.DB$$anon$1.apply(DB.scala:112)
>at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:
> 368)
>at net.liftweb.http.S$$anonfun$net$liftweb$http$S$
> $_nest2InnerInit$1.apply(S.scala:446)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit
> (S.scala:445)
>at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
> $1$$anonfun$apply$17$$anonfun$apply$18$$anonfun$apply$19$$anonfun$apply
> $20$$anonfun$apply$21.apply(S.scala:465)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
> $1$$anonfun$apply$17$$anonfun$apply$18$$anonfun$apply$19$$anonfun$apply
> $20.apply(S.scala:464)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
> $1$$anonfun$apply$17$$anonfun$apply$18$$anonfun$apply$19.apply(S.scala:
> 463)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
> $1$$anonfun$apply$17$$anonfun$apply$18.apply(S.scala:462)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
> $1$$anonfun$apply$17.apply(S.scala:461)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
> $1.apply(S.scala:460)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:
> 459)
>at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24$
> $anonfun$apply$25$$anonfun$apply$26$$anonfun$apply$27.apply(S.scala:
> 489)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24$
> $anonfun$apply$25$$anonfun$apply$26.apply(S.scala:488)
>at net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun
> $apply$4$$anonfun$apply$5.apply(Vars.scala:150)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun
> $apply$4.apply(Vars.scala:149)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.RequestVarHandler$$anonfun$apply$3.apply
> (Vars.scala:148)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:147)
>at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24$
> $anonfun$apply$25.apply(S.scala:486)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24.apply
> (S.scala:485)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:484)
>at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
>at net.liftweb.http.S$._init(S.scala:483)
>at net.liftweb.http.S$.init(S.scala:329)
>at net.liftweb.http.S$.initIfUninitted(S.scala:597)
>at net.liftweb.http.CometActor$$anon$1.apply(CometActor.scala:
> 163)
>at net.liftweb.http.CometActor$$anon$1.apply(CometActor.scala:
> 161)
>at scala.actors.Reaction.run(Reaction.scala:78)
> at scala.actors.FJTask$Wrap.run(Unknown Source)
>at scala.actors.FJTaskRunner.scanWhileIdling(Unknown Source)
> at scala.actors.FJTaskRunner.run(Unknown Source)
> Other 
> INFO - Service request (POST) /ajax_request took 83 Milliseconds
> TRACE - About to suspend continuation
> Other 
> TRACE - About to suspe

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[David Pollak]

Folks,

I have not had a single instance of wanting to change global application
behavior at runtime.  I cannot think of use case for such a feature.

On the other hand, the idea that your program behavior is stable from the
first HTTP request on makes a lot of sense to me.  It means tests work
because the tests don't have to worry about the behavior of the program
changing.  The same n steps will lead to the same result.

If anyone can come up with a use case for globally changing program behavior
during program execution, I'm all ears, but barring that, once the boot
phase is over, the stuff in LiftRules should be frozen.

Thanks,

David


On Sun, Dec 14, 2008 at 3:54 AM, Marius  wrote:

>
>
>
> On Dec 14, 12:53 pm, "Viktor Klang"  wrote:
> > On Sun, Dec 14, 2008 at 11:42 AM, Marius 
> wrote:
> >
> > > On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
> > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius 
> wrote:
> >
> > > > > On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
> > > > > > Not to beat a dead horse, but... what's the rationale, again, for
> > > > > throwing
> > > > > > an exception after boot? Is there a real danger to some or all
> > > RulesSeqs
> > > > > > being mutable after boot? If some, then those rules should
> > > selectively be
> > > > > > protected. Even if they're all dangerous, there are better (i.e.,
> > > type
> > > > > safe)
> > > > > > ways of protecting RulesSeqs from mutation than just throwing an
> > > > > exception.
> >
> > > > > This was actually DPP's suggestion. I'm not sure why would someone
> > > > > mutate them after boot but I'm totally opened if there is a strong
> > > > > case for allowing that. I do not have strong feelings about this so
> > > > > changing it would be trivial. Still I kind of like it this way.
> What
> > > > > other ways of protecting mutations after boot are you referring?
> ...
> > > > > something like ignore it and do nothing?
> >
> > > > Hmm, how about "locking" them by havign a paralell lazy val?
> >
> > > > val somePf : RuleSeq = Nil;
> >
> > > > lazy val runtimeSomePf = somePf.toList
> >
> > > > Then prepending/appending on the somePf AFTER runtimeSomePf has been
> > > > dereferenced won't make a difference.
> > > > (runtimeSomePf would be used by Lift internally if that isn't clear
> > > enough
> > > > :) )
> >
> > > Still we'd allow useless strong references on those lists.
> >
> > > > Or another, perhaps more suitable suggestion:
> >
> > > > make boot() have an InitializationContext parameter that's only
> available
> > > in
> > > > the scope of boot, and then the problem should disappear?
> >
> > > How would the problem disappear? ... I mean after boot people would
> > > still be able to add their functions (from API perspective) and they
> > > would be surprised that their functions are not called and yet lift
> > > just allowed them to do that.
> >
> > I meant something like:
> >
> > def boot(val lc : LiftContext) =
> > {
> >  //prepend/append,configure everything on lc
> >
> > }
> >
> > And then when the LiftFilter runt boot:
> >
> > {
> >val lc = LiftContext(/*servletContext and stuff goes here*/)
> >boot(lc)
> >LiftRules.init(lc)
> >
> > }
> >
> > And then only have non-append/prependable stuff in LiftRules?
> >
> > But really, what is it a problem that lift is reconfigurable during
> runtime?
> > I thought that was kind of cool?
>
> As I said I don't have strong opinions on this. It was DPP's
> suggestion and personally I kind of like it which does not mean that
> things can not change :) ... AFAIC reconfiguration at runtime does not
> make a whole lot of sense because:
>
> 1. We'd have to expose other functions to allow people to also remove
> their function not only prepend & append them
> 2. I do not see what kinds of problems runtime reconfiguration really
> solve (I'm only referring on the current RulesSeq members). I haven't
> encounter a practical need but if you have please let me know.
> 3. Dynamic behavior can happen inside user's functions without
> allowing runtime reconfiguration.
>
> Just my 2 cents ...
>
> P.S.
> If the general consensus is to remove this restriction I have no
> problem removing it ... so more thoughts/perspectives on this are
> welcomed.
>
>
>
> >
> > Cheers,
> > Viktor
> >
> >
> >
> >
> >
> > > > Cheers,
> > > > Viktor
> >
> > > > > > Nit-pick: why is 'toList' (which just returns 'rules') defined as
> > > > > > private[http] when 'rules' itself is public?
> >
> > > > > Why would you use toList in the lift app code? ...RulesSeq is
> mainly
> > > > > about adding user functions to lift. If "rules" itself is public
> > > > > doesn't necessary mean that it should not have its "private" logic.
> >
> > > > > > Also, if RulesSeq are always made up of either Functions or
> > > > > > PartialFunctions, maybe we should enforce that at a type level,
> and
> > > the
> > > > > > helper methods on Seqs of PFs that now exist in the NamedPF
> object
> > > can be
> > > > > > put in the RulesSeq object.
> >
> > > > 

[Lift] Re: Hooking into /user_mgt

[Juha L]

There already seems to be hooks for login & logout (onLogIn/onLogOut)
in the MetaMegaProtoUser. Would it be possible to also add onSignUp
which would be called when user has been successfully created &
validated? That would make it trivial to do basic initializations for
the new users.

// Juha

On Dec 14, 6:18 am, "Derek Chen-Becker"  wrote:
> /user_mgt is handled via MetaMegaProtoUser. You may be able to override some
> things there.
>
> Derek
>
> On Sat, Dec 13, 2008 at 2:03 PM, Juha L  wrote:
>
> > Hi again,
>
> > I have need to hook some extra code into user sign up, login, and
> > logout. In archetype-basic project all things related to user
> > management seem to happen in magical "/user_mgt", and I couldn't
> > really find any good information about how I could alter what happens
> > there. Could anyone provide me pointers or examples?
>
> > // Juha

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] XML problems in ToDo tutorial?

[Stefan Scott]

Hi -

On page 14 of the ToDo tutorial here:

http://groups.google.com/group/liftweb/browse_thread/thread/0d99974c622262d5#

after I edit the file 'src/main/webapp/index.html' so that it now
reads:


Please
Log In



and I stop jetty (Ctl-C) and then recompile/restart with 'mvn
jetty:run'...

I get the following error in the browser on the first screen:


XML Parsing Error: syntax error
Location: http://localhost:8080/
Line Number 4, Column 1:Please



If I remove the word "Please" from that file, I get a different error:


This XML file does not appear to have any style information associated
with it.
The document tree is shown below.

Please Log In



If I replace my '~\jetty\webapps\todo' directory with the *completed*
todo.tgz archive supplied with the tutorial (thereby skipping ahead a
few steps in the tutorial) and recompile/restart, it works fine. But
if I create these steps myself, I keep getting these XML errors.

Any suggestions? Am I missing a file somewhere?

Thanks!

- Stefan Scott




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] ToDo Tutorial - Layout for added column

[Stefan Scott]

Hi -

I'm about halfway through the new ToDo Tutorial available here:

http://groups.google.com/group/liftweb/browse_thread/thread/0d99974c622262d5#

and I wanted to try adding a new column "loc" ("Location").

(NOTE: As pointed out in another threads here today, you have to do
'cd todo' before doing 'mvn jetty:run' on page 6 of the tutorial.)

I added my new column "loc" ("Location") to the model, and it displays
on the screen (in the list of existing ToDo's, and below in the form
for adding a new ToDo), but I can't control the formatting - my
columns aren't straight.

(They just happened to be straight in the *basic* tutorial because the
"desc" or "Description" happens to be the last column, and all the
preceding columns are either Boolean or drop-down menu, which are
fixed width.)

Anybody have an example of this? Between the currying and the Ajax, I
can't quite wrap my mind around how the html is being generated.

Thanks. I'm very exciteds about Scala and /lift/ !

- Stefan Scott


Here are the 3 files I've updated:


C:\www\jetty\webapps\todo\src\main\webapp\ToDo.scala


  

  
Exclude done 

  

  Location
  
  
1
  
  To Do

  

  




  

  Location:
  Location


  Description:
  To Do


  
Priority
  
  

  1

  


   
  

  New

  

  

  


  Please
Log In
  


==

C:\www\jetty\webapps\todo\src\main\scala\com\liftworkshop\model
\ToDo.scala

package com.liftworkshop.model

import net.liftweb._
import mapper._
import http._
import SHtml._
import util._

class ToDo extends LongKeyedMapper[ToDo] with IdPK {
  def getSingleton = ToDo

  object done extends MappedBoolean(this)

  object owner extends MappedLongForeignKey(this, User)

  object priority extends MappedInt(this) {
override def defaultValue = 5
override def validations = validPriority _ :: super.validations
def validPriority(in: Int): List[FieldError] =
if (in > 0 && in <= 10) Nil
else List(FieldError(this, Priority must be 1-10))
override def _toForm = Full(select(ToDo.priorityList,
   Full(is.toString),
   f => set(f.toInt)))
  }

  object desc extends MappedPoliteString(this, 128) {
override def validations =
valMinLen(3, "Description must be 3 characters") _ ::
super.validations
  }

  object loc extends MappedPoliteString(this, 63) {
override def validations =
valMinLen(3, "Location must be 3 characters") _ ::
super.validations
  }
}

object ToDo extends ToDo with LongKeyedMetaMapper[ToDo] {
  lazy val priorityList = (1 to 10).
  map(v => (v.toString, v.toString))
}

==

C:\www\jetty\webapps\todo\src\main\scala\com\liftworkshop\snippet
\TD.scala

package com.liftworkshop.snippet
import com.liftworkshop._
import model._
import net.liftweb._
import http._
import SHtml._
import S._
import js._
import JsCmds._
import mapper._
import util._
import Helpers._
import scala.xml.{NodeSeq, Text}

class TD {
  def add(form: NodeSeq) = {
val todo = ToDo.create.owner(User.currentUser)
def checkAndSave(): Unit =
todo.validate match {
  case Nil => todo.save ; S.notice("Added "+todo.desc)
  case xs => S.error(xs) ; S.mapSnippet("TD.add", doBind)
}
def doBind(form: NodeSeq) =
bind("todo", form,
 "priority" -> todo.priority.toForm,
 "desc" -> todo.desc.toForm,
 "loc" -> todo.loc.toForm,
 "submit" -> submit("New", checkAndSave))
doBind(form)
  }

  private def toShow =
  ToDo.findAll(By(ToDo.owner, User.currentUser),
   if (QueryNotDone) By(ToDo.done, false)
   else Ignore[ToDo],
   OrderBy(ToDo.done, Ascending),
   OrderBy(ToDo.priority, Descending),
   OrderBy(ToDo.desc, Ascending))

  private def desc(td: ToDo, reDraw: () => JsCmd) =
  swappable({td.desc},
{ajaxText(td.desc,
v => {td.desc(v).save; reDraw()})}
)

  private def loc(td: ToDo, reDraw: () => JsCmd) =
  swappable({td.loc},
{ajaxText(td.loc,
v => {td.loc(v).save; reDraw()})}
)

  private def doList(reDraw: () => JsCmd)(html: NodeSeq): NodeSeq =
  toShow.
  flatMap(td =>
bind("todo", html,
 "check" -> ajaxCheckbox(td.done,
 v => {td.done(v).save; reDraw()}),
 "priority" ->
 ajaxSelect(ToDo.priorityList, Full(td.priority.toString),
v => {td.priority(

[Lift] todo_steps feedback

[mal3]

David,

I'm not sure where to send feedback on the todo_steps book. I'm
working my way through the todo
project, and I my feedback may be at times very minor in the interests
of doing my bit to help with
the final book product.

There was a warning with the first mvn command:

[INFO] [archetype:create]
[WARNING] This goals is deprecated. Please use mvn archetype:generate
instead

mvn archetype:generate seemed to work just as well. If there's no
reason to use create rather than generate,
maybe change it to generate in the book.

Mal.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: More JPA goodness

[philip]

How does it relate to the new "record" way of accessing database?

On Dec 14, 6:19 am, "Derek Chen-Becker"  wrote:
> OK, party people. I've broken out behaviors into a number of traits. Since
> I'm coming at this from Lift, I've also added a nice trait to make using JPA
> from Lift nice and simple. For now I'll host the scaladocs up on my own
> website:
>
> http://chen-becker.org/scalajpa/scaladocs/index.html
>
> The code is available on git:
>
> http://github.com/dchenbecker/scalajpa/tree/master
>
> Just to give you a sample of what this can do, here's how we define a Local
> JPA module:
>
> object Model extends LocalEM("mypersistenceunit") with RequestVarEM
>
> Ta da! That's it; oyu no longer have to code up the request var stuff, or
> even transaction handling (it's optional on the LocalEM trait, but JNDI
> generally requires JTA). If you want JNDI instead:
>
> object Model extends JndiEM("java:/MyUnitEM") with RequestVarEM
>
> If you'd rather manage the EMs yourself, just drop the RequestVarEM:
>
> object Model extends LocalEM("foo")
>
> and in your code:
>
> val em = Model.newEM
> em.findAll(...)
> em.close()
>
> The RequestVarEM (and ThreadLocalEM, for use outside of Lift) can be used to
> make your object a singleton ScalaEntityManager, so the EM methods are
> called directly on your object:
>
> Model.createNamedQuery(...)
> Model.lock(...)
>
> I think that with this design we get maximum flexibility by using the traits
> to control independent behaviors, but as always I'm open to suggestions. One
> thing I've been vacillating on is naming things like RequestVarEM
> RequestVarSingleton to explicitly show that it makes the object a singleton
> EM, but I don't know that it makes a huge difference either way.
>
> Cheers,
>
> Derek
>
> PS - I'll discuss getting this up on scala-tools.org with David B. so that
> it's in the repos soon.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Crashing CometActor

[Michael]

Looks like Hudson was up again, so I pulled in the latest snapshot
from scala-tools and added the log level statement. It didn't seem to
matter much though:

INFO - Service request (GET) / took 35 Milliseconds
Listener added
INFO - Service request (GET) /details.html took 162 Milliseconds
INFO - Service request (GET) /ajax_request/liftAjax.js took 1
Milliseconds
INFO - Service request (GET) /comet_request/5gbp8rg1wko7/cometAjax.js
took 6 Milliseconds
TRACE - About to suspend continuation
ERROR - The ActorWatcher restarted
org.developerworks.comet.auctionac...@12cdd20 because
scala.MatchError: None
scala.MatchError: None
at net.liftweb.mapper.DB$.releaseConnectionNamed(DB.scala:127)
at net.liftweb.mapper.DB$.use(DB.scala:283)
at net.liftweb.mapper.DB$$anon$1.net$liftweb$mapper$DB$$anon$
$doWith(DB.scala:109)
at net.liftweb.mapper.DB$$anon$1.apply(DB.scala:112)
at net.liftweb.http.S$.net$liftweb$http$S$$doAround(S.scala:
368)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$
$_nest2InnerInit$1.apply(S.scala:446)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$.net$liftweb$http$S$$_nest2InnerInit
(S.scala:445)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
$1$$anonfun$apply$17$$anonfun$apply$18$$anonfun$apply$19$$anonfun$apply
$20$$anonfun$apply$21.apply(S.scala:465)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
$1$$anonfun$apply$17$$anonfun$apply$18$$anonfun$apply$19$$anonfun$apply
$20.apply(S.scala:464)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
$1$$anonfun$apply$17$$anonfun$apply$18$$anonfun$apply$19.apply(S.scala:
463)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
$1$$anonfun$apply$17$$anonfun$apply$18.apply(S.scala:462)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
$1$$anonfun$apply$17.apply(S.scala:461)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$net$liftweb$http$S$$_innerInit
$1.apply(S.scala:460)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$.net$liftweb$http$S$$_innerInit(S.scala:
459)
at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24$
$anonfun$apply$25$$anonfun$apply$26$$anonfun$apply$27.apply(S.scala:
489)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24$
$anonfun$apply$25$$anonfun$apply$26.apply(S.scala:488)
at net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun
$apply$4$$anonfun$apply$5.apply(Vars.scala:150)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.RequestVarHandler$$anonfun$apply$3$$anonfun
$apply$4.apply(Vars.scala:149)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.RequestVarHandler$$anonfun$apply$3.apply
(Vars.scala:148)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.RequestVarHandler$.apply(Vars.scala:147)
at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24$
$anonfun$apply$25.apply(S.scala:486)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$_init$1$$anonfun$apply$24.apply
(S.scala:485)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$$anonfun$_init$1.apply(S.scala:484)
at net.liftweb.util.ThreadGlobal.doWith(ThreadGlobal.scala:31)
at net.liftweb.http.S$._init(S.scala:483)
at net.liftweb.http.S$.init(S.scala:329)
at net.liftweb.http.S$.initIfUninitted(S.scala:597)
at net.liftweb.http.CometActor$$anon$1.apply(CometActor.scala:
163)
at net.liftweb.http.CometActor$$anon$1.apply(CometActor.scala:
161)
at scala.actors.Reaction.run(Reaction.scala:78)
at scala.actors.FJTask$Wrap.run(Unknown Source)
at scala.actors.FJTaskRunner.scanWhileIdling(Unknown Source)
at scala.actors.FJTaskRunner.run(Unknown Source)
Other 
INFO - Service request (POST) /ajax_request took 83 Milliseconds
TRACE - About to suspend continuation
Other 
TRACE - About to suspend continuation


On Dec 13, 9:45 am, "David Pollak" 
wrote:
> Michael,
> I'm not sure what's going on.  I just added some extra debugging statements
> to the acquisition/release of DB connections.
>
> Please wait until the new version of Lift is in Hudson (or pull and build
> locally... well looks like Hudson's down again... so you'll have to build
> locally:http

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Viktor Klang]

On Sun, Dec 14, 2008 at 12:54 PM, Marius  wrote:

>
>
>
> On Dec 14, 12:53 pm, "Viktor Klang"  wrote:
> > On Sun, Dec 14, 2008 at 11:42 AM, Marius 
> wrote:
> >
> > > On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
> > > > On Sun, Dec 14, 2008 at 9:28 AM, Marius 
> wrote:
> >
> > > > > On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
> > > > > > Not to beat a dead horse, but... what's the rationale, again, for
> > > > > throwing
> > > > > > an exception after boot? Is there a real danger to some or all
> > > RulesSeqs
> > > > > > being mutable after boot? If some, then those rules should
> > > selectively be
> > > > > > protected. Even if they're all dangerous, there are better (i.e.,
> > > type
> > > > > safe)
> > > > > > ways of protecting RulesSeqs from mutation than just throwing an
> > > > > exception.
> >
> > > > > This was actually DPP's suggestion. I'm not sure why would someone
> > > > > mutate them after boot but I'm totally opened if there is a strong
> > > > > case for allowing that. I do not have strong feelings about this so
> > > > > changing it would be trivial. Still I kind of like it this way.
> What
> > > > > other ways of protecting mutations after boot are you referring?
> ...
> > > > > something like ignore it and do nothing?
> >
> > > > Hmm, how about "locking" them by havign a paralell lazy val?
> >
> > > > val somePf : RuleSeq = Nil;
> >
> > > > lazy val runtimeSomePf = somePf.toList
> >
> > > > Then prepending/appending on the somePf AFTER runtimeSomePf has been
> > > > dereferenced won't make a difference.
> > > > (runtimeSomePf would be used by Lift internally if that isn't clear
> > > enough
> > > > :) )
> >
> > > Still we'd allow useless strong references on those lists.
> >
> > > > Or another, perhaps more suitable suggestion:
> >
> > > > make boot() have an InitializationContext parameter that's only
> available
> > > in
> > > > the scope of boot, and then the problem should disappear?
> >
> > > How would the problem disappear? ... I mean after boot people would
> > > still be able to add their functions (from API perspective) and they
> > > would be surprised that their functions are not called and yet lift
> > > just allowed them to do that.
> >
> > I meant something like:
> >
> > def boot(val lc : LiftContext) =
> > {
> >  //prepend/append,configure everything on lc
> >
> > }
> >
> > And then when the LiftFilter runt boot:
> >
> > {
> >val lc = LiftContext(/*servletContext and stuff goes here*/)
> >boot(lc)
> >LiftRules.init(lc)
> >
> > }
> >
> > And then only have non-append/prependable stuff in LiftRules?
> >
> > But really, what is it a problem that lift is reconfigurable during
> runtime?
> > I thought that was kind of cool?
>
> As I said I don't have strong opinions on this. It was DPP's
> suggestion and personally I kind of like it which does not mean that
> things can not change :) ... AFAIC reconfiguration at runtime does not
> make a whole lot of sense because:
>
> 1. We'd have to expose other functions to allow people to also remove
> their function not only prepend & append them
> 2. I do not see what kinds of problems runtime reconfiguration really
> solve (I'm only referring on the current RulesSeq members). I haven't
> encounter a practical need but if you have please let me know.
> 3. Dynamic behavior can happen inside user's functions without
> allowing runtime reconfiguration.
>
> Just my 2 cents ...
>
> P.S.
> If the general consensus is to remove this restriction I have no
> problem removing it ... so more thoughts/perspectives on this are
> welcomed.



I have no opinion, I'm just offering solutions :)



>
>
>
>
> >
> > Cheers,
> > Viktor
> >
> >
> >
> >
> >
> > > > Cheers,
> > > > Viktor
> >
> > > > > > Nit-pick: why is 'toList' (which just returns 'rules') defined as
> > > > > > private[http] when 'rules' itself is public?
> >
> > > > > Why would you use toList in the lift app code? ...RulesSeq is
> mainly
> > > > > about adding user functions to lift. If "rules" itself is public
> > > > > doesn't necessary mean that it should not have its "private" logic.
> >
> > > > > > Also, if RulesSeq are always made up of either Functions or
> > > > > > PartialFunctions, maybe we should enforce that at a type level,
> and
> > > the
> > > > > > helper methods on Seqs of PFs that now exist in the NamedPF
> object
> > > can be
> > > > > > put in the RulesSeq object.
> >
> > > > > But what would be the benefit? .. except that it would simplify a
> bit
> > > > > how Lift calls these PF's?
> >
> > > > > ... to me distinguishing between functions and partial functions
> here
> > > > > by using Either or even using different RulesSeq traits would not
> > > > > bring much benefits ... but I hope I'm wrong.
> >
> > > > > > --j
> >
> > > > > > On Sat, Dec 13, 2008 at 2:31 PM, Marius  >
> > > wrote:
> >
> > > > > > > All,
> >
> > > > > > > I committed a bunch of changes in LiftRules. In a previous
> thread
> > > > > > > Jorge suggested the abstraction of LiftRules va

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Marius]

On Dec 14, 12:53 pm, "Viktor Klang"  wrote:
> On Sun, Dec 14, 2008 at 11:42 AM, Marius  wrote:
>
> > On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
> > > On Sun, Dec 14, 2008 at 9:28 AM, Marius  wrote:
>
> > > > On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
> > > > > Not to beat a dead horse, but... what's the rationale, again, for
> > > > throwing
> > > > > an exception after boot? Is there a real danger to some or all
> > RulesSeqs
> > > > > being mutable after boot? If some, then those rules should
> > selectively be
> > > > > protected. Even if they're all dangerous, there are better (i.e.,
> > type
> > > > safe)
> > > > > ways of protecting RulesSeqs from mutation than just throwing an
> > > > exception.
>
> > > > This was actually DPP's suggestion. I'm not sure why would someone
> > > > mutate them after boot but I'm totally opened if there is a strong
> > > > case for allowing that. I do not have strong feelings about this so
> > > > changing it would be trivial. Still I kind of like it this way. What
> > > > other ways of protecting mutations after boot are you referring? ...
> > > > something like ignore it and do nothing?
>
> > > Hmm, how about "locking" them by havign a paralell lazy val?
>
> > > val somePf : RuleSeq = Nil;
>
> > > lazy val runtimeSomePf = somePf.toList
>
> > > Then prepending/appending on the somePf AFTER runtimeSomePf has been
> > > dereferenced won't make a difference.
> > > (runtimeSomePf would be used by Lift internally if that isn't clear
> > enough
> > > :) )
>
> > Still we'd allow useless strong references on those lists.
>
> > > Or another, perhaps more suitable suggestion:
>
> > > make boot() have an InitializationContext parameter that's only available
> > in
> > > the scope of boot, and then the problem should disappear?
>
> > How would the problem disappear? ... I mean after boot people would
> > still be able to add their functions (from API perspective) and they
> > would be surprised that their functions are not called and yet lift
> > just allowed them to do that.
>
> I meant something like:
>
> def boot(val lc : LiftContext) =
> {
>      //prepend/append,configure everything on lc
>
> }
>
> And then when the LiftFilter runt boot:
>
> {
>    val lc = LiftContext(/*servletContext and stuff goes here*/)
>    boot(lc)
>    LiftRules.init(lc)
>
> }
>
> And then only have non-append/prependable stuff in LiftRules?
>
> But really, what is it a problem that lift is reconfigurable during runtime?
> I thought that was kind of cool?

As I said I don't have strong opinions on this. It was DPP's
suggestion and personally I kind of like it which does not mean that
things can not change :) ... AFAIC reconfiguration at runtime does not
make a whole lot of sense because:

1. We'd have to expose other functions to allow people to also remove
their function not only prepend & append them
2. I do not see what kinds of problems runtime reconfiguration really
solve (I'm only referring on the current RulesSeq members). I haven't
encounter a practical need but if you have please let me know.
3. Dynamic behavior can happen inside user's functions without
allowing runtime reconfiguration.

Just my 2 cents ...

P.S.
If the general consensus is to remove this restriction I have no
problem removing it ... so more thoughts/perspectives on this are
welcomed.



>
> Cheers,
> Viktor
>
>
>
>
>
> > > Cheers,
> > > Viktor
>
> > > > > Nit-pick: why is 'toList' (which just returns 'rules') defined as
> > > > > private[http] when 'rules' itself is public?
>
> > > > Why would you use toList in the lift app code? ...RulesSeq is mainly
> > > > about adding user functions to lift. If "rules" itself is public
> > > > doesn't necessary mean that it should not have its "private" logic.
>
> > > > > Also, if RulesSeq are always made up of either Functions or
> > > > > PartialFunctions, maybe we should enforce that at a type level, and
> > the
> > > > > helper methods on Seqs of PFs that now exist in the NamedPF object
> > can be
> > > > > put in the RulesSeq object.
>
> > > > But what would be the benefit? .. except that it would simplify a bit
> > > > how Lift calls these PF's?
>
> > > > ... to me distinguishing between functions and partial functions here
> > > > by using Either or even using different RulesSeq traits would not
> > > > bring much benefits ... but I hope I'm wrong.
>
> > > > > --j
>
> > > > > On Sat, Dec 13, 2008 at 2:31 PM, Marius 
> > wrote:
>
> > > > > > All,
>
> > > > > > I committed a bunch of changes in LiftRules. In a previous thread
> > > > > > Jorge suggested the abstraction of LiftRules variables. Lists of
> > > > > > functions are now abstracted by RulesSeq trait, which contains
> > prepend
> > > > > > and append functions. Note that if you're calling prepend/append
> > > > > > functions after boot they will throw an exception. If there are
> > > > > > compelling reasons not to do this please let us know. This is just
> > a
> > > > > > mechanism to enforce the use of these functions

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Viktor Klang]

On Sun, Dec 14, 2008 at 11:42 AM, Marius  wrote:

>
>
>
> On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
> > On Sun, Dec 14, 2008 at 9:28 AM, Marius  wrote:
> >
> > > On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
> > > > Not to beat a dead horse, but... what's the rationale, again, for
> > > throwing
> > > > an exception after boot? Is there a real danger to some or all
> RulesSeqs
> > > > being mutable after boot? If some, then those rules should
> selectively be
> > > > protected. Even if they're all dangerous, there are better (i.e.,
> type
> > > safe)
> > > > ways of protecting RulesSeqs from mutation than just throwing an
> > > exception.
> >
> > > This was actually DPP's suggestion. I'm not sure why would someone
> > > mutate them after boot but I'm totally opened if there is a strong
> > > case for allowing that. I do not have strong feelings about this so
> > > changing it would be trivial. Still I kind of like it this way. What
> > > other ways of protecting mutations after boot are you referring? ...
> > > something like ignore it and do nothing?
> >
> > Hmm, how about "locking" them by havign a paralell lazy val?
> >
> > val somePf : RuleSeq = Nil;
> >
> > lazy val runtimeSomePf = somePf.toList
> >
> > Then prepending/appending on the somePf AFTER runtimeSomePf has been
> > dereferenced won't make a difference.
> > (runtimeSomePf would be used by Lift internally if that isn't clear
> enough
> > :) )
>
> Still we'd allow useless strong references on those lists.
>
> >
> > Or another, perhaps more suitable suggestion:
> >
> > make boot() have an InitializationContext parameter that's only available
> in
> > the scope of boot, and then the problem should disappear?
>
> How would the problem disappear? ... I mean after boot people would
> still be able to add their functions (from API perspective) and they
> would be surprised that their functions are not called and yet lift
> just allowed them to do that.



I meant something like:

def boot(val lc : LiftContext) =
{
 //prepend/append,configure everything on lc
}


And then when the LiftFilter runt boot:

{
   val lc = LiftContext(/*servletContext and stuff goes here*/)
   boot(lc)
   LiftRules.init(lc)
}

And then only have non-append/prependable stuff in LiftRules?




But really, what is it a problem that lift is reconfigurable during runtime?
I thought that was kind of cool?

Cheers,
Viktor



>
>
> >
> > Cheers,
> > Viktor
> >
> >
> >
> >
> >
> > > > Nit-pick: why is 'toList' (which just returns 'rules') defined as
> > > > private[http] when 'rules' itself is public?
> >
> > > Why would you use toList in the lift app code? ...RulesSeq is mainly
> > > about adding user functions to lift. If "rules" itself is public
> > > doesn't necessary mean that it should not have its "private" logic.
> >
> > > > Also, if RulesSeq are always made up of either Functions or
> > > > PartialFunctions, maybe we should enforce that at a type level, and
> the
> > > > helper methods on Seqs of PFs that now exist in the NamedPF object
> can be
> > > > put in the RulesSeq object.
> >
> > > But what would be the benefit? .. except that it would simplify a bit
> > > how Lift calls these PF's?
> >
> > > ... to me distinguishing between functions and partial functions here
> > > by using Either or even using different RulesSeq traits would not
> > > bring much benefits ... but I hope I'm wrong.
> >
> > > > --j
> >
> > > > On Sat, Dec 13, 2008 at 2:31 PM, Marius 
> wrote:
> >
> > > > > All,
> >
> > > > > I committed a bunch of changes in LiftRules. In a previous thread
> > > > > Jorge suggested the abstraction of LiftRules variables. Lists of
> > > > > functions are now abstracted by RulesSeq trait, which contains
> prepend
> > > > > and append functions. Note that if you're calling prepend/append
> > > > > functions after boot they will throw an exception. If there are
> > > > > compelling reasons not to do this please let us know. This is just
> a
> > > > > mechanism to enforce the use of these functions on startup.
> >
> > > > > Br's,
> > > > > Marius
> >
> > --
> > Viktor Klang
> > Senior Systems Analyst
> >
>


-- 
Viktor Klang
Senior Systems Analyst

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Marius]

On Dec 14, 12:10 pm, "Viktor Klang"  wrote:
> On Sun, Dec 14, 2008 at 9:28 AM, Marius  wrote:
>
> > On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
> > > Not to beat a dead horse, but... what's the rationale, again, for
> > throwing
> > > an exception after boot? Is there a real danger to some or all RulesSeqs
> > > being mutable after boot? If some, then those rules should selectively be
> > > protected. Even if they're all dangerous, there are better (i.e., type
> > safe)
> > > ways of protecting RulesSeqs from mutation than just throwing an
> > exception.
>
> > This was actually DPP's suggestion. I'm not sure why would someone
> > mutate them after boot but I'm totally opened if there is a strong
> > case for allowing that. I do not have strong feelings about this so
> > changing it would be trivial. Still I kind of like it this way. What
> > other ways of protecting mutations after boot are you referring? ...
> > something like ignore it and do nothing?
>
> Hmm, how about "locking" them by havign a paralell lazy val?
>
> val somePf : RuleSeq = Nil;
>
> lazy val runtimeSomePf = somePf.toList
>
> Then prepending/appending on the somePf AFTER runtimeSomePf has been
> dereferenced won't make a difference.
> (runtimeSomePf would be used by Lift internally if that isn't clear enough
> :) )

Still we'd allow useless strong references on those lists.

>
> Or another, perhaps more suitable suggestion:
>
> make boot() have an InitializationContext parameter that's only available in
> the scope of boot, and then the problem should disappear?

How would the problem disappear? ... I mean after boot people would
still be able to add their functions (from API perspective) and they
would be surprised that their functions are not called and yet lift
just allowed them to do that.

>
> Cheers,
> Viktor
>
>
>
>
>
> > > Nit-pick: why is 'toList' (which just returns 'rules') defined as
> > > private[http] when 'rules' itself is public?
>
> > Why would you use toList in the lift app code? ...RulesSeq is mainly
> > about adding user functions to lift. If "rules" itself is public
> > doesn't necessary mean that it should not have its "private" logic.
>
> > > Also, if RulesSeq are always made up of either Functions or
> > > PartialFunctions, maybe we should enforce that at a type level, and the
> > > helper methods on Seqs of PFs that now exist in the NamedPF object can be
> > > put in the RulesSeq object.
>
> > But what would be the benefit? .. except that it would simplify a bit
> > how Lift calls these PF's?
>
> > ... to me distinguishing between functions and partial functions here
> > by using Either or even using different RulesSeq traits would not
> > bring much benefits ... but I hope I'm wrong.
>
> > > --j
>
> > > On Sat, Dec 13, 2008 at 2:31 PM, Marius  wrote:
>
> > > > All,
>
> > > > I committed a bunch of changes in LiftRules. In a previous thread
> > > > Jorge suggested the abstraction of LiftRules variables. Lists of
> > > > functions are now abstracted by RulesSeq trait, which contains prepend
> > > > and append functions. Note that if you're calling prepend/append
> > > > functions after boot they will throw an exception. If there are
> > > > compelling reasons not to do this please let us know. This is just a
> > > > mechanism to enforce the use of these functions on startup.
>
> > > > Br's,
> > > > Marius
>
> --
> Viktor Klang
> Senior Systems Analyst
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Viktor Klang]

On Sun, Dec 14, 2008 at 9:28 AM, Marius  wrote:

>
>
>
> On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
> > Not to beat a dead horse, but... what's the rationale, again, for
> throwing
> > an exception after boot? Is there a real danger to some or all RulesSeqs
> > being mutable after boot? If some, then those rules should selectively be
> > protected. Even if they're all dangerous, there are better (i.e., type
> safe)
> > ways of protecting RulesSeqs from mutation than just throwing an
> exception.
>
> This was actually DPP's suggestion. I'm not sure why would someone
> mutate them after boot but I'm totally opened if there is a strong
> case for allowing that. I do not have strong feelings about this so
> changing it would be trivial. Still I kind of like it this way. What
> other ways of protecting mutations after boot are you referring? ...
> something like ignore it and do nothing?


Hmm, how about "locking" them by havign a paralell lazy val?

val somePf : RuleSeq = Nil;

lazy val runtimeSomePf = somePf.toList

Then prepending/appending on the somePf AFTER runtimeSomePf has been
dereferenced won't make a difference.
(runtimeSomePf would be used by Lift internally if that isn't clear enough
:) )


Or another, perhaps more suitable suggestion:

make boot() have an InitializationContext parameter that's only available in
the scope of boot, and then the problem should disappear?

Cheers,
Viktor




>
> >
> > Nit-pick: why is 'toList' (which just returns 'rules') defined as
> > private[http] when 'rules' itself is public?
>
> Why would you use toList in the lift app code? ...RulesSeq is mainly
> about adding user functions to lift. If "rules" itself is public
> doesn't necessary mean that it should not have its "private" logic.
>
> >
> > Also, if RulesSeq are always made up of either Functions or
> > PartialFunctions, maybe we should enforce that at a type level, and the
> > helper methods on Seqs of PFs that now exist in the NamedPF object can be
> > put in the RulesSeq object.
>
> But what would be the benefit? .. except that it would simplify a bit
> how Lift calls these PF's?
>
> ... to me distinguishing between functions and partial functions here
> by using Either or even using different RulesSeq traits would not
> bring much benefits ... but I hope I'm wrong.
>
>
>
> >
> > --j
> >
> > On Sat, Dec 13, 2008 at 2:31 PM, Marius  wrote:
> >
> > > All,
> >
> > > I committed a bunch of changes in LiftRules. In a previous thread
> > > Jorge suggested the abstraction of LiftRules variables. Lists of
> > > functions are now abstracted by RulesSeq trait, which contains prepend
> > > and append functions. Note that if you're calling prepend/append
> > > functions after boot they will throw an exception. If there are
> > > compelling reasons not to do this please let us know. This is just a
> > > mechanism to enforce the use of these functions on startup.
> >
> > > Br's,
> > > Marius
> >
>


-- 
Viktor Klang
Senior Systems Analyst

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: *** MAJOR BREAKING CHANGES *** LiftRules abstractions

[Marius]

On Dec 14, 3:02 am, "Jorge Ortiz"  wrote:
> Not to beat a dead horse, but... what's the rationale, again, for throwing
> an exception after boot? Is there a real danger to some or all RulesSeqs
> being mutable after boot? If some, then those rules should selectively be
> protected. Even if they're all dangerous, there are better (i.e., type safe)
> ways of protecting RulesSeqs from mutation than just throwing an exception.

This was actually DPP's suggestion. I'm not sure why would someone
mutate them after boot but I'm totally opened if there is a strong
case for allowing that. I do not have strong feelings about this so
changing it would be trivial. Still I kind of like it this way. What
other ways of protecting mutations after boot are you referring? ...
something like ignore it and do nothing?

>
> Nit-pick: why is 'toList' (which just returns 'rules') defined as
> private[http] when 'rules' itself is public?

Why would you use toList in the lift app code? ...RulesSeq is mainly
about adding user functions to lift. If "rules" itself is public
doesn't necessary mean that it should not have its "private" logic.

>
> Also, if RulesSeq are always made up of either Functions or
> PartialFunctions, maybe we should enforce that at a type level, and the
> helper methods on Seqs of PFs that now exist in the NamedPF object can be
> put in the RulesSeq object.

But what would be the benefit? .. except that it would simplify a bit
how Lift calls these PF's?

... to me distinguishing between functions and partial functions here
by using Either or even using different RulesSeq traits would not
bring much benefits ... but I hope I'm wrong.



>
> --j
>
> On Sat, Dec 13, 2008 at 2:31 PM, Marius  wrote:
>
> > All,
>
> > I committed a bunch of changes in LiftRules. In a previous thread
> > Jorge suggested the abstraction of LiftRules variables. Lists of
> > functions are now abstracted by RulesSeq trait, which contains prepend
> > and append functions. Note that if you're calling prepend/append
> > functions after boot they will throw an exception. If there are
> > compelling reasons not to do this please let us know. This is just a
> > mechanism to enforce the use of these functions on startup.
>
> > Br's,
> > Marius
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---