[Lift] Re: Timestamps, Mapper, and MySQL

2009-07-18 Thread Peter Robinett

Glad to hear there's interest.

However, G-Man, why do you need the browser to include a timestamp?
You can make a timestamp in your Lift code that responses to the
request. If you want to do conditional HTTP requests then you should
consider using the If-Modified-Since and If-None-Match headers.

Peter

On Jul 17, 9:02 pm, g-man gregor...@gmail.com wrote:
 I, too, want to get a better grip on managment of dates and times, and
 for me the first step is to record everything as a UTC instance in my
 DB (MySQL).

 What I need to do is to have a way to make the client browser include
 a 'Date' HTTP Header in every request. From that, I can get the
 timezone and set a SessionVar to use in translating the particular
 data back to the correct timezone in the response.

 As it is now, it looks like only:

 GET /ajax_request/liftAjax.js HTTP/1.1
 Host:
 User-Agent:
 Accept:
 Accept-Language:
 Accept-Encoding:
 Accept-Charset:
 Keep-Alive:
 Connection:
 Referer:
 Cookie:

 are sent over.

 Lift and Scala are fun!

 On Jul 15, 12:30 pm, Peter Robinett pe...@bubblefoundry.com wrote:

  As others have encountered before[1], MappedDateTime has some
  limitations. Unlike others I'm not losing my time information: in my
  MySQL database correct datetimes are stored. However, the datetimes
  are in my local timezone, not GMT. I could change the MySQL timezone
  but I'd rather not rely on that.

  Given this and because I would like to store millisecond timestamps
  and MySQL's native timestamp column type only stores timestamps to the
  second, I figure using an unsigned BIGINT would be best. Assuming that
  is a reasonable decision (please tell me if you think it isn't), what
  is the best way to map to this database column?

  One solution I see is to just use a MappedLong. However, then I would
  have to manually convert to and from usable Dates and so on. I see
  that Joda Time is a popular replacement for java.util.Date but I don't
  know how to beginning using it as a MappedField. Could someone advise
  me?

  Finally, given the common need for timestamp fields, would it make
  sense to create a MappedTimestamp MappedField? If so, how would I go
  about doing this? As you can tell, I am quite new to Lift and Scala
  but this would be a good way to improve my knowledge and to contribute
  to Lift.

  What do you think? I look forward to your thoughts!

  Peter Robinett

  [1]:http://groups.google.com/group/liftweb/browse_thread/thread/a3755d82f...
--~--~-~--~~~---~--~~
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: Snippets creating snippets with embedded 'attributes'

2009-07-18 Thread Jonathan Meeks

Thanks for the tips, Naftoli and David.

On Jul 17, 10:46 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Fri, Jul 17, 2009 at 7:30 AM, Jonathan Meeks 
 jonathanme...@gmail.comwrote:



  I don't see how it would help. How would the SHtml.hidden callback,
  presumably defined deleteFileForm snippet method, know the filename?
  That value somehow needs to be passed from the fileManager method to
  the deleteFileForm.

  I was hoping that the a snippet tag could take attributes where I
  could pass this data through, instead of writing the hidden input
  explicitly.

 def fileManager(xhtml : NodeSeq) : NodeSeq = {
    table
    {
      for(file - fileList(folderName))
        yield
          tr
            td{file.getName}/td
            td
              lift:form.post
                 {s.submit(delete, () = doFileDelete(file.getName))}
              /lift:form.post
            /td
          /tr
    }
    /table
  }

 No need to do more.  The current value of the file instance will be
 preserved on the callback.





  On Jul 17, 12:38 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
   Why don't you use a SHtml.hidden with a callback?

   -

   Jonathan Meeksjonathanme...@gmail.com wrote:

   I have a snippet (call it the file manager snippet) that creates a
   list of snippet tags (each called file deletion snippets) to create
   a virtual file listing with a deletion form next to each of the file
   names.

   These file deletion snippet methods need to somehow know their
   corresponding file names so that the submit binding can delete the
   correct file.

   I accomplished it with something like the code at the bottom of this
   message.

   The general solution was to create the file deletion snippet tags
   with a hidden input that contains the file name. The file deletion
   snippet method, in turn, extracts the value out of the NodeSeq.

   It works but seems inelegant. Is there a preferred method to do this?
   Any feedback is welcome.

   Regards,

   Jonathan

   def fileManager(xhtml : NodeSeq) : NodeSeq = {
       table
       {
         for(file - fileList(folderName))
           yield
             tr
               td{file.getName}/td
               td
                 lift:filesystem.deleteFileForm form=POST
                   input type=hidden name={fileKeyHiddenFieldName}
   value={file.getName}/
                   deleteFile:submit/
                 /lift:filesystem.deleteFileForm
               /td
             /tr
       }
       /table
     }

   def extractHiddenInputValue(name: String, xhtml: NodeSeq) : String = {
       (xhtml \\ input).filter(_ \ @type == hidden).filter(_ \
   @value != ).find(_ \ @name == name) match {
         case Some(node) = (node \ @value).toString
         case _ = null
       }
     }

   def deleteFileForm(xhtml : NodeSeq) : NodeSeq = {
       def deleteFile() = {
         val fileToDelete = extractHiddenInputValue
   (fileKeyHiddenFieldName, xhtml)
   ...
       }

       bind(deleteFile, xhtml,
         submit - SHtml.submit (delete, deleteFile))
     }

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://www.apress.com/book/view/1430219890
 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: JTA Transaction Monad - Early Access Program

2009-07-18 Thread Jonas Bonér

JTA stuff is in github master branch now.
http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc127933c/lift-jta

Have fun.
/Jonas

2009/7/17 David Pollak feeder.of.the.be...@gmail.com:


 On Fri, Jul 17, 2009 at 1:02 AM, Jonas Bonér jbo...@gmail.com wrote:

 Hi Greg.

 Have you had time to look at the JTA stuff?
 Should I merge in master?

 Please merge into Master.  We've got 6-8 weeks until with have the 1.1
 release code slush... and if stuff is in the Maven repo, it'll get used.


 /Jonas

 2009/7/7 Jonas Bonér jbo...@gmail.com:
  Thanks Tim. Thanks for staying on top of it. Derek has already looked
  at it and seemed to like it. But I'll wait until I get Greg's
  feedback.
 
  2009/7/7 Timothy Perrett timo...@getintheloop.eu:
 
 
  Hey Jonas,
 
  I have no real use case to test it out - I was just interested in its
  status
  as conceptually it was very very clever and wondered where you were too
  with
  it. I think Greg or Derek are most likely to be able to give you
  valuable
  feedback as I believe they are using JTA already.
 
  Cheers, Tim
 
  On 07/07/2009 18:18, Jonas Bonér jbo...@gmail.com wrote:
 
 
  No I haven't. Should I? Is everyone happy with it?
  Have anyone tried it? Is anyone using it?
 
  2009/6/30 Timothy Perrett timo...@getintheloop.eu:
 
  Jonas,
 
  Did you roll this into master? What's its status?
 
  Cheers, Tim
 
  On Jun 10, 4:46 pm, James Strachan james.strac...@gmail.com wrote:
  2009/6/9 Jonas Bonér jbo...@gmail.com:
 
 
 
  2009/6/9 David Pollak feeder.of.the.be...@gmail.com:
  Jonas,
  We always use Maven to load dependencies.  We never use GPL
  dependencies.
   If you have a question about the license of a dependency and its
  use in
  Lift, please ping me privately.
 
  I am using Maven. But as I said I could not find the Atomikos in
  any
  public library, putting them in lib will let the user easily
  install
  them in their local repo.
  Do you know if they are in any public repo?
 
  If its any help I added them here a while back for an integration
  test
  in ActiveMQhttp://repo.fusesource.com/maven2-all/com/atomikos/
 
  the repo is:http://repo.fusesource.com/maven2-all/
 
  you might wanna put more recent jars up on some public repo though.
 
  --
  James
  ---http://macstrac.blogspot.com/
 
  Open Source Integrationhttp://fusesource.com/
 
 
 
 
 
 
 
  
 
 
 
 
  --
  Jonas Bonér
 
  twitter: @jboner
  blog:    http://jonasboner.com
  work:   http://crisp.se
  work:   http://scalablesolutions.se
  code:   http://github.com/jboner
 



 --
 Jonas Bonér

 twitter: @jboner
 blog:    http://jonasboner.com
 work:   http://crisp.se
 work:   http://scalablesolutions.se
 code:   http://github.com/jboner





 --
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Git some: http://github.com/dpp

 




-- 
Jonas Bonér

twitter: @jboner
blog:http://jonasboner.com
work:   http://crisp.se
work:   http://scalablesolutions.se
code:   http://github.com/jboner

--~--~-~--~~~---~--~~
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] File upload streaming and progress monitoring ...

2009-07-18 Thread Marius

HI there,

I know, there have been several other threads around the topic but I
just wanted to yield somethings here. In the past few days I've been
talking with Tim as he was having problems with his FileUpload widget.
Even with short polling the progress was not reported even though the
LiftSession.progressListener was properly called.

Today I started to look into it and here is what I've done:

1. Here is the markup:

  iframe id=upload_target name=upload_target src=# style=width:
0;height:0;border:0px solid #fff;/iframe

  lift:Upload.render form=POST multipart=true id=upload_form
target=upload_target
f:inputFile/
input type=submit value=Upload/
  /lift:Upload.render

  A simple snippet that uses the invisible iframe trick to upload
stuff in the background. The so called Ajax upload. (I had to add
the target attribute into the supported form snippet attributed but
that's ok)

2. In boot had something like:

LiftSession.onSetupSession = ((session: LiftSession) = {
  session.progessListener = Full((chunk, total, index) = {
 Thread.sleep(100)
 println(index +  read  + chunk +  out of  + total +   +
Thread.currentThread)
  })
}) :: Nil

Just monitor the progress ... and to make it last a little longer
I'm sleeping for 100 milliseconds

3. I set the GC polling to 10 seconds. The think is that GC polling
would be just like the short polling for getting the progress status
back in the browser.

The behavior that I observed was that while I was uploading a 30 Mb +
file the polling requests timed out after 5 secconds per
LiftRules.ajaxPostTimeout. This means that our progress monitoring
ajax request would have timed out as well. On the server side the
execution got stuck until the upload was complete.
LiftServlet.handleAjax was not called until the upload terminates.

Initially I thought that this has to do to limited request channels
that browser have but the thing is that we have several places in Lift
code where we synchronize things. Such as LiftSession.getSession,
LiftSession.fixSessionTime etc. Acquiring these locks made the
progress polling to hang until the upload terminated. Of course
removing th synchronized block made the polling to work right during
the file upload. Now this was just for test ... I'm not suggesting to
remove the synchronized blocks as  we'd loose consistency but this
looks to stay in the way of properly dealing with multiple parallel
request per same session like fileupload and progress monitoring.

It appears that there is either a thread starvation situation or
simply a lock that is held while upload is is progress.


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: File upload streaming and progress monitoring ...

2009-07-18 Thread marius d.

A little more on this ...

Living the above synchronized blocks where they are but removing the
one from LiftSession.runParams  made it work properly. Looks like this
one was holding the lock while the file upload progress was happening.
Dave I'm not really sure why in runParams the the toRun is obtained
from a synchronized block ... is it because we'rreading from
messageCallback there ? ..cause otherwise the entire expression is
about functions composition that does not change any state.


Br's,
Marius

On Jul 18, 3:57 pm, Marius marius.dan...@gmail.com wrote:
 HI there,

 I know, there have been several other threads around the topic but I
 just wanted to yield somethings here. In the past few days I've been
 talking with Tim as he was having problems with his FileUpload widget.
 Even with short polling the progress was not reported even though the
 LiftSession.progressListener was properly called.

 Today I started to look into it and here is what I've done:

 1. Here is the markup:

   iframe id=upload_target name=upload_target src=# style=width:
 0;height:0;border:0px solid #fff;/iframe

   lift:Upload.render form=POST multipart=true id=upload_form
 target=upload_target
     f:inputFile/
     input type=submit value=Upload/
   /lift:Upload.render

   A simple snippet that uses the invisible iframe trick to upload
 stuff in the background. The so called Ajax upload. (I had to add
 the target attribute into the supported form snippet attributed but
 that's ok)

 2. In boot had something like:

     LiftSession.onSetupSession = ((session: LiftSession) = {
       session.progessListener = Full((chunk, total, index) = {
          Thread.sleep(100)
          println(index +  read  + chunk +  out of  + total +   +
 Thread.currentThread)
       })
     }) :: Nil

     Just monitor the progress ... and to make it last a little longer
 I'm sleeping for 100 milliseconds

 3. I set the GC polling to 10 seconds. The think is that GC polling
 would be just like the short polling for getting the progress status
 back in the browser.

 The behavior that I observed was that while I was uploading a 30 Mb +
 file the polling requests timed out after 5 secconds per
 LiftRules.ajaxPostTimeout. This means that our progress monitoring
 ajax request would have timed out as well. On the server side the
 execution got stuck until the upload was complete.
 LiftServlet.handleAjax was not called until the upload terminates.

 Initially I thought that this has to do to limited request channels
 that browser have but the thing is that we have several places in Lift
 code where we synchronize things. Such as LiftSession.getSession,
 LiftSession.fixSessionTime etc. Acquiring these locks made the
 progress polling to hang until the upload terminated. Of course
 removing th synchronized block made the polling to work right during
 the file upload. Now this was just for test ... I'm not suggesting to
 remove the synchronized blocks as  we'd loose consistency but this
 looks to stay in the way of properly dealing with multiple parallel
 request per same session like fileupload and progress monitoring.

 It appears that there is either a thread starvation situation or
 simply a lock that is held while upload is is progress.

 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: File upload streaming and progress monitoring ...

2009-07-18 Thread marius d.

Just committed a fix ...

Br's,
Marius

On Jul 18, 4:10 pm, marius d. marius.dan...@gmail.com wrote:
 A little more on this ...

 Living the above synchronized blocks where they are but removing the
 one from LiftSession.runParams  made it work properly. Looks like this
 one was holding the lock while the file upload progress was happening.
 Dave I'm not really sure why in runParams the the toRun is obtained
 from a synchronized block ... is it because we'rreading from
 messageCallback there ? ..cause otherwise the entire expression is
 about functions composition that does not change any state.

 Br's,
 Marius

 On Jul 18, 3:57 pm, Marius marius.dan...@gmail.com wrote:

  HI there,

  I know, there have been several other threads around the topic but I
  just wanted to yield somethings here. In the past few days I've been
  talking with Tim as he was having problems with his FileUpload widget.
  Even with short polling the progress was not reported even though the
  LiftSession.progressListener was properly called.

  Today I started to look into it and here is what I've done:

  1. Here is the markup:

    iframe id=upload_target name=upload_target src=# style=width:
  0;height:0;border:0px solid #fff;/iframe

    lift:Upload.render form=POST multipart=true id=upload_form
  target=upload_target
      f:inputFile/
      input type=submit value=Upload/
    /lift:Upload.render

    A simple snippet that uses the invisible iframe trick to upload
  stuff in the background. The so called Ajax upload. (I had to add
  the target attribute into the supported form snippet attributed but
  that's ok)

  2. In boot had something like:

      LiftSession.onSetupSession = ((session: LiftSession) = {
        session.progessListener = Full((chunk, total, index) = {
           Thread.sleep(100)
           println(index +  read  + chunk +  out of  + total +   +
  Thread.currentThread)
        })
      }) :: Nil

      Just monitor the progress ... and to make it last a little longer
  I'm sleeping for 100 milliseconds

  3. I set the GC polling to 10 seconds. The think is that GC polling
  would be just like the short polling for getting the progress status
  back in the browser.

  The behavior that I observed was that while I was uploading a 30 Mb +
  file the polling requests timed out after 5 secconds per
  LiftRules.ajaxPostTimeout. This means that our progress monitoring
  ajax request would have timed out as well. On the server side the
  execution got stuck until the upload was complete.
  LiftServlet.handleAjax was not called until the upload terminates.

  Initially I thought that this has to do to limited request channels
  that browser have but the thing is that we have several places in Lift
  code where we synchronize things. Such as LiftSession.getSession,
  LiftSession.fixSessionTime etc. Acquiring these locks made the
  progress polling to hang until the upload terminated. Of course
  removing th synchronized block made the polling to work right during
  the file upload. Now this was just for test ... I'm not suggesting to
  remove the synchronized blocks as  we'd loose consistency but this
  looks to stay in the way of properly dealing with multiple parallel
  request per same session like fileupload and progress monitoring.

  It appears that there is either a thread starvation situation or
  simply a lock that is held while upload is is progress.

  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: JTA Transaction Monad - Early Access Program

2009-07-18 Thread Timothy Perrett

Awesome - kudos Jonas.

Cheers, Tim

On Jul 18, 11:53 am, Jonas Bonér jbo...@gmail.com wrote:
 JTA stuff is in github master branch 
 now.http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc1...

 Have fun.
 /Jonas

--~--~-~--~~~---~--~~
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: File upload streaming and progress monitoring ...

2009-07-18 Thread Timothy Perrett

Marius,

This is awesome. Things are now working as expected - I knew this
wasn't a browser connection issue causing the problems.

The code in the widget package is pretty rubbish right now, but i just
had time to hack together a hardcoded sample to make sure that your
commit actually fix the problem... Im happy to report that it does
indeed now work exactly as required.

The next step is to work backwards and clean all the code up and fix
the cross-browser issues as right now it works in firefox and IE but
not in safari or chrome et al.

Cheers, Tim

On Jul 18, 3:08 pm, marius d. marius.dan...@gmail.com wrote:
 Just committed a fix ...

 Br's,
 Marius

 On Jul 18, 4:10 pm, marius d. marius.dan...@gmail.com wrote:



  A little more on this ...

  Living the above synchronized blocks where they are but removing the
  one from LiftSession.runParams  made it work properly. Looks like this
  one was holding the lock while the file upload progress was happening.
  Dave I'm not really sure why in runParams the the toRun is obtained
  from a synchronized block ... is it because we'rreading from
  messageCallback there ? ..cause otherwise the entire expression is
  about functions composition that does not change any state.

  Br's,
  Marius

  On Jul 18, 3:57 pm, Marius marius.dan...@gmail.com wrote:

   HI there,

   I know, there have been several other threads around the topic but I
   just wanted to yield somethings here. In the past few days I've been
   talking with Tim as he was having problems with his FileUpload widget.
   Even with short polling the progress was not reported even though the
   LiftSession.progressListener was properly called.

   Today I started to look into it and here is what I've done:

   1. Here is the markup:

     iframe id=upload_target name=upload_target src=# style=width:
   0;height:0;border:0px solid #fff;/iframe

     lift:Upload.render form=POST multipart=true id=upload_form
   target=upload_target
       f:inputFile/
       input type=submit value=Upload/
     /lift:Upload.render

     A simple snippet that uses the invisible iframe trick to upload
   stuff in the background. The so called Ajax upload. (I had to add
   the target attribute into the supported form snippet attributed but
   that's ok)

   2. In boot had something like:

       LiftSession.onSetupSession = ((session: LiftSession) = {
         session.progessListener = Full((chunk, total, index) = {
            Thread.sleep(100)
            println(index +  read  + chunk +  out of  + total +   +
   Thread.currentThread)
         })
       }) :: Nil

       Just monitor the progress ... and to make it last a little longer
   I'm sleeping for 100 milliseconds

   3. I set the GC polling to 10 seconds. The think is that GC polling
   would be just like the short polling for getting the progress status
   back in the browser.

   The behavior that I observed was that while I was uploading a 30 Mb +
   file the polling requests timed out after 5 secconds per
   LiftRules.ajaxPostTimeout. This means that our progress monitoring
   ajax request would have timed out as well. On the server side the
   execution got stuck until the upload was complete.
   LiftServlet.handleAjax was not called until the upload terminates.

   Initially I thought that this has to do to limited request channels
   that browser have but the thing is that we have several places in Lift
   code where we synchronize things. Such as LiftSession.getSession,
   LiftSession.fixSessionTime etc. Acquiring these locks made the
   progress polling to hang until the upload terminated. Of course
   removing th synchronized block made the polling to work right during
   the file upload. Now this was just for test ... I'm not suggesting to
   remove the synchronized blocks as  we'd loose consistency but this
   looks to stay in the way of properly dealing with multiple parallel
   request per same session like fileupload and progress monitoring.

   It appears that there is either a thread starvation situation or
   simply a lock that is held while upload is is progress.

   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: Jersey + Lift, whats the story?

2009-07-18 Thread Timothy Perrett

Greg, once again your musing are generally over my head but I follow
your thoughts conceptually here.

Sounds like your saying Jersey wasnt the best fit with lift from a
functional perspective and you want to create something more monadic
based  on the zipper pattern?

Like i said, Jersey is not part of my usual tool chain so im not
really familiar with it full stop - let alone what value it adds to
lift as from my perspective the templating system in lift by default
is pretty sweet

Cheers, Tim

On Jul 17, 6:54 pm, Meredith Gregory lgreg.mered...@gmail.com wrote:
 Guys,

 After playing around with integrating Lift and Jersey before the Jersey guys
 did an 'official' integration and thinking hard about how i wanted to
 reference locations in data structures via URLs, i realized that
 zipperhttp://en.wikipedia.org/wiki/Zipper_%28data_structure%29(cf.
 this
 explanation http://www.haskell.org/haskellwiki/Zipper) is a much better,
 much more functional, generic and maintainable solution.

 Briefly, the way this works is to automate the calculation of a context
 type, C(T), from a data type T. The context type will allow for the
 representation of locations in an instance of T in terms of contexts and
 holes. There's a natural way to get from contexts to paths. So, there's a
 natural map from URLs (viewed as paths) to locations. One great example of
 how this works in practice is Oleg Kiselyov's Zipper-based file system. The
 analogy between paths to files and URLs to resources should be clear.

 This has led me to look at where to cut the line on calculating zippers. As
 the wikipedia article mentions above, it is possible do this completely
 generically, provided one has a notion of differentiation on data
 structures; that is, the zipper can be expressed in terms of the derivative
 of a data structure. There are two natural (and somewhat competing) places
 to hang the differentiation calculation:

    - the new collections library for scala
    - the target of a mapping from one of the XML schema proposals to scala
    types

 Jorge and i were chatting about this the other day. Either route is a bit of
 a large task and i've got a bunch of other stuff on my plate right now.
 However, i'd be very happy to collaborate with anyone who wants to make this
 happen. Also, by the way, this works really well with a lot of other
 monadically based machinery.

 Best wishes,

 --greg





 On Fri, Jul 17, 2009 at 8:17 AM, TylerWeir tyler.w...@gmail.com wrote:

  Wait a few days, and I think there'll be some very good news on this
  front.

  Tease! :)

  On Jul 17, 10:51 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
   There are benefits to both approaches.  I prefer the partial function
   composition, but annotations on Pojos have their place.
   Wait a few days, and I think there'll be some very good news on this
  front.

   On Fri, Jul 17, 2009 at 7:28 AM, Timothy Perrett timo...@getintheloop.eu
  wrote:

Hey guys,

I've been taking a look at Jersey and how it operates with Lift by way
of the recent integration that cropped up on dev.java.net...

From my perspective, I see how having a standard RS service framework
could be helpful, but it appears to bypass important lift concepts
like SiteMap etc so I'm just wondering what the benefit of using such
a layer would be over using DispatchPF etc to create REST services or
serving xml fragments for templates? (I have no idea about Jersey
apart from the basic docs ive read, so if im missing a major benefit
id love to hear discuss)

Cheers for any thoughts

Tim

   --
   Lift, the simply functional web frameworkhttp://liftweb.net
   Beginning Scalahttp://www.apress.com/book/view/1430219890
   Follow me:http://twitter.com/dpp
   Git some:http://github.com/dpp

 --
 L.G. Meredith
 Managing Partner
 Biosimilarity LLC
 1219 NW 83rd St
 Seattle, WA 98117

 +1 206.650.3740

 http://biosimilarity.blogspot.com
--~--~-~--~~~---~--~~
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: Wiki Articles

2009-07-18 Thread Timothy Perrett

Hey Alex,

 - Templating
   * Snippets etc.

You might want to checkout my article here: http://is.gd/sfyT

As for the rest of your list, I agree these need documenting in fair
detail. I can certainly contribute from a localization and REST
perspective - i'll try and crank something out onto my blog.

Cheers, Tim
--~--~-~--~~~---~--~~
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: File upload streaming and progress monitoring ...

2009-07-18 Thread marius d.

Great. Let me know if I can help with anything.

Br's,
Marius

On Jul 18, 9:22 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 Marius,

 This is awesome. Things are now working as expected - I knew this
 wasn't a browser connection issue causing the problems.

 The code in the widget package is pretty rubbish right now, but i just
 had time to hack together a hardcoded sample to make sure that your
 commit actually fix the problem... Im happy to report that it does
 indeed now work exactly as required.

 The next step is to work backwards and clean all the code up and fix
 the cross-browser issues as right now it works in firefox and IE but
 not in safari or chrome et al.

 Cheers, Tim

 On Jul 18, 3:08 pm, marius d. marius.dan...@gmail.com wrote:

  Just committed a fix ...

  Br's,
  Marius

  On Jul 18, 4:10 pm, marius d. marius.dan...@gmail.com wrote:

   A little more on this ...

   Living the above synchronized blocks where they are but removing the
   one from LiftSession.runParams  made it work properly. Looks like this
   one was holding the lock while the file upload progress was happening.
   Dave I'm not really sure why in runParams the the toRun is obtained
   from a synchronized block ... is it because we'rreading from
   messageCallback there ? ..cause otherwise the entire expression is
   about functions composition that does not change any state.

   Br's,
   Marius

   On Jul 18, 3:57 pm, Marius marius.dan...@gmail.com wrote:

HI there,

I know, there have been several other threads around the topic but I
just wanted to yield somethings here. In the past few days I've been
talking with Tim as he was having problems with his FileUpload widget.
Even with short polling the progress was not reported even though the
LiftSession.progressListener was properly called.

Today I started to look into it and here is what I've done:

1. Here is the markup:

  iframe id=upload_target name=upload_target src=# style=width:
0;height:0;border:0px solid #fff;/iframe

  lift:Upload.render form=POST multipart=true id=upload_form
target=upload_target
    f:inputFile/
    input type=submit value=Upload/
  /lift:Upload.render

  A simple snippet that uses the invisible iframe trick to upload
stuff in the background. The so called Ajax upload. (I had to add
the target attribute into the supported form snippet attributed but
that's ok)

2. In boot had something like:

    LiftSession.onSetupSession = ((session: LiftSession) = {
      session.progessListener = Full((chunk, total, index) = {
         Thread.sleep(100)
         println(index +  read  + chunk +  out of  + total +   +
Thread.currentThread)
      })
    }) :: Nil

    Just monitor the progress ... and to make it last a little longer
I'm sleeping for 100 milliseconds

3. I set the GC polling to 10 seconds. The think is that GC polling
would be just like the short polling for getting the progress status
back in the browser.

The behavior that I observed was that while I was uploading a 30 Mb +
file the polling requests timed out after 5 secconds per
LiftRules.ajaxPostTimeout. This means that our progress monitoring
ajax request would have timed out as well. On the server side the
execution got stuck until the upload was complete.
LiftServlet.handleAjax was not called until the upload terminates.

Initially I thought that this has to do to limited request channels
that browser have but the thing is that we have several places in Lift
code where we synchronize things. Such as LiftSession.getSession,
LiftSession.fixSessionTime etc. Acquiring these locks made the
progress polling to hang until the upload terminated. Of course
removing th synchronized block made the polling to work right during
the file upload. Now this was just for test ... I'm not suggesting to
remove the synchronized blocks as  we'd loose consistency but this
looks to stay in the way of properly dealing with multiple parallel
request per same session like fileupload and progress monitoring.

It appears that there is either a thread starvation situation or
simply a lock that is held while upload is is progress.

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



Re: [scala] Re: [Lift] Re: Jersey + Lift, whats the story?

2009-07-18 Thread David Pollak
Greg,
This sounds interesting... but I'd like to see what the Scala code would
look like that would manipulate the Zipper-based data structures.  If you've
got a pile of XML, what does it look like to map it to nested [case]
classes?  What does it look like to manipulate the XML?

Thanks,

David

On Fri, Jul 17, 2009 at 10:54 AM, Meredith Gregory lgreg.mered...@gmail.com
 wrote:

 Guys,

 After playing around with integrating Lift and Jersey before the Jersey
 guys did an 'official' integration and thinking hard about how i wanted to
 reference locations in data structures via URLs, i realized that 
 zipperhttp://en.wikipedia.org/wiki/Zipper_%28data_structure%29(cf. this
 explanation http://www.haskell.org/haskellwiki/Zipper) is a much better,
 much more functional, generic and maintainable solution.

 Briefly, the way this works is to automate the calculation of a context
 type, C(T), from a data type T. The context type will allow for the
 representation of locations in an instance of T in terms of contexts and
 holes. There's a natural way to get from contexts to paths. So, there's a
 natural map from URLs (viewed as paths) to locations. One great example of
 how this works in practice is Oleg Kiselyov's Zipper-based file system. The
 analogy between paths to files and URLs to resources should be clear.

 This has led me to look at where to cut the line on calculating zippers. As
 the wikipedia article mentions above, it is possible do this completely
 generically, provided one has a notion of differentiation on data
 structures; that is, the zipper can be expressed in terms of the derivative
 of a data structure. There are two natural (and somewhat competing) places
 to hang the differentiation calculation:

- the new collections library for scala
- the target of a mapping from one of the XML schema proposals to scala
types

 Jorge and i were chatting about this the other day. Either route is a bit
 of a large task and i've got a bunch of other stuff on my plate right now.
 However, i'd be very happy to collaborate with anyone who wants to make this
 happen. Also, by the way, this works really well with a lot of other
 monadically based machinery.

 Best wishes,

 --greg


 On Fri, Jul 17, 2009 at 8:17 AM, TylerWeir tyler.w...@gmail.com wrote:


 Wait a few days, and I think there'll be some very good news on this
 front.

 Tease! :)

 On Jul 17, 10:51 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  There are benefits to both approaches.  I prefer the partial function
  composition, but annotations on Pojos have their place.
  Wait a few days, and I think there'll be some very good news on this
 front.
 
  On Fri, Jul 17, 2009 at 7:28 AM, Timothy Perrett
 timo...@getintheloop.euwrote:
 
 
 
 
 
   Hey guys,
 
   I've been taking a look at Jersey and how it operates with Lift by way
   of the recent integration that cropped up on dev.java.net...
 
   From my perspective, I see how having a standard RS service framework
   could be helpful, but it appears to bypass important lift concepts
   like SiteMap etc so I'm just wondering what the benefit of using such
   a layer would be over using DispatchPF etc to create REST services or
   serving xml fragments for templates? (I have no idea about Jersey
   apart from the basic docs ive read, so if im missing a major benefit
   id love to hear discuss)
 
   Cheers for any thoughts
 
   Tim
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Git some:http://github.com/dpp
 



 --
 L.G. Meredith
 Managing Partner
 Biosimilarity LLC
 1219 NW 83rd St
 Seattle, WA 98117

 +1 206.650.3740

 http://biosimilarity.blogspot.com




-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
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: Code Review for Unique Key Constraints

2009-07-18 Thread Calen Pennington
So, I'm trying to make use of this code, now that it's in the git repo.

However, I'm running into the follow issue:

In my model, I have

object RecipeIngredient extends RecipeIngredient with
LongKeyedMetaMapper[RecipeIngredient] {
  override def dbIndexes = UniqueIndex(new IndexField(recipe), new
IndexField(order)) :: Nil
}

However, when the schemifier runs, I get a match error:

scala.MatchError: UniqueIndex(Array(IndexField(NULL), IndexField(0)))
at
net.liftweb.mapper.Schemifier$$anonfun$net$liftweb$mapper$Schemifier$$ensureIndexes$2.apply(Schemifier.scala:266)
at
net.liftweb.mapper.Schemifier$$anonfun$net$liftweb$mapper$Schemifier$$ensureIndexes$2.apply(Schemifier.scala:261)
...

It seems that the only way that the UniqueIndex wouldn't match would be if
there was a type inconsistency. However, I can't figure out how that could
be happening. (For reference, I get the same error if I use an Index, rather
than a UniqueIndex).

Any thoughts?

Thanks
-Cale

On Tue, Jul 14, 2009 at 4:05 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 OK, it's merged. An example usage of the new GenericIndex is:

 package com.test.model

 import _root_.net.liftweb.mapper._

 class DateItem extends Mapper[DateItem] with IdPK {
   def getSingleton = DateItem
   object timestamp extends MappedDateTime(this)
   object time extends MappedTime(this)
   object date extends MappedDate(this)
 }

 object DateItem extends DateItem with MetaMapper[DateItem] {
   override def fieldOrder = date :: time :: timestamp :: Nil
   override def dbIndexes = GenericIndex({ (table,columns) =
 String.format(CREATE UNIQUE INDEX %s ON %s %s, myindex_ + table + _ +
 columns.mkString(_), table, columns.mkString((, ,, )))},
 IHaveValidatedThisSQL(Derek, 2009-07-13), date) :: Nil
 }

 It's basically up to you to generate the DDL statement based on the table
 and column names.

 Derek


 On Mon, Jul 13, 2009 at 4:11 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 OK, on wip-dcb-unique-indices there's now a GenericIndex that should give
 you full flexibility to do whatever you want for an index. I'll hold until
 tomorrow to merge with trunk.

 Derek


 On Mon, Jul 13, 2009 at 9:26 AM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 I'll add a UserIndex type that will let you specify the creation of the
 index directly. Unique indices are generally supported across all DBs,
 AFAIK, so it makes it more clear to have a specific type.

 Derek


 On Mon, Jul 13, 2009 at 7:40 AM, Calen Pennington 
 calen.penning...@gmail.com wrote:


 Hey, I'm glad the code could make it in. One comment on your changes:
 It seems to me that using the pattern matching in ensureIndexes puts
 Lift in the position of maintaining support for various DBs, rather
 than letting the client code do it in a project by project basis (for
 instance, the FULLTEXT and SPACIAL index types that I mentioned, that
 are mysql specific.) Is there a reason that you preferred that over
 allowing client code to specify the index type?

 -Cale

 On Fri, Jul 10, 2009 at 5:32 PM, Derek Chen-Becker
 dchenbec...@gmail.com wrote:
  I've pushed a smaller commit into the wip-dcb-unique-indices branch on
  GitHub that adds a UniqueIndex case class. Conceivably we could add
 other
  types of indices if there's a need. If no one has any objections to
 what
  I've added I can merge with trunk on Monday.
 
  Derek
 
  http://github.com/dpp/liftweb/tree/wip-dcb-unique-indices
 
  On Thu, Jul 9, 2009 at 9:44 PM, DFectuoso santiago1...@gmail.com
 wrote:
 
  I for one would like to say: Cool! Thanks! If i need unique indexes
 in
  the next couple of weeks i'll get this baby to the war( .war thats
  it ) =)
 
  On Jul 9, 11:30 am, Calen Pennington calen.penning...@gmail.com
  wrote:
   As mentioned is this issue
   (http://github.com/dpp/liftweb/issues#issue/19), and as came up on
 the
   list recently, Lift currently has no way to specify that a field or
 an
   index be unique. I've coded up a patch that addresses this, and
 could
   also be used for other index types on a project specific basis (for
   instance, FULLTEXT or SPATIAL indexes in mysql).
  
   -Cale
  
0001-Adding-the-ability-to-create-UNIQUE-indexes-over-sin.patch
   5KViewDownload
 
 
 
 
  
 






 


--~--~-~--~~~---~--~~
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] building lift

2009-07-18 Thread Wilson MacGyver

Hi,

I git clone the lift source from git hub. then run mvn install to build it.

It fails with

Downloading: 
http://scala-tools.org/repo-releases/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[INFO] Unable to find resource 'javax.transaction:jta:jar:1.0.1B' in
repository scala-tools.org (http://scala-tools.org/repo-releases)
Downloading: 
http://scala-tools.org/repo-snapshots/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[INFO] Unable to find resource 'javax.transaction:jta:jar:1.0.1B' in
repository scala-tools.org.snapshots
(http://scala-tools.org/repo-snapshots)
Downloading: 
http://repo1.maven.org/maven2/javax/transaction/jta/1.0.1B/jta-1.0.1B.jar
[INFO] Unable to find resource 'javax.transaction:jta:jar:1.0.1B' in
repository central (http://repo1.maven.org/maven2)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) javax.transaction:jta:jar:1.0.1B


is this intentional due to some license issue with the jta jar?

Thanks,
Mac

-- 
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: JTA Transaction Monad - Early Access Program

2009-07-18 Thread David Pollak
On Sat, Jul 18, 2009 at 11:20 AM, Timothy Perrett
timo...@getintheloop.euwrote:


 Awesome - kudos Jonas.


+1

And more generally, it's great to have such a diverse and talented group of
people contributing to Lift!




 Cheers, Tim

 On Jul 18, 11:53 am, Jonas Bonér jbo...@gmail.com wrote:
  JTA stuff is in github master branch now.
 http://github.com/dpp/liftweb/tree/4d8405a3dcf93570da8142c078784f9dc1...
 
  Have fun.
  /Jonas

 



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
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
-~--~~~~--~~--~--~---