[Lift] How to install non-standard Lift from GitHub

2009-07-25 Thread Jon Kleiser

I have pulled and built a certain Lift branch from the GitHub on my Mac,
and I would like to temporarily switch to using that branch. Do I have to
make an installer app (how?) and run that, or could I just set up some
pointer(s) (like an environment variable) to the directory where all the
new jars are? (I may want to switch back to standard Lift 1.0 soon
afterwards.)

/Jon


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



[Lift] Re: How to install non-standard Lift from GitHub

2009-07-25 Thread Indrajit

Jon,

Assuming you are using Maven (you probably are if you used the
installer), you can move to the lift-core module and do an 'mvn
install' to have everything built and deployed in the local Maven
repository. (cd lift-core ; mvn install)

Subsequently, you can modify your projects pom.xml to have lift-core
dependency set to 1.1-SNAPSHOT (you must be having 1.0 there) to use
the version that you just built.
You can revert the lift-core dependency to 1.0 to switch back to
standard Lift 1.0.

/irc


On Jul 25, 7:46 pm, Jon Kleiser jon.klei...@usit.uio.no wrote:
 I have pulled and built a certain Lift branch from the GitHub on my Mac,
 and I would like to temporarily switch to using that branch. Do I have to
 make an installer app (how?) and run that, or could I just set up some
 pointer(s) (like an environment variable) to the directory where all the
 new jars are? (I may want to switch back to standard Lift 1.0 soon
 afterwards.)

 /Jon

--~--~-~--~~~---~--~~
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] Lift (AsyncWeb || ...)

2009-07-25 Thread Marius

Hi,

Did anyone played with AsyncWeb? .. Looks pretty promising but I
think having Lift working properly with it we need some adaptions. For
instance:

1. Lift uses HttpServletXXX references provided by JEE containers. One
solution that avoids vast code change is Lift is to bridge AsyncWeb
API through our own implementation of HttpServlet, HttpServletXXX etc.

2. Session management .. We'd also need a bridge for HttpSession ..
but that should be pretty straight forward. (Fortunately we have
LiftSession only bridged to HTTP session today.)

3. Comet support. Async Web fundamental concept seems to map pretty
well to Comet model. Probably they don't have the suspend/resume
mechanism as Jetty but there are some other means to do it right. Need
to look more into it ...

The point is that perhaps we should expand a bit and not depend so
much on JEE web container anymore as there are other viable
alternatives. We just need to build a flexible and transparent wiring
mechanism.

I'll probably start looking more into this path but first I'd like to
see your thoughts ...

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: Lift (AsyncWeb || ...)

2009-07-25 Thread Timothy Perrett

Hey Marius,

I read your email with interest - myself and viktor were only today
discussing all the various technologies such as this which are now flooding
the wider JEE eco-system and how lift can interoperate with them (or if
indeed we need to / should)

I think perhaps there is something wider to consider here: possibly abstract
things away so pluging lift into something other than HttpServlet is fairly
straight forward. You talk below about AsyncWeb, but it seems the same might
be true for the Grizzly NIO family of projects? Im not sure, nor am I
familiar with them in great detail but your right, there are a lot of new
options now that didn't previously exist so we should be considering them.

Today I read a preso that was suggesting servlet 3.0 wont deliver
feature-full cross-container comet support as everyone had hoped; if that's
the case, then sure, supporting other architectures would probably be a
pretty good idea :-)

Cheers, Tim


On 25/07/2009 19:06, Marius marius.dan...@gmail.com wrote:

 
 Hi,
 
 Did anyone played with AsyncWeb? .. Looks pretty promising but I
 think having Lift working properly with it we need some adaptions. For
 instance:
 
 1. Lift uses HttpServletXXX references provided by JEE containers. One
 solution that avoids vast code change is Lift is to bridge AsyncWeb
 API through our own implementation of HttpServlet, HttpServletXXX etc.
 
 2. Session management .. We'd also need a bridge for HttpSession ..
 but that should be pretty straight forward. (Fortunately we have
 LiftSession only bridged to HTTP session today.)
 
 3. Comet support. Async Web fundamental concept seems to map pretty
 well to Comet model. Probably they don't have the suspend/resume
 mechanism as Jetty but there are some other means to do it right. Need
 to look more into it ...
 
 The point is that perhaps we should expand a bit and not depend so
 much on JEE web container anymore as there are other viable
 alternatives. We just need to build a flexible and transparent wiring
 mechanism.
 
 I'll probably start looking more into this path but first I'd like to
 see your thoughts ...
 
 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] Image problems...

2009-07-25 Thread Joe Wass

I'm completely stumped. I'll give the background for the sake of
completeness but I'm not sure if it will help or not. It's more of a
Jetty problem but perhaps someone here can help.

Standard Jetty set-up running one Lift instance. Mac OS X.

I have a snippet which transforms the XML input, renders an image,
saves it to disc under the webroot/images/ directory with a filename
taken from the MD5 of the contents, such as
c5669d3eedcf7d305dcf9f88a61b3ee0.png . The snippet then returns an
img / with a reference to the generated image for inclusion in the
output.

Most of the time most of the images work. But most of the time some of
them don't, and some of the images are not rendered by the browser.
Attempting to view a problem image in the browser (Camino and Firefox)
doesn't work: the image is not displayed, suggesting that something is
vaguely wrong. Viewing it in another browser (Safari and with
QuickTime), the image works fine. When viewing the file directly with
Camino (i.e. file://...), the image shows fine (the file itself is not
corrupted). I can only assume that something goes wrong in the
transport of the image.

The URIs that do fail, fail consistently, it's not intermittent.
Restarting Jetty makes no difference, so I don't think it's that the
file was created after the server started. Also, the render is a
blocking call, so there's no chance that the file is still open /
hasn't been saved before the HTML is sent and the browser requests the
images.

The only thing I can imagine is that the MIME type is mangled, so I
put the appropriate mapping in web.xml:

mime-mapping
  extensionpng/extension
  mime-typeimage/png/mime-type
/mime-mapping

But still no cigar. The MIME type looks to be OK and I've verified
that the number of bytes is correct.

HTTP/1.1 200 OK
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=1dbeh8eq4mtu0;Path=/
Content-Type: image/png
Content-Length: 25488
Last-Modified: Sat, 25 Jul 2009 15:38:19 GMT
Server: Jetty(6.1.16)

For completeness, the headers from an image that does load fine:

HTTP/1.1 200 OK
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=15dt649lzovc4;Path=/
Content-Type: image/png
Content-Length: 18657
Last-Modified: Sat, 25 Jul 2009 15:41:35 GMT
Server: Jetty(6.1.16)


Very very puzzled about this. Any clues?

Cheers

Joe

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



[Lift] Re: Lift (AsyncWeb || ...)

2009-07-25 Thread marius d.



On Jul 25, 9:25 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 Hey Marius,

 I read your email with interest - myself and viktor were only today
 discussing all the various technologies such as this which are now flooding
 the wider JEE eco-system and how lift can interoperate with them (or if
 indeed we need to / should)

 I think perhaps there is something wider to consider here: possibly abstract
 things away so pluging lift into something other than HttpServlet is fairly
 straight forward. You talk below about AsyncWeb, but it seems the same might
 be true for the Grizzly NIO family of projects?

Most definitely ... my goal would be to be HTTP platform agnostic.
If the platform can deliver proper Comet support. AsyncWeb here is
just an example that can serve as a reference implementation.

 Im not sure, nor am I
 familiar with them in great detail but your right, there are a lot of new
 options now that didn't previously exist so we should be considering them.

 Today I read a preso that was suggesting servlet 3.0 wont deliver
 feature-full cross-container comet support as everyone had hoped; if that's
 the case, then sure, supporting other architectures would probably be a
 pretty good idea :-)

I think that supporting other non JEE architectures is important
regardless if servlet 3.0 can deliver or not their claims. Widening
Lift underlying HTTP platform would be a huge gain IMHO.


 Cheers, Tim

 On 25/07/2009 19:06, Marius marius.dan...@gmail.com wrote:



  Hi,

  Did anyone played with AsyncWeb? .. Looks pretty promising but I
  think having Lift working properly with it we need some adaptions. For
  instance:

  1. Lift uses HttpServletXXX references provided by JEE containers. One
  solution that avoids vast code change is Lift is to bridge AsyncWeb
  API through our own implementation of HttpServlet, HttpServletXXX etc.

  2. Session management .. We'd also need a bridge for HttpSession ..
  but that should be pretty straight forward. (Fortunately we have
  LiftSession only bridged to HTTP session today.)

  3. Comet support. Async Web fundamental concept seems to map pretty
  well to Comet model. Probably they don't have the suspend/resume
  mechanism as Jetty but there are some other means to do it right. Need
  to look more into it ...

  The point is that perhaps we should expand a bit and not depend so
  much on JEE web container anymore as there are other viable
  alternatives. We just need to build a flexible and transparent wiring
  mechanism.

  I'll probably start looking more into this path but first I'd like to
  see your thoughts ...

  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] Rational Behind One Callback per Form Field

2009-07-25 Thread Devon Tucker

Hi all,

I've been working with Lift for about a little while now; there are
still plenty of aspects of Lift I haven't touched yet. One thing I am
curious about at this point though is the rationale behind having one
callback per field when generating forms. Each SHtml form element
needs to be handed its own call back function. This strikes me as a
kind of cumbersome, for instance the form examples on the Wiki and in
the Exploring Lift book all follow this pattern:


someSnippet(xml: NodeSeq) = {
var fieldOne = 
var fieldTwo = 
def sumbitHandler() = { ... }

bind(prefix, xml,
fieldOne - SHtml.text(fieldOne, fieldOne = _),
fieldTwo - SHtml.text(fieldTwo, fieldTwo = _),
formSubmit - SHtml.submit(Submit, submitHandler))
}

I've seen several examples of this exact pattern at this point and it
makes the whole fieldOne = _ callback seem like needless boiler-plate.
Why not allow for just one callback function that works over some
object encapsulating an entire form? Am I missing something?

As a corollary to this question, are there other mechanisms available
in Lift for form generation/processing?

Cheers

--~--~-~--~~~---~--~~
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] url rewrite subdomain?

2009-07-25 Thread JanWillem Tulp

Hi all,

most examples I have seen about Lift URL rewriting are about the path
of the URL, the part that comes after the hostname (and port). But is
it also possible to do URL rewriting on subdomains?

For instance, can I rewrite a URL where the account name is used as a
subdomain, something like: http://myaccount.example.com so that it
maps to something similar to http://www.example.com?account=myaccount

And is URL rewriting for subdomains always possible, or are there some
prerequisities from a hosting company or something?

Thanks!

JanWillem Tulp

--~--~-~--~~~---~--~~
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] log4j problems with Jetty

2009-07-25 Thread Jeppe Nejsum Madsen

Hi,

I'm trying to use the jetty plugin for gradle (a Groovy build tool ala
buildr) and I'm getting the following error when loading the Lift app:

3:52:11.276 [main] ERROR org.mortbay.log - failed LiftFilter
java.lang.IllegalAccessError: tried to access method 
org.apache.log4j.Logger.init(Ljava/lang/String;)V from class 
org.apache.log4j.spi.RootLogger
at org.apache.log4j.spi.RootLogger.init(RootLogger.java:43)
at org.apache.log4j.LogManager.clinit(LogManager.java:78)
at net.liftweb.util.LogBoot$.log4jIsConfigured$1(Log.scala:113)
at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:129)

I assume there are some logging conflicts somewhere, but can't seem to
figure out where. Any clues to what the issue is?

This is the classpath used:

23:52:08.786 [main] DEBUG org.mortbay.log - 
webapp=file:/Users/jeppe//build/jetty/webapp/
23:52:08.787 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/classes/
23:52:08.788 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/activation-1.1.jar
23:52:08.788 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/avalon-framework-4.1.3.jar
23:52:08.789 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-codec-1.3.jar
23:52:08.789 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-collections-3.2.1.jar
23:52:08.789 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-fileupload-1.2.1.jar
23:52:08.789 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-httpclient-3.1.jar
23:52:08.790 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/commons-logging-1.1.jar
23:52:08.790 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/dom4j-1.6.1.jar
23:52:08.790 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-actor-1.1-SNAPSHOT.jar
23:52:08.790 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-mapper-1.1-SNAPSHOT.jar
23:52:08.791 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-util-1.1-SNAPSHOT.jar
23:52:08.792 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-webkit-1.1-SNAPSHOT.jar
23:52:08.793 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/lift-widgets-1.1-SNAPSHOT.jar
23:52:08.793 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/log4j-1.2.14.jar
23:52:08.793 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/logkit-1.0.1.jar
23:52:08.794 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/mail-1.4.jar
23:52:08.794 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/ooxml-schemas-1.0.jar
23:52:08.808 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/poi-3.5-beta6.jar
23:52:08.808 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/poi-ooxml-3.5-beta6.jar
23:52:08.824 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/postgresql-8.3-603.jdbc4.jar
23:52:08.824 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/scala-compiler-2.7.5.jar
23:52:08.824 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/scala-library-2.7.5.jar
23:52:08.824 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/stax-api-1.0.1.jar
23:52:08.824 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/xml-apis-1.0.b2.jar
23:52:08.825 [main] DEBUG org.mortbay.log - Path 
resource=file:/Users/jeppe//build/jetty/webapp/WEB-INF/lib/xmlbeans-2.3.0.jar

/Jeppe


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

2009-07-25 Thread Kev

I was working through the ToDo example on the web
http://liftweb.net/docs/getting_started/mod_master.html#x1-12.4

but when I add the ToDo to the line
 Schemifier.schemify(true, Log.infoF _, User, ToDo)

I get file not found exceptions at compile time, have I missed a step?
the import is correct and my todo clas is in the correct location.

Hopefully it's late and I have missed some thing...
thanks,

Kevin

--~--~-~--~~~---~--~~
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] erro: MappedDouble is not mapped to 'double precision' datatype in PostgreSQL?

2009-07-25 Thread JanWillem Tulp

Hi all,

I'm not sure that I am missing something here, but the Schemifier
cannot create a table for a model class that contains an object that
extends from MappedDouble.

This is the Lift code:

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

  object value extends MappedDouble(this)
  object measure extends MappedLongForeignKey(this, Measure)
}

object MeasureValue extends MeasureValue with LongKeyedMetaMapper
[MeasureValue]

I added MeasureValue to the Schemifier so that it will create a table
when boot is executed. However, this is the stacktrace I get when I
start the application:

main INFO  lift - CREATE TABLE measurevalue (measure BIGINT , value
DOUBLE , id BIGSERIAL)
main ERROR lift - Failed to Boot
org.postgresql.util.PSQLException: ERROR: type double does not exist
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse
(QueryExecutorImpl.java:1592)
at org.postgresql.core.v3.QueryExecutorImpl.processResults
(QueryExecutorImpl.java:1327)
at org.postgresql.core.v3.QueryExecutorImpl.execute
(QueryExecutorImpl.java:192)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute
(AbstractJdbc2Statement.java:451)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags
(AbstractJdbc2Statement.java:336)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute
(AbstractJdbc2Statement.java:328)
at net.liftweb.mapper.Schemifier$.net$liftweb$mapper$Schemifier$
$maybeWrite(Schemifier.scala:150)
at net.liftweb.mapper.Schemifier$.net$liftweb$mapper$Schemifier$
$ensureTable(Schemifier.scala:160)
at net.liftweb.mapper.Schemifier$$anonfun$schemify$1$$anonfun$1.apply
(Schemifier.scala:60)
at net.liftweb.mapper.Schemifier$$anonfun$schemify$1$$anonfun$1.apply
(Schemifier.scala:60)
at scala.List.foldLeft(List.scala:1066)
at net.liftweb.mapper.Schemifier$$anonfun$schemify$1.apply
(Schemifier.scala:60)
at net.liftweb.mapper.Schemifier$$anonfun$schemify$1.apply
(Schemifier.scala:54)
at net.liftweb.mapper.DB$.use(DB.scala:305)
at net.liftweb.mapper.Schemifier$.schemify(Schemifier.scala:53)
at net.liftweb.mapper.Schemifier$.schemify(Schemifier.scala:36)
at bootstrap.liftweb.Boot.boot(Boot.scala:26)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at net.liftweb.util.ClassHelpers$$anonfun$createInvoker$1.apply
(ClassHelpers.scala:392)
at net.liftweb.util.ClassHelpers$$anonfun$createInvoker$1.apply
(ClassHelpers.scala:390)
at net.liftweb.http.DefaultBootstrap$$anonfun$boot$1.apply
(LiftRules.scala:909)
at net.liftweb.http.DefaultBootstrap$$anonfun$boot$1.apply
(LiftRules.scala:909)
at net.liftweb.util.Full.map(Box.scala:330)
at net.liftweb.http.DefaultBootstrap$.boot(LiftRules.scala:909)
at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:573)
at net.liftweb.http.LiftFilter.init(LiftServlet.scala:548)
at org.apache.catalina.core.ApplicationFilterConfig.getFilter
(ApplicationFilterConfig.java:275)
at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef
(ApplicationFilterConfig.java:397)
at org.apache.catalina.core.ApplicationFilterConfig.init
(ApplicationFilterConfig.java:108)
at org.apache.catalina.core.StandardContext.filterStart
(StandardContext.java:3800)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:4450)
at org.apache.catalina.core.ContainerBase.addChildInternal
(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:
771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:
526)
at org.apache.catalina.startup.HostConfig.deployDirectory
(HostConfig.java:987)
at org.apache.catalina.startup.HostConfig.deployDirectories
(HostConfig.java:909)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:
495)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206)
at org.apache.catalina.startup.HostConfig.lifecycleEvent
(HostConfig.java:314)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:
1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:
443)
at org.apache.catalina.core.StandardService.start
(StandardService.java:516)
at 

[Lift] Re: ToDo example

2009-07-25 Thread Wilson MacGyver

btw, when I said stupid questions, I was talking about the questions
I was about to ask, not yours. :) I wrote it real fast and realized it
could be taken the wrong way. :)

On Sat, Jul 25, 2009 at 10:09 PM, Kevgriffin@gmail.com wrote:

 I was working through the ToDo example on the web
 http://liftweb.net/docs/getting_started/mod_master.html#x1-12.4

 but when I add the ToDo to the line
  Schemifier.schemify(true, Log.infoF _, User, ToDo)

 I get file not found exceptions at compile time, have I missed a step?
 the import is correct and my todo clas is in the correct location.

 Hopefully it's late and I have missed some thing...
 thanks,

 Kevin

 




-- 
Omnem crede diem tibi diluxisse supremum.

--~--~-~--~~~---~--~~
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: Rational Behind One Callback per Form Field

2009-07-25 Thread Kris Nuttycombe

On Sat, Jul 25, 2009 at 3:18 PM, Devon Tuckerdevonrtuc...@gmail.com wrote:

 Hi all,

 I've been working with Lift for about a little while now; there are
 still plenty of aspects of Lift I haven't touched yet. One thing I am
 curious about at this point though is the rationale behind having one
 callback per field when generating forms. Each SHtml form element
 needs to be handed its own call back function. This strikes me as a
 kind of cumbersome, for instance the form examples on the Wiki and in
 the Exploring Lift book all follow this pattern:

 someSnippet(xml: NodeSeq) = {
    var fieldOne = 
    var fieldTwo = 
    def sumbitHandler() = { ... }

    bind(prefix, xml,
        fieldOne - SHtml.text(fieldOne, fieldOne = _),
        fieldTwo - SHtml.text(fieldTwo, fieldTwo = _),
        formSubmit - SHtml.submit(Submit, submitHandler))
 }

 I've seen several examples of this exact pattern at this point and it
 makes the whole fieldOne = _ callback seem like needless boiler-plate.
 Why not allow for just one callback function that works over some
 object encapsulating an entire form? Am I missing something?

This is a pretty interesting question; I've sometimes wondered whether
the use of bare closures for this purpose isn't a bit too close to the
metal. It would be possible to do something like what you describe,
but the binding of each form element would still have to have some
reference to the variable being set. Now this could conceivably be
achieved in a few different ways:

You could have each bound variable, instead of being a regular Scala
variable, be an object extending some trait that the SHtml field
builders know about. This would mean that you'd just pass references
to those objects to the field builders, and they'd be automatically
mutated with the form field value on submit. The amount of boilerplate
-- maybe something like object fieldOne extends StringField -- would
be similar to what you get from the current situation. The one thing I
like about this is that the state of such a field could be tracked a
bit better; in the past I've found myself with a lot of code like the
following:

var fieldOne: Option[MyObject] = None
val options: Seq[(MyObject, String)] = ...

bind(prefix, xml,
   myselect - SHtml.selectObj(options, Empty, a = fieldOne = Some(a))

just to avoid mucking about with nulls, and this definitely gets laden
with boilerplate when you have a bunch of fields, particularly in the
handler function.

You could have the SHtml field builders return some sort of object
apart from an XML node, store that in a local val, and then have your
form-level callback refer to that value. This seems like an attractive
possibility to me because it could eliminate the need for mutable
variables entirely; the resulting objects could dynamically obtain
their submitted values from the Req when referenced by the callback
function.

Neither of these approaches exist yet, but you could build either one
of them atop the current framework, which I think is sort of one of
the main points of Lift at this stage in its development - it gives
you the most powerful tools it can, and one can build higher-level
abstractions atop what it provides.

Kris

--~--~-~--~~~---~--~~
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: Rational Behind One Callback per Form Field

2009-07-25 Thread Naftoli Gugenheim

I hope to commit in the next few days code that makes a couple of similar asks 
easier BH.
But, to put the ball in your court, how exactly do you want your code to look? 
If you write a complete sample usage I'll see what I can do to implement such 
functionality.
Also, Kris, could you elaborate on how the first way would help track values 
and how it would make the option case easier, and explain the second way better?
Thanks.


-
Kris Nuttycombekris.nuttyco...@gmail.com wrote:


On Sat, Jul 25, 2009 at 3:18 PM, Devon Tuckerdevonrtuc...@gmail.com wrote:

 Hi all,

 I've been working with Lift for about a little while now; there are
 still plenty of aspects of Lift I haven't touched yet. One thing I am
 curious about at this point though is the rationale behind having one
 callback per field when generating forms. Each SHtml form element
 needs to be handed its own call back function. This strikes me as a
 kind of cumbersome, for instance the form examples on the Wiki and in
 the Exploring Lift book all follow this pattern:

 someSnippet(xml: NodeSeq) = {
    var fieldOne = 
    var fieldTwo = 
    def sumbitHandler() = { ... }

    bind(prefix, xml,
        fieldOne - SHtml.text(fieldOne, fieldOne = _),
        fieldTwo - SHtml.text(fieldTwo, fieldTwo = _),
        formSubmit - SHtml.submit(Submit, submitHandler))
 }

 I've seen several examples of this exact pattern at this point and it
 makes the whole fieldOne = _ callback seem like needless boiler-plate.
 Why not allow for just one callback function that works over some
 object encapsulating an entire form? Am I missing something?

This is a pretty interesting question; I've sometimes wondered whether
the use of bare closures for this purpose isn't a bit too close to the
metal. It would be possible to do something like what you describe,
but the binding of each form element would still have to have some
reference to the variable being set. Now this could conceivably be
achieved in a few different ways:

You could have each bound variable, instead of being a regular Scala
variable, be an object extending some trait that the SHtml field
builders know about. This would mean that you'd just pass references
to those objects to the field builders, and they'd be automatically
mutated with the form field value on submit. The amount of boilerplate
-- maybe something like object fieldOne extends StringField -- would
be similar to what you get from the current situation. The one thing I
like about this is that the state of such a field could be tracked a
bit better; in the past I've found myself with a lot of code like the
following:

var fieldOne: Option[MyObject] = None
val options: Seq[(MyObject, String)] = ...

bind(prefix, xml,
   myselect - SHtml.selectObj(options, Empty, a = fieldOne = Some(a))

just to avoid mucking about with nulls, and this definitely gets laden
with boilerplate when you have a bunch of fields, particularly in the
handler function.

You could have the SHtml field builders return some sort of object
apart from an XML node, store that in a local val, and then have your
form-level callback refer to that value. This seems like an attractive
possibility to me because it could eliminate the need for mutable
variables entirely; the resulting objects could dynamically obtain
their submitted values from the Req when referenced by the callback
function.

Neither of these approaches exist yet, but you could build either one
of them atop the current framework, which I think is sort of one of
the main points of Lift at this stage in its development - it gives
you the most powerful tools it can, and one can build higher-level
abstractions atop what it provides.

Kris



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