[Lift] Re: RFC: Restructuring Lift Codebase

2009-09-28 Thread Heiko Seeberger
Indrajit,
Impressive work!
See my comments below ...

Heiko

2009/9/27 Indrajit Raychaudhuri indraj...@gmail.com


 [A] lift-* prefix looks superfluous, but it's best to have one for all
 artifacts that generate jar (packagingjar/packaging). Also Maven
 reactor feels happier when artifactId == directory_name (site
 generation, scm extrapolation etc., situation might have improved
 now).


Let's keep it!


 [B] The top level project categories (lift-core, lift-persistence,
 lift-modules etc.) are simple multi-module models at the moment and
 not meant to create anything other than pom. Therefore, lift-* prefix
 can go away. But they'll have to come back if we plan to generate 'one
 jar' in assembly mode per category (lift-core-all.jar, lift-
 persistence-all.jar etc.). This could be useful for 'get me
 everything, I don't care about size' people. But is it necessary? The
 alternative is to have empty 'meta modules' that pull up the necessary
 dependencies and can be included by the users in their project (quite
 similar to what lift-core does now).


Again, let's keep the prefix, because for Lift users not using Maven these
*-all.jars will be valuable.


 [D] Presentations and other materials aren't really source code for
 inclusion in source repository. Can this go in wiki? (immediate
 problem: github doesn't take attachment). Has this been discussed
 earlier? They can go as a separate github project too.


GitHub's Wiki or Downloads are not well suited for these materials. I tried
myself for ScalaModules and it was frustrating.
Therefore I think keeping them in the repository in a separate folder which
of course in not a Maven module is a pragmatic solution.


 [F] The modules in a category can be further sub-grouped, but with
 caution. Basically, need the right mix between 'flat'-ness and deep
 nesting. Thoughts on this?


Let's not go deeper right now.

-- 
Heiko Seeberger

My job: weiglewilczek.com
My blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to 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 and Hibernate validators

2009-09-28 Thread etorreborre

Hi,

I'm trying to get a Lift/JPA demo rolling but I can't get Scala work
with Hibernate validators (as it has been noticed before:
https://lampsvn.epfl.ch/trac/scala/ticket/1846,
https://lampsvn.epfl.ch/trac/scala/ticket/2245,
https://lampsvn.epfl.ch/trac/scala/ticket/2252).

My question is: what's your preferred workaround for this issue when
using Lift/JPA?

Thanks,

Eric.
--~--~-~--~~~---~--~~
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: automaticly generated forms and submit button naming

2009-09-28 Thread Martin

Hi,

Ross, thank you for your help. This code works perfectly for me. I
heaven't noticed I could group many elements in one lift tag.

I changed somethings in your code. Maybe it's not worth mentioning but
if someone has similar problems it can help a little.
I corrected only to things: changed parameters order in one bind and
added some code to other.
Result is here:

def newPlace(ns: NodeSeq, place : Place): NodeSeq = {
def bindFields(innerNs: NodeSeq): NodeSeq = {
var s : String = test
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
flatMap(f = {
f.toForm.toList.map(form = {
bind(field,
innerNs,
displayName -
 f.displayName,
form-
 form)(1);
})
})
}

def handleSubmit(): Any = {
}

bind(place, ns,
 fields - { (ns: NodeSeq) = bindFields(ns) },
 submit - { (ns: NodeSeq) = SHtml.submit(Submit new
place, handleSubmit _) })
}

Still I don't get why I need to get second element from bind result
(which is NodeSeq) and pass it to .toForm.toList.map(...).
When I first compiled this code i got type mismatch error:
 found   : scala.xml.NodeSeq
 required: scala.xml.Node

So I picked up first non empty element from the result by using bind
(...)(1) and it works in my scenario. Maybe I will catch it later ;)

Again this code works perfectly for me. Great thanks Ross!

- Martin




On 24 Wrz, 16:15, Ross Mellgren dri...@gmail.com wrote:
 It sounds like you probably want p{ SHtml.submit(Title of submit  
 button, () = actionToTakeWhenButtonIsUsedToSubmitForm) }/p

 By the way, what you have there doesn't seem to be following the usual  
 lift pattern of binding snippets, is there a reason that you prefer  
 this to:

 template:

 lift:MySnippet.newPlace form=post
      h4Place details/h4
      div
          place:fields
              p
                  labelfield:displayName //label
                  field:form /
              /p
          /place:fields
      /div
      pplace:submit //p
 /lift:MySnippet.newPlace

 Snippet:

 def newPlace(ns: NodeSeq): NodeSeq = {
      val place = /* make a new place somehow */

      def bindFields(ns: NodeSeq): NodeSeq =
          signupFields.
              map(fi = getSingleton.getActualBaseField(place, fi)).
              flatMap(f = {
                  f.toForm.toList.map(form = {
                      bind(ns, field,
                           displayName - f.displayName,
                           form        - form)
                  })
              })

      def handleSubmit(): Any = /* do something with place */

      bind(place, ns,
           fields - { (ns: NodeSeq) = bindFields(ns) },
           submit - { (ns: NodeSeq) = SHtml.submit(Submit new  
 Place, handleSubmit _) })

 }

 This way lets you see most of the HTML in one place (the template). I  
 inlined localForm, but there's no particular reason that it needs to  
 be local (other than it closes on place, but you could just pass that  
 in)

 -Ross

 On Sep 24, 2009, at 6:55 AM, Martin wrote:



  Hi all,

  I've got a following problem. When I create a form form automaticly..
  similar to the User login/register example I encontered a problem I'm
  not posible to cope with.

  Firstly I have 'written' a function (using CopyPaste method) which
  creates a form fields list based on my class properties:

     private def localForm(place: Place, ignorePassword: Boolean):
  NodeSeq = {
         signupFields.
         map(fi = getSingleton.getActualBaseField(place, fi)).
         filter(f = !ignorePassword || (f match {
                     case f: MappedPassword[Place] = false
                     case _ = true
                 })).
         flatMap(f =
             f.toForm.toList.map(form = plabel{f.displayName}/
  label {form}/p) )
     }

  Next, I wrote some code to return a complete form to the snippet:

     def newPlace(place: Place) =
     form method=post action={S.uri}
         h4Place details/h4
         div
             {
                 localForm(place, false)
             }
         /div
         p_WHAT_SHOULD_I_WRITE_HERE_:submit //p
     /form

  My question is... what do I write in _WHAT_SHOULD_I_WRITE_HERE_ ?
  Or better.. how/where to define this value?

  In a user login/register example there is submit defined like this:
  user:submit

  Placing there name of the owner class didn't work.
  I know I could use bind but as far as I know next I should create a
  complete snippet with all the fields by hand.. and I would to avoid
  it.

  I was digging for solution in a Lift Book and on group as well, but
  without success.
  Help!

--~--~-~--~~~---~--~~
You received this 

[Lift] Seeking for Simple Sample .scala and .html that mimics CRUDify/Seam-Gen

2009-09-28 Thread yk

I have had plowing through the internet for two weeks now, for a
simple tutorial that can point me in the right direction to catch on
the Lift/Scala bandwagon.

I am a CodeCharge studio coder and have had exposed to seam-gen codes
deploying on JBoss AS at the rookie level.

I had tried RoR and have liked the instant gratification joy but not
the performance issue(s) that I stumbled across on the internet.

At this junction, I had went through examples of Starting with Lift,
Exploring Lift, and the tutorial from IBM involving Comet. I had also
went through the OneToMany tutorial on Wiki (along with source code)
and the ManyToMany (UserMon) example from one of the posting.

I believe Scala/Lift will be the probable solution for the portal I am
building and wish for some additional help.

I am shamelessly asking for a bunch of sample codes (Both snippets and
html) of the OneToMany tutorial (the one involving Author and Book)
that mimics CRUDify/Seam-Gen generated code with clear add/remove/
update/delete defs so a noob like myself can understand better =S

Thank you in advance.
yk

--~--~-~--~~~---~--~~
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: automaticly generated forms and submit button naming

2009-09-28 Thread Ross Mellgren

Ah, that's because it should be a flatMap not a map --  
f.toForm.toList.flatMap(form = { bind(...) }) should typecheck.

The way you have it now, if the bind expands to more than one element  
or node, the ones after the first will be dropped.

Glad it (mostly) worked for you.

-Ross

On Sep 28, 2009, at 5:48 AM, Martin wrote:


 Hi,

 Ross, thank you for your help. This code works perfectly for me. I
 heaven't noticed I could group many elements in one lift tag.

 I changed somethings in your code. Maybe it's not worth mentioning but
 if someone has similar problems it can help a little.
 I corrected only to things: changed parameters order in one bind and
 added some code to other.
 Result is here:

def newPlace(ns: NodeSeq, place : Place): NodeSeq = {
def bindFields(innerNs: NodeSeq): NodeSeq = {
var s : String = test
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
flatMap(f = {
f.toForm.toList.map(form = {
bind(field,
 innerNs,
displayName -
 f.displayName,
form-
 form)(1);
})
})
}

def handleSubmit(): Any = {
}

bind(place, ns,
 fields - { (ns: NodeSeq) = bindFields(ns) },
 submit - { (ns: NodeSeq) = SHtml.submit(Submit new
 place, handleSubmit _) })
}

 Still I don't get why I need to get second element from bind result
 (which is NodeSeq) and pass it to .toForm.toList.map(...).
 When I first compiled this code i got type mismatch error:
 found   : scala.xml.NodeSeq
 required: scala.xml.Node

 So I picked up first non empty element from the result by using bind
 (...)(1) and it works in my scenario. Maybe I will catch it later ;)

 Again this code works perfectly for me. Great thanks Ross!

 - Martin




 On 24 Wrz, 16:15, Ross Mellgren dri...@gmail.com wrote:
 It sounds like you probably want p{ SHtml.submit(Title of submit
 button, () = actionToTakeWhenButtonIsUsedToSubmitForm) }/p

 By the way, what you have there doesn't seem to be following the  
 usual
 lift pattern of binding snippets, is there a reason that you prefer
 this to:

 template:

 lift:MySnippet.newPlace form=post
  h4Place details/h4
  div
  place:fields
  p
  labelfield:displayName //label
  field:form /
  /p
  /place:fields
  /div
  pplace:submit //p
 /lift:MySnippet.newPlace

 Snippet:

 def newPlace(ns: NodeSeq): NodeSeq = {
  val place = /* make a new place somehow */

  def bindFields(ns: NodeSeq): NodeSeq =
  signupFields.
  map(fi = getSingleton.getActualBaseField(place, fi)).
  flatMap(f = {
  f.toForm.toList.map(form = {
  bind(ns, field,
   displayName - f.displayName,
   form- form)
  })
  })

  def handleSubmit(): Any = /* do something with place */

  bind(place, ns,
   fields - { (ns: NodeSeq) = bindFields(ns) },
   submit - { (ns: NodeSeq) = SHtml.submit(Submit new
 Place, handleSubmit _) })

 }

 This way lets you see most of the HTML in one place (the template). I
 inlined localForm, but there's no particular reason that it needs to
 be local (other than it closes on place, but you could just pass that
 in)

 -Ross

 On Sep 24, 2009, at 6:55 AM, Martin wrote:



 Hi all,

 I've got a following problem. When I create a form form  
 automaticly..
 similar to the User login/register example I encontered a problem  
 I'm
 not posible to cope with.

 Firstly I have 'written' a function (using CopyPaste method) which
 creates a form fields list based on my class properties:

private def localForm(place: Place, ignorePassword: Boolean):
 NodeSeq = {
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
filter(f = !ignorePassword || (f match {
case f: MappedPassword[Place] = false
case _ = true
})).
flatMap(f =
f.toForm.toList.map(form = plabel{f.displayName}/
 label {form}/p) )
}

 Next, I wrote some code to return a complete form to the snippet:

def newPlace(place: Place) =
form method=post action={S.uri}
h4Place details/h4
div
{
localForm(place, false)
}
/div
p_WHAT_SHOULD_I_WRITE_HERE_:submit //p
/form

 My question is... what do I write in _WHAT_SHOULD_I_WRITE_HERE_ ?
 Or better.. how/where to define this value?

 In a user login/register example there is submit defined like this:
 user:submit

 Placing there name of the owner class didn't work.
 I know I 

[Lift] Re: Tabbed browsing and session state

2009-09-28 Thread marius d.



On Sep 27, 10:31 am, Naftoli Gugenheim naftoli...@gmail.com wrote:
 Do you mean multiple browser tabs? They won't interfere, because which 
 stateful snippet is used in a given request depends on which is registered in 
 that request which depends on which function is called which depends on which 
 function id is in the request query parameters which depends on the link that 
 was clicked which is generated by the stateful snippet :)
 But if one page must link to several pages each with a pre-instantiated 
 snippet you must use mapSnippet.
 Marius, did David work on lift-wizard since the last time he said he doesn't 
 know when he will find time? Also, how would he approach his goal using 
 lift-wizard?

Dunno. I pointed to lift-wizard mostly for looking to the code and see
if the concept fits tiro's needs.



 -

 marius d.marius.dan...@gmail.com wrote:

 Tiro,

 Please see the lift-wizard project.

 Br's,
 Marius

 On Sep 27, 1:33 am, tiro tim.romb...@googlemail.com wrote:



  Naftoli,
  thanks for providing these insights into the inner workings of
  Stateful Snippets. The mapSnippet solution sounds interesting. I knew
  that snippets don't live on when not needed, but assumed that IF one
  is alive in the current session, you would always get that one
  instance. Hence at most one instance would be alive per snippet class
  and per session. What you seem to indicate is that the lifecycle is
  held together by redirects and such (and therefore page ids) rather
  than two requests being in the same session. I will experiment how
  that works with tabs. I guess one has to still be very careful since
  the user may go from the view initiating a snippet and open several
  tabs from there, whereafter you could still get unwanted interference
  between the tabs if you don't pay attention.

  Marius, thanks for your pointsWizard code

  exciting.. since the wizardiness probably won't jump into my eye, if
  you happen to stumble on it in the next few days, could you perhaps
  post a classname here?

  That data needs to be preserved into a RequestVar,

  That is precisely what I meant by passing state on from a response to
  the next request :-) RequestVars are benign.

  AJAX Tabs

  Had briefly thought of that. Makes good sense with some types of apps.
  In this particular app I've already made other compromises to preserve
  standard behavior and let the user bookmark the current URL etc.

 Bookmarking URL's would make you loose state unless you preserve that
 state in the URL itself. But you're fully aware of this.

  Actually things would already be much simpler if browsers allowed you
  to address tabs by Javascript (close current tab, jump to search
  results tab). One could then keep the results list open in a user-
  friendly way. But apparently browsers have been getting quite
  restrictive on that, for obvious reasons.
--~--~-~--~~~---~--~~
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: CometActor timeout problem

2009-09-28 Thread David Pollak
Jack,
Here's a working example.

Here's the source for the CometActor:


package com.liftcode.comet
import net.liftweb._
import http._
import util._

class Background extends CometActor {
  private val values = new Array[Box[Int]](100)

  // render the information
  def render =
  div
ul
  {
values.zipWithIndex.map{
  case (Full(v), idx) = liItem: {idx} is {v}/li
  case (_, idx) = liItem: {idx} iCalculating/i/li
}
  }
/ul
  /div

  // receive the update and re-render
  override def lowPriority = {
case (idx: Int, value: Int) =
  values(idx) = Full(value)
  reRender(false)
  }

  // fork 100 thread
  override def localSetup() {
super.localSetup()
values.zipWithIndex.foreach {
  case (_, idx) =
(new Thread(
new Runnable {
  def run() {
Thread.sleep(1 + Helpers.randomLong(1))
Background.this ! (idx, Helpers.randomInt(1000))
  }
}
)).start()
}
  }
}


Note that the render method cannot block.  You must always render the page
and put placeholders where you will be updating values.

Note also that this code re-renders the entire comet component on each
update.  This is network inefficient.  Please take a look a the Comet Chat
example for how to user partial update which is much more network efficient.

Thanks,

David


On Sun, Sep 27, 2009 at 8:09 PM, jack jack.wid...@gmail.com wrote:


 I am still having this problem so I will post a simple example. Say I
 want to display a list of the numbers 1 to 100. And suppose I have an
 object Foo and a method bar, which takes an integer and returns an
 integer. And bar takes about 10 seconds to return. So I want to
 display the numbers, run Foo.bar on each of them in the background,
 and then update the display via comet to replace each integer with bar
 of it. I got the Clock example to work and I think I understand what
 is going on there. Could somebody show me how to do this example in
 terms of the Clock example? Or just a few lines of code to suggest how
 to do it?








 On Sep 18, 12:09 pm, marius d. marius.dan...@gmail.com wrote:
  On Sep 17, 11:09 pm,jackjack.wid...@gmail.com wrote:
 
   I have a CometActor which displays a list of urls and at the same time
   launches a bunch of threads each of which gets information about the
   urls and then puts messages about that information in a Queue. On each
   new tick, the CometActor checks the queue and updates its urls.
 
   The problem is that I am launching the threads from the CometActor and
   the page is never coming back. It times out.
 
  So the page never gets rendered? I would recommend using actors and
  not really threads but even with threads it shouldn't impact you. But
  it also depends on what your code does. Can you post a minimalistic
  example?
 
 
 
 
 
   Is there some general principle about launching threads from a
   CometActor that might explain this behavior?
 



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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to 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
-~--~~~~--~~--~--~---



comet_foo.tgz
Description: GNU Zip compressed data


[Lift] Re: Db.addLogFunc

2009-09-28 Thread Derek Chen-Becker
I tested it locally on my own code and it works. Just for giggles, does
anything print on the console if you change those lines to println?

Derek

On Wed, Sep 23, 2009 at 2:39 PM, David david.b...@gmail.com wrote:


 Hello, I'm trying to use the new logging information as described
 here.  In my Boot I have:

 import net.liftweb.mapper.{DB, DBLogEntry}
 snip...

DB.addLogFunc {
  case (query, time) = {
 Log.info(All queries took  + time + ms: )
 query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
Log.info(stmt +  took  + duration + ms)})
Log.info(End queries)
  }
}

 I'm using slf4j and logback, my root level is set to trace.  I see
 trace output from lift, like:
 16:32:02.208 [5991...@qtp-10429832-0] TRACE lift.trace:76 - Released
 connection ConnectionIdentifier(lift) on thread Thread
 [5991...@qtp-10429832-0,5,main]

 But I don't see any output from the DB log functions.   Is there
 anything else I need to do in order to enable logging?  I'm using
 scala 2.7.5 and lift 1.1-SNAPSHOT.

 Thanks, Dave


 On Aug 28, 1:20 pm, marius d. marius.dan...@gmail.com wrote:
  EXCELLENT WORK DEREK !
 
  On Aug 28, 7:28 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
 
   Hi all,
   I've made a change to the Mapper logging functionality in
   wip-dcb-sql-log-wrappers. The DB.addLogFuncmethod has changed to:
 
  addLogFunc( f: (DBLog,Long) = Any)
 
   where DBLog is a new trait (below) and the Long corresponds to the
 *total*
   duration of a given DB execution method. DBLog is defined as:
 
   trait DBLog {
 ... private stuff up here ...
 /** Return a list of all of the DBStatementEntry instances in the log
   buffer */
 def statementEntries : List[DBStatementEntry] = ...
 
 /** Return a list of all of the DBMetaEntry instances in the log
 buffer */
 def metaEntries : List[DBMetaEntry] = ...
 
 /** Return all log buffer entries */
 def allEntries : List[DBLogEntry] = ...
 
   }
 
   and we have some new event class/traits:
 
   trait DBLogEntry {
 def statement : String
 def duration : Long}
 
   object DBLogEntry {
 def unapply(obj : Any) = obj match {
   case entry : DBLogEntry = Some(entry.statement,entry.duration)
   case _ = None
 }}
 
   case class DBStatementEntry(statement : String, duration : Long)
 extends
   DBLogEntry
   case class DBMetaEntry(statement : String, duration : Long) extends
   DBLogEntry
 
   Statements are SQL statements, prepared or immediate, and meta entries
   correspond to things like getMaxRows, getGeneratedKeys, etc. As you can
 see,
   each individual statement records its own duration as well, so you can
 get
   fine-grained detail on all activity. An example log function in Boot
 could
   look like:
 
   DB.addLogFunc{
 case (query, time) = {
   Log.info(All queries took  + time + ms: )
   query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
   Log.info(stmt +  took  + duration + ms)})
   Log.info(End queries)
 }
   }
 
   And we get output like:
 
   INFO - All queries took 17ms:
   INFO - Exec update INSERT INTO users
  
 (lastname,locale,password_pw,password_slt,validated,uniqueid,timezone,firstname,email,superuser,textarea)
   VALUES
  
 (C,en_US,GzwLqDpmJ6TrECg06bGKvOAQxyc=,1JTAWGSSYLJHXASO,1,DU0G0RT3IFOA0NHSY5QQQTX42BOIHDGI,US/Mountain,D,
   d...@c.com,0,) : updated 1 rows took 9ms
   INFO - Get generated keys : rs =
   oracle.jdbc.driver.oraclereturnresult...@23f9e6e5 took 2ms
   INFO - Closed Statement took 0ms
   INFO - End queries
 
   Note that this code does introduce a breaking change if you're already
 using
   log functions, since theaddLogFuncsignature has changed. If I can get a
   review on the code before I merge to master I would appreciate it.
 
   Derek
 
   On Sat, Aug 15, 2009 at 8:02 AM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:
 
OK, a preliminary version of log wrappers is checked in on
wip-dcb-sql-log-wrappers. I'll merge it on Tuesday if no one sees any
problems with it.
 
Derek
 
On Tue, Aug 11, 2009 at 11:08 AM, Derek Chen-Becker 
 dchenbec...@gmail.com
 wrote:
 
Will do.
 
On Tue, Aug 11, 2009 at 2:33 AM, marius d. marius.dan...@gmail.com
 wrote:
 
Please do so. If you need any help for some reason (time
 availability
etc.) please let me know. As a note probably the wrappers should be
only only when there is at least one log function registered.
 
Br's,
Marius
 
On Aug 6, 11:48 pm, Derek Chen-Becker dchenbec...@gmail.com
 wrote:
 If there's a consensus that we want our own JDBC wrappers I'll go
 ahead
and
 write them.
 
 Derek
 
 On Thu, Aug 6, 2009 at 1:19 PM, marius d. 
 marius.dan...@gmail.com
wrote:
 
  Probably building our own wrappers would be more lightweight
 then
3-rd
  party. Jus' guessing
 
  Br's,
  Marius
 
  On Aug 6, 9:58 pm, Derek Chen-Becker 

[Lift] Re: TreeView widget doesn't work with IE 8

2009-09-28 Thread Derek Chen-Becker
Can you do two things:

1. Open a ticket on GitHub: http://github.com/dpp/liftweb/issues
2. In the ticket, can you give some more details about what does and doesn't
work? If you're getting javascript errors it would help to have those, too.

Derek

On Wed, Sep 23, 2009 at 3:43 PM, glenn gl...@exmbly.com wrote:


 The TreeView widget doesn't work in IE 8. I haven't tested in earlier
 versions. It does work in the latest FireFox.

 Glenn
 


--~--~-~--~~~---~--~~
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: Db.addLogFunc

2009-09-28 Thread David

Nope, changed to println():

DB.addLogFunc {
  case (query, time) = {
 println(All queries took  + time + ms: )
 query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
println(stmt +  took  + duration + ms)})
println(End queries)
  }
}

Nothing on console.

Thanks, David

On Sep 28, 1:36 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
 I tested it locally on my own code and it works. Just for giggles, does
 anything print on the console if you change those lines to println?

 Derek

 On Wed, Sep 23, 2009 at 2:39 PM, David david.b...@gmail.com wrote:

  Hello, I'm trying to use the new logging information as described
  here.  In my Boot I have:

  import net.liftweb.mapper.{DB, DBLogEntry}
  snip...

     DB.addLogFunc {
       case (query, time) = {
          Log.info(All queries took  + time + ms: )
          query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
             Log.info(stmt +  took  + duration + ms)})
             Log.info(End queries)
       }
     }

  I'm using slf4j and logback, my root level is set to trace.  I see
  trace output from lift, like:
  16:32:02.208 [5991...@qtp-10429832-0] TRACE lift.trace:76 - Released
  connection ConnectionIdentifier(lift) on thread Thread
  [5991...@qtp-10429832-0,5,main]

  But I don't see any output from the DB log functions.   Is there
  anything else I need to do in order to enable logging?  I'm using
  scala 2.7.5 and lift 1.1-SNAPSHOT.

  Thanks, Dave

  On Aug 28, 1:20 pm, marius d. marius.dan...@gmail.com wrote:
   EXCELLENT WORK DEREK !

   On Aug 28, 7:28 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:

Hi all,
    I've made a change to the Mapper logging functionality in
wip-dcb-sql-log-wrappers. The DB.addLogFuncmethod has changed to:

   addLogFunc( f: (DBLog,Long) = Any)

where DBLog is a new trait (below) and the Long corresponds to the
  *total*
duration of a given DB execution method. DBLog is defined as:

trait DBLog {
  ... private stuff up here ...
  /** Return a list of all of the DBStatementEntry instances in the log
buffer */
  def statementEntries : List[DBStatementEntry] = ...

  /** Return a list of all of the DBMetaEntry instances in the log
  buffer */
  def metaEntries : List[DBMetaEntry] = ...

  /** Return all log buffer entries */
  def allEntries : List[DBLogEntry] = ...

}

and we have some new event class/traits:

trait DBLogEntry {
  def statement : String
  def duration : Long}

object DBLogEntry {
  def unapply(obj : Any) = obj match {
    case entry : DBLogEntry = Some(entry.statement,entry.duration)
    case _ = None
  }}

case class DBStatementEntry(statement : String, duration : Long)
  extends
DBLogEntry
case class DBMetaEntry(statement : String, duration : Long) extends
DBLogEntry

Statements are SQL statements, prepared or immediate, and meta entries
correspond to things like getMaxRows, getGeneratedKeys, etc. As you can
  see,
each individual statement records its own duration as well, so you can
  get
fine-grained detail on all activity. An example log function in Boot
  could
look like:

    DB.addLogFunc{
      case (query, time) = {
        Log.info(All queries took  + time + ms: )
        query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
Log.info(stmt +  took  + duration + ms)})
        Log.info(End queries)
      }
    }

And we get output like:

INFO - All queries took 17ms:
INFO - Exec update INSERT INTO users

  (lastname,locale,password_pw,password_slt,validated,uniqueid,timezone,firstname,email,superuser,textarea)
VALUES

  (C,en_US,GzwLqDpmJ6TrECg06bGKvOAQxyc=,1JTAWGSSYLJHXASO,1,DU0G0RT3IFOA0NHSY5QQQTX42BOIHDGI,US/Mountain,D,
d...@c.com,0,) : updated 1 rows took 9ms
INFO - Get generated keys : rs =
oracle.jdbc.driver.oraclereturnresult...@23f9e6e5 took 2ms
INFO - Closed Statement took 0ms
INFO - End queries

Note that this code does introduce a breaking change if you're already
  using
log functions, since theaddLogFuncsignature has changed. If I can get a
review on the code before I merge to master I would appreciate it.

Derek

On Sat, Aug 15, 2009 at 8:02 AM, Derek Chen-Becker 
  dchenbec...@gmail.comwrote:

 OK, a preliminary version of log wrappers is checked in on
 wip-dcb-sql-log-wrappers. I'll merge it on Tuesday if no one sees any
 problems with it.

 Derek

 On Tue, Aug 11, 2009 at 11:08 AM, Derek Chen-Becker 
  dchenbec...@gmail.com
  wrote:

 Will do.

 On Tue, Aug 11, 2009 at 2:33 AM, marius d. marius.dan...@gmail.com
  wrote:

 Please do so. If you need any help for some reason (time
  availability
 etc.) please let me know. As a note probably the wrappers should be
 only only when there is at least one log function registered.

 

[Lift] Re: RFC: Restructuring Lift Codebase

2009-09-28 Thread David Pollak
Indrajit,
Excellent work!

My thoughts inline.

On Sun, Sep 27, 2009 at 1:44 PM, Indrajit Raychaudhuri
indraj...@gmail.comwrote:


 Folks,

 As followup to the proposed goal of Keeping lift-core neat and
 small, here is the first iteration of the revised structure of Lift
 codebase.


 liftweb

 - lift-core [10]


lift-core currently means everything Lift.  I think we need another name,
but none is jumping out at me.


  - lift-base [02]
  - lift-actor
  - lift-util
  - lift-json [03]
  - lift-webkit [04]
  - lift-testkit [05]

 - lift-persistence [06]
  - lift-mapper
  - lift-record
  - lift-jpa

 - lift-modules [07]
  - lift-osgi
  - lift-wizard [08]
  - lift-widgets [09]
  - lift-machine
  - lift-textile
  - lift-facebook
  - lift-amqp
  - lift-xmpp
  - lift-openid
  - lift-oauth
  - lift-paypal
  - lift-jta

 - lift-archetypes
  - ...

 - lift-examples
  - ...

 - lift-site [10]

 - lift-resources [lift-varia, lift-infra ?] [11]
  - lift-root-model [12]
  - lift-site-skin
  - lift-installer
  - misc config resources (scaladoc, javadoc etc.)

 General notes (including some obvious ones):

 [A] lift-* prefix looks superfluous, but it's best to have one for all
 artifacts that generate jar (packagingjar/packaging). Also Maven
 reactor feels happier when artifactId == directory_name (site
 generation, scm extrapolation etc., situation might have improved
 now).

 [B] The top level project categories (lift-core, lift-persistence,
 lift-modules etc.) are simple multi-module models at the moment and
 not meant to create anything other than pom. Therefore, lift-* prefix
 can go away. But they'll have to come back if we plan to generate 'one
 jar' in assembly mode per category (lift-core-all.jar, lift-
 persistence-all.jar etc.). This could be useful for 'get me
 everything, I don't care about size' people. But is it necessary? The
 alternative is to have empty 'meta modules' that pull up the necessary
 dependencies and can be included by the users in their project (quite
 similar to what lift-core does now).

 [C] The members in a project category (lift-mapper, lift-record etc.)
 would inherit the category model (lift-persistence in case of lift-
 mapper, lift-record). Related modules clubbed together helps similar
 configuration pulled up to the parent pom (improves DRY-ness). Added
 benefit: modules can be developed even outside Lift codebase with the
 given parent pom (available in global repo) and the developer won't
 have to worry about most of the infra related boilerplate
 configurations (couple of config still would need change though).

 [D] Presentations and other materials aren't really source code for
 inclusion in source repository. Can this go in wiki? (immediate
 problem: github doesn't take attachment). Has this been discussed
 earlier? They can go as a separate github project too.


From an administrative perspective, having two repositories represents twice
the work for me, so I'd rather everything from Lift committers stays in one
repository.  With that being said and with our new focus on not merging
anything into Master without a review-board cycle, I propose that we have a
presentations branch and people put their presos on this branch.  Whenever
someone merges their review-boarded code into master, they also merge in the
presentations branch.



 [E] The categorization is mostly based on my interpretation as a late
 entrant. If there is a different structure that fits the philosophy
 better (quite likely), this would get regrouped. (Tim ?)

 [F] The modules in a category can be further sub-grouped, but with
 caution. Basically, need the right mix between 'flat'-ness and deep
 nesting. Thoughts on this?

 [G] Each category can eventually be split up into separate projects
 and have their own release schedules (less frequent for core, more
 frequent for modules etc.). This might be little overkill at the
 moment. Just mentioned to enable us mind the long term perspective :)

 [H] Other points on the draft hierarchy (see the # in brackets above):

 [01] With these members, if lift-core doesn't sound as the right name,
 we need the right name. Provided the grouping is right that is.

 [02] Base interfaces for Lift (currently present in dpp_wip_actorized)

 [03] Doesn't really have to be part of Lift core in current form, but
 this is eventually meant to be part of Lift's JS infrastructure (thus
 kept here at the moment)

 [04] Candidate for decomposition. But kept intact at the moment. Would
 be taken up in next pass once the top level reaches steady state. This
 could either become a category of its own or a module with submodules.

 [05] Little unsure about it's intent and purpose, I could be
 completely mis-interpreting this. Thoughts from somebody with more
 understanding please :)


The lift-testkit is supposed to be a set of tools to generate integration
tests against the application.  I would put it in a separate high-level
package (perhaps lift-modules).  It is used during testing, 

[Lift] Re: Code Plugability in Lift

2009-09-28 Thread Derek Chen-Becker
It's a really ugly corner that JPA paints us into here. There aren't any
vendor-neutral APIs for programmatically wiring entities up, so it's going
to have to be some sort of trickery.

On Fri, Sep 25, 2009 at 4:23 PM, Timothy Perrett timo...@getintheloop.euwrote:

 Are you feeling OK david? For a moment I thought you said *runtime*
 bytecode generation?!

 Cheers, Tim

 On 25 Sep 2009, at 23:06, David Pollak wrote:

 I've been thinking about vomitting (I mean creating) bytecode at runtime
 that creates a mock class for Hibernate consumption.

 On Fri, Sep 25, 2009 at 3:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 I've been thinking about it in the back of my head. I may be able to get
 something working that's vendor specific (e.g. Hibernate) by using their
 internal API to have the Record+JPA driver wire up the entities at runtime
 based on Record metadata. Feels kinda dirty, but if it works that would be
 great.

 Derek


 On Mon, Sep 21, 2009 at 4:29 PM, Timothy Perrett timo...@getintheloop.eu
  wrote:


 I know we've discussed this before, but ultimately we'd like to wrap
 JPA with a Record front end somehow...

 Cheers, Tim

 On Sep 21, 10:42 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  On Mon, Sep 21, 2009 at 2:03 PM, glenn gl...@exmbly.com wrote:
 
   David,
 
   Does this mean you could write an entity class, like so:
 
   class User(val firstName: String, val lastName: String, val userName:
   String, val email: String, val password: String) with myTrait {...}
 
   and it would be useable in either a JPA or mapper or record
   implementation?
 
  No.  Mapper/Record require a richer representation of fields than
 Pojos.
   The reason for this can be found athttp://
 blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-w...
 
 
 
 
 
 
 
   That would be the ticket.
 
   Glenn
 
   On Sep 21, 12:47 pm, David Pollak feeder.of.the.be...@gmail.com
   wrote:
This is an impedance mis-match between POJOs (what JPA expects) and
 the
richer fields that Mapper and Record have.
I'm working on an interface (
  
 http://github.com/dpp/liftweb/blob/master/lift-util/src/main/scala/ne..
 .)
that should be a base trait on everything in Lift that's gettable
 or
gettable/settable.
 
Then you could write a trait that looks like:
 
trait MyThing {  def name: PSettableValueHolder[String]
*
*
* def getName(): String = name.is*
* def setName(in: String) = name.set(in)*
*
*
* *
 
}
 
Such a trait should be able to bridge a JPA implementation and a
 Lift
   mapper
implementation.
 
If you've got a better solution, please code it up and let's talk
 about
   it.
 
On Mon, Sep 21, 2009 at 9:31 AM, glenn gl...@exmbly.com wrote:
 
 Forgive me. I'm bringing up the subject of modularization in Lift
 under a new heading, but the last discussion was, sadly, all over
 the
 map and only served to emphasize the problem. So let me narrow it
 down, a bit, here, and ask:
 
 How is it possible to create two different snippet
 implementations, or
 two different models, one JPA and one not, or one using the
 mapper
 framework and another the record, and replace one with the other
 without having to recompile the application?
 
 We're not talking here about interface design - you still have to
 deal
 with boot.  And traits, as has been suggested by others...well,
 you'd
 better not expose them to the world outside your implementation,
 as
 any changes would require recompilation. In other words, you
 can't
 really use traits for your interface.
 
 To use Lift in the enterprise does require that teams be able to
 work
 independently, doesn't it.
 
 Glenn
 
--
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
 
  --
  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







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




 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to 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: SHtml.a not active when used via innerHtml

2009-09-28 Thread David Pollak
On Fri, Sep 25, 2009 at 5:43 PM, KP horse.headed.fish@gmail.com wrote:


 David,

 This works like a charm. Thanks. There is essentially zero chance I
 would have figured this out on my own.


Yeah... it took a fair amount of digging into SetHtml and dusting off old
parts of my brain to remember how and why.

Please keep asking questions!

Thanks,

David



 KP


 On Sep 24, 7:13 pm, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  There is a trait in JsCommands:
 
  trait HtmlFixer {
def fixHtml(uid: String, content: NodeSeq): String =
AltXML.toXML(Group(S.session.map(s =
  s.fixHtml(s.processSurroundAndInclude(JS SetHTML id: +uid,
  content))).openOr(content)),
 false, true, S.ieMode).encJs
 
  }
 
  What this trait does it it rewrites the content such that it is ready to
 be
  displayed.  This means updating any links based on the context path,
  rewriting any lift:a/ tags, running snippets and generally making the
  XHTML clean.
 
  I would suggest running your intermediate XHTML through this method and
  it'll come out working as you expect it to.
 
 
 
 
 
  On Tue, Sep 22, 2009 at 9:46 PM, KP horse.headed.fish@gmail.com
 wrote:
 
   Hello,
 
   Doing that appears not to help the issue. The thing I called
   customJSStr above now looks like
 
   document.getElementById('foo').innerHTML = 'lift:a
   key=F859002372055OWMbar/lift:a';
 
   (with 's properly handled by encJs), and the behavior appears to be
   unchanged. Is there some sort of setup of the lift:a that doesn't
   get to take place when I update the page like this, perhaps?
 
   Thanks much,
   KP
 
   On Sep 22, 9:55 pm, David Pollak feeder.of.the.be...@gmail.com
   wrote:
On Tue, Sep 22, 2009 at 7:49 PM, KP horse.headed.fish@gmail.com
 
   wrote:
 
 Hi all.
 
 I have essentially the following setup in a website:
 
 class AjaxTest {
   def render =
  div
 div id=foofoo/div
 {getAjaxForm}
  /div
 
   def getAjaxForm = SHtml.ajaxForm(
 SHtml.submit(submit, () = ()),
 Run(customJSStr))
 
   def customJSStr = document.getElementById('foo').innerHTML = '
 +
 aStr + ';
 
If aStr contains a single or double quote or a non-printable or
 non-ascii
character, your expression will fail (it will be invalid JavaScript).
 
I would suggest:
 
def customJSStr = document.getElementById('foo').innerHTML = 
   +aStr.encJs
+ ;
 
That will properly escape the string as a JavaScript string.
 
   val aStr = SHtml.a(() = SetHtml(foo, Text(baz)), Text
 (bar)).toString
 }
 
 when aStr is displayed (with text 'bar'), the link is inactive.
 
 I'm using Run(customJSStr) instead of SetHtml as, in the actual
 app,
 the situation is slightly more complicated (and the RHS of the
 assignment operator in the javascript expression has some more
 stuff
 fetched from the document).
 
 Note also that if the ajaxForm uses SetHtml() instead of Run() it
 works as expected.
 
 So the question is -- is there a straightforward explanation for
 what's going on here (I'm still kinda cargo-culting lift).
 
 And, unconditional upon the answer to the last question, is there a
 way to make aStr a valid, active link (or, I guess, string
 representing one) while retaining the ability to have an
 arbitrarily
 complex javascript expression in customJSStr (this would actually
 be
 defined in a separate js file, of course).
 
 Thanks much,
 KP
 
--
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
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Surf the harmonics

 



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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to 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 can I replace SHtml.a with a Loc

2009-09-28 Thread David Pollak
On Fri, Sep 25, 2009 at 10:28 AM, glenn gl...@exmbly.com wrote:


 David,

 In this case, I was trying to see if there was a way to use the
 standard Lift
 menu generator to create a link with a callback for ajax handling,
 similar to SHtml.a.
 I don't know about menu generation from SiteMap. Perhaps that's what I
 really
 need. What would that look like?


Sorry... I'm being dense.  Do you want to have links generated by the Menu
snippet that are Ajax or do you want to change the contents of the menu
based on an Ajax request?


 Glenn

 On Sep 25, 8:22 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  On Fri, Sep 25, 2009 at 8:13 AM, glenn gl...@exmbly.com wrote:
 
   David,
 
   Thanks for the reply. The Loc, itself, though. How do I write that
   to create the Ajax link. I want to be able to modify an html element
   when the link is clicked, as in SetHtml(item-save, edit(item)).
 
  Sorry... didn't quite understand.
 
  Are you using your own menu generator or the standard Lift menu
 generator?
 
  I'm thinking that we have to uniquely identify (put a knowable id on)
 each
  a href that is generated.  If you're doing your own menu generation
 from
  SiteMap, you can probably get your code to work by using the name of the
 Loc
  as the id.  If you're using the standard Lift Menu snippet to create your
  menus, you'll have to open a ticket, I'll prioritize the ticket, then
 we'll
  wait for review board and then you'll get your change.
 
 
 
 
 
   Glenn
 
   On Sep 24, 5:05 pm, David Pollak feeder.of.the.be...@gmail.com
   wrote:
val myLoc: Loc[_] = ...
 
bind(item, xhtml, addNew - a
   href={myLoc.createDefaultLink}Hello/a)
 
On Wed, Sep 23, 2009 at 11:25 AM, glenn gl...@exmbly.com wrote:
 
 I have a snippet that creates a Ajax link.
 
 bind(item, xhtml,
addNew - {SHtml.a({ ()=
  SetHtml(item-save, edit(item))},
  Text(MenuTitle_Add)
  )}
 )
 
 How would I, instead, create the same or similar link using a Loc?
 
 Glenn
 
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Surf the harmonics
 



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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to 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 and Hibernate validators

2009-09-28 Thread Derek Chen-Becker
The simplest would be to define your own getter/setter pairs just like you
would in Java and put the annotations there. Ugly, but it should work.

On Mon, Sep 28, 2009 at 1:41 AM, etorreborre etorrebo...@gmail.com wrote:


 Hi,

 I'm trying to get a Lift/JPA demo rolling but I can't get Scala work
 with Hibernate validators (as it has been noticed before:
 https://lampsvn.epfl.ch/trac/scala/ticket/1846,
 https://lampsvn.epfl.ch/trac/scala/ticket/2245,
 https://lampsvn.epfl.ch/trac/scala/ticket/2252).

 My question is: what's your preferred workaround for this issue when
 using Lift/JPA?

 Thanks,

 Eric.
 


--~--~-~--~~~---~--~~
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] Java 5 support?

2009-09-28 Thread Derek Chen-Becker
I was just about to work on issue #67 (build breaks on Java 5), but when I
went to get a Java 5 JDK to compile/test with, Sun says that it's EOL as of
October 30, 2009. I don't have a problem fixing things to work with Java 5,
but I don't want to do work that's going to be tossed out in a month.

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: RFC: Restructuring Lift Codebase

2009-09-28 Thread Timothy Perrett

Indrajit,

What is the purpose of lift-resources? We cannot make the lift  
installer part of the build process - belive me, i've looked into this  
extensively... basically, it boils down to needed install4j licensed  
on that machines which would be a stupid requirement to place on any  
person building the sources - so we wont be doing that ;-)

What the hell is lift-site-skin?

Cheers, Tim

On 27 Sep 2009, at 21:44, Indrajit Raychaudhuri wrote:


 Folks,

 As followup to the proposed goal of Keeping lift-core neat and
 small, here is the first iteration of the revised structure of Lift
 codebase.


 liftweb

 - lift-core [10]
  - lift-base [02]
  - lift-actor
  - lift-util
  - lift-json [03]
  - lift-webkit [04]
  - lift-testkit [05]

 - lift-persistence [06]
  - lift-mapper
  - lift-record
  - lift-jpa

 - lift-modules [07]
  - lift-osgi
  - lift-wizard [08]
  - lift-widgets [09]
  - lift-machine
  - lift-textile
  - lift-facebook
  - lift-amqp
  - lift-xmpp
  - lift-openid
  - lift-oauth
  - lift-paypal
  - lift-jta

 - lift-archetypes
  - ...

 - lift-examples
  - ...

 - lift-site [10]

 - lift-resources [lift-varia, lift-infra ?] [11]
  - lift-root-model [12]
  - lift-site-skin
  - lift-installer
  - misc config resources (scaladoc, javadoc etc.)

 General notes (including some obvious ones):

 [A] lift-* prefix looks superfluous, but it's best to have one for all
 artifacts that generate jar (packagingjar/packaging). Also Maven
 reactor feels happier when artifactId == directory_name (site
 generation, scm extrapolation etc., situation might have improved
 now).

 [B] The top level project categories (lift-core, lift-persistence,
 lift-modules etc.) are simple multi-module models at the moment and
 not meant to create anything other than pom. Therefore, lift-* prefix
 can go away. But they'll have to come back if we plan to generate 'one
 jar' in assembly mode per category (lift-core-all.jar, lift-
 persistence-all.jar etc.). This could be useful for 'get me
 everything, I don't care about size' people. But is it necessary? The
 alternative is to have empty 'meta modules' that pull up the necessary
 dependencies and can be included by the users in their project (quite
 similar to what lift-core does now).

 [C] The members in a project category (lift-mapper, lift-record etc.)
 would inherit the category model (lift-persistence in case of lift-
 mapper, lift-record). Related modules clubbed together helps similar
 configuration pulled up to the parent pom (improves DRY-ness). Added
 benefit: modules can be developed even outside Lift codebase with the
 given parent pom (available in global repo) and the developer won't
 have to worry about most of the infra related boilerplate
 configurations (couple of config still would need change though).

 [D] Presentations and other materials aren't really source code for
 inclusion in source repository. Can this go in wiki? (immediate
 problem: github doesn't take attachment). Has this been discussed
 earlier? They can go as a separate github project too.

 [E] The categorization is mostly based on my interpretation as a late
 entrant. If there is a different structure that fits the philosophy
 better (quite likely), this would get regrouped. (Tim ?)

 [F] The modules in a category can be further sub-grouped, but with
 caution. Basically, need the right mix between 'flat'-ness and deep
 nesting. Thoughts on this?

 [G] Each category can eventually be split up into separate projects
 and have their own release schedules (less frequent for core, more
 frequent for modules etc.). This might be little overkill at the
 moment. Just mentioned to enable us mind the long term perspective :)

 [H] Other points on the draft hierarchy (see the # in brackets above):

 [01] With these members, if lift-core doesn't sound as the right name,
 we need the right name. Provided the grouping is right that is.

 [02] Base interfaces for Lift (currently present in dpp_wip_actorized)

 [03] Doesn't really have to be part of Lift core in current form, but
 this is eventually meant to be part of Lift's JS infrastructure (thus
 kept here at the moment)

 [04] Candidate for decomposition. But kept intact at the moment. Would
 be taken up in next pass once the top level reaches steady state. This
 could either become a category of its own or a module with submodules.

 [05] Little unsure about it's intent and purpose, I could be
 completely mis-interpreting this. Thoughts from somebody with more
 understanding please :)

 [06] Doesn't have to be part of lift-core. Lift applications not using
 persistence doesn't have to need this.

 [07] Extra stuff, necessary iff one needs. Right now, I am putting
 'everything else' here for lack of better place, but I see a scaling
 up issue there. This can turn out to be a place for all the 'nowhere
 else to go' modules. But we can take it up in next pass. Suggestions?

 [08][09] See #04 above. Can be subpackage of lift-webkit eventually

 [10] 

[Lift] Re: Db.addLogFunc

2009-09-28 Thread Derek Chen-Becker
I can't rule it out, but because the new logging implements methods on
java.sql.Statement that don't exist in Java 5, I would expect some
classloading issues or exceptions.

On Mon, Sep 28, 2009 at 11:47 AM, David Pollak 
feeder.of.the.be...@gmail.com wrote:

 Could this be a JDK 1.5 vs. 1.6 issue?


 On Mon, Sep 28, 2009 at 10:43 AM, David david.b...@gmail.com wrote:


 Nope, changed to println():

DB.addLogFunc {
  case (query, time) = {
  println(All queries took  + time + ms: )
  query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
 println(stmt +  took  + duration + ms)})
println(End queries)
  }
}

 Nothing on console.

 Thanks, David

 On Sep 28, 1:36 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
  I tested it locally on my own code and it works. Just for giggles, does
  anything print on the console if you change those lines to println?
 
  Derek
 
  On Wed, Sep 23, 2009 at 2:39 PM, David david.b...@gmail.com wrote:
 
   Hello, I'm trying to use the new logging information as described
   here.  In my Boot I have:
 
   import net.liftweb.mapper.{DB, DBLogEntry}
   snip...
 
  DB.addLogFunc {
case (query, time) = {
   Log.info(All queries took  + time + ms: )
   query.allEntries.foreach({ case DBLogEntry(stmt, duration) =
  Log.info(stmt +  took  + duration + ms)})
  Log.info(End queries)
}
  }
 
   I'm using slf4j and logback, my root level is set to trace.  I see
   trace output from lift, like:
   16:32:02.208 [5991...@qtp-10429832-0] TRACE lift.trace:76 - Released
   connection ConnectionIdentifier(lift) on thread Thread
   [5991...@qtp-10429832-0,5,main]
 
   But I don't see any output from the DB log functions.   Is there
   anything else I need to do in order to enable logging?  I'm using
   scala 2.7.5 and lift 1.1-SNAPSHOT.
 
   Thanks, Dave
 
   On Aug 28, 1:20 pm, marius d. marius.dan...@gmail.com wrote:
EXCELLENT WORK DEREK !
 
On Aug 28, 7:28 pm, Derek Chen-Becker dchenbec...@gmail.com
 wrote:
 
 Hi all,
 I've made a change to the Mapper logging functionality in
 wip-dcb-sql-log-wrappers. The DB.addLogFuncmethod has changed to:
 
addLogFunc( f: (DBLog,Long) = Any)
 
 where DBLog is a new trait (below) and the Long corresponds to the
   *total*
 duration of a given DB execution method. DBLog is defined as:
 
 trait DBLog {
   ... private stuff up here ...
   /** Return a list of all of the DBStatementEntry instances in
 the log
 buffer */
   def statementEntries : List[DBStatementEntry] = ...
 
   /** Return a list of all of the DBMetaEntry instances in the log
   buffer */
   def metaEntries : List[DBMetaEntry] = ...
 
   /** Return all log buffer entries */
   def allEntries : List[DBLogEntry] = ...
 
 }
 
 and we have some new event class/traits:
 
 trait DBLogEntry {
   def statement : String
   def duration : Long}
 
 object DBLogEntry {
   def unapply(obj : Any) = obj match {
 case entry : DBLogEntry =
 Some(entry.statement,entry.duration)
 case _ = None
   }}
 
 case class DBStatementEntry(statement : String, duration : Long)
   extends
 DBLogEntry
 case class DBMetaEntry(statement : String, duration : Long)
 extends
 DBLogEntry
 
 Statements are SQL statements, prepared or immediate, and meta
 entries
 correspond to things like getMaxRows, getGeneratedKeys, etc. As
 you can
   see,
 each individual statement records its own duration as well, so you
 can
   get
 fine-grained detail on all activity. An example log function in
 Boot
   could
 look like:
 
 DB.addLogFunc{
   case (query, time) = {
 Log.info(All queries took  + time + ms: )
 query.allEntries.foreach({ case DBLogEntry(stmt, duration)
 =
 Log.info(stmt +  took  + duration + ms)})
 Log.info(End queries)
   }
 }
 
 And we get output like:
 
 INFO - All queries took 17ms:
 INFO - Exec update INSERT INTO users
 
  
 (lastname,locale,password_pw,password_slt,validated,uniqueid,timezone,firstname,email,superuser,textarea)
 VALUES
 
  
 (C,en_US,GzwLqDpmJ6TrECg06bGKvOAQxyc=,1JTAWGSSYLJHXASO,1,DU0G0RT3IFOA0NHSY5QQQTX42BOIHDGI,US/Mountain,D,
 d...@c.com,0,) : updated 1 rows took 9ms
 INFO - Get generated keys : rs =
 oracle.jdbc.driver.oraclereturnresult...@23f9e6e5 took 2ms
 INFO - Closed Statement took 0ms
 INFO - End queries
 
 Note that this code does introduce a breaking change if you're
 already
   using
 log functions, since theaddLogFuncsignature has changed. If I can
 get a
 review on the code before I merge to master I would appreciate it.
 
 Derek
 
 On Sat, Aug 15, 2009 at 8:02 AM, Derek Chen-Becker 
   dchenbec...@gmail.comwrote:
 
  OK, a preliminary version of log wrappers is checked in on
  

[Lift] Re: Java 5 support?

2009-09-28 Thread Timothy Perrett

Hmm - had this problem the other day. The only real downside of not  
letting it build on 1.5 from my position is that people on Mac will  
need to tweak the PATH because the default JDK is 5, not 6 (which is  
installed too, oddly)

Might be some others, but I cant think of them.

Cheers, Tim

On 28 Sep 2009, at 19:14, Derek Chen-Becker wrote:

 I was just about to work on issue #67 (build breaks on Java 5), but  
 when I went to get a Java 5 JDK to compile/test with, Sun says that  
 it's EOL as of October 30, 2009. I don't have a problem fixing  
 things to work with Java 5, but I don't want to do work that's going  
 to be tossed out in a month.

 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: Java 5 support?

2009-09-28 Thread David Pollak
On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker
dchenbec...@gmail.comwrote:

 My main concern is that after October 30, Java 5 costs money (I'm guessing
 not a trivial amount, either). I can get the JDK right now, but if some bug
 in the Java libraries pops up that would prevent things from working, I
 don't know how we'll work around that.


I don't see the condition under which that could happen.  When we compile
against Java 1.5, we are simply defining the contract between our classes
and the library classes.  None of the library seeps into our code (this is
not true of Scala traits).  So, as long as the running library has the
classes/methods that we are calling, we're fine.  Compiling against 1.5
simply means that we have fewer calls that we can make.  If there is an
issue in 1.5 that a user is experiencing, that is the user's issue, not
ours.  If the code compiles (and runs tests) against 1.5 and does not
generate the particular issue that the user is seeing under 1.6, then that
use has to contact Sun, not us.



 Derek

 On Mon, Sep 28, 2009 at 12:29 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I was just about to work on issue #67 (build breaks on Java 5), but when
 I went to get a Java 5 JDK to compile/test with, Sun says that it's EOL as
 of October 30, 2009. I don't have a problem fixing things to work with Java
 5, but I don't want to do work that's going to be tossed out in a month.


 Lift will be JDK 1.5 compatible for at least 1 year (and probably longer).
  LinkedIn and SAP are both 1.5 shops.  There are tons of other Bay Area
 companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops.  For the next
 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks == 1.5.

 It will not be lost work.


 Derek





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





 



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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to 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: [scala] EclipseLink?

2009-09-28 Thread Meredith Gregory
Dear Ismael,

Thanks. i knew about that and tried it. My version of maven barf'ed on the
download url and so it didn't work for me. i would much prefer not to have
to ferret out and maintain the jar myself. ;-)

Best wishes,

--greg

On Mon, Sep 28, 2009 at 12:56 PM, Ismael Juma mli...@juma.me.uk wrote:

 Hey Greg,

 On Mon, 2009-09-28 at 10:57 -0700, Meredith Gregory wrote:
  Is there maven support?

 http://wiki.eclipse.org/EclipseLink/Maven

 Ismael




-- 
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: Java 5 support?

2009-09-28 Thread David Pollak
Crud.  This just isn't going to be easy, is it?

On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Another issue, which may be more problematic, is that in my case I'm
 compiling against the java.sql.Statement interface. If I remove the
 troublesome methods so that it compiles for 1.5, it no longer compiles for
 1.6 because of the missing methods:

 [WARNING]
 /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:70:
 error: class LoggedStatement needs to be abstract, since method isPoolable
 in trait Statement of type ()Boolean is not defined
 [WARNING] class LoggedStatement(underlying : Statement) extends Statement
 with DBLog {
 [WARNING]   ^
 [WARNING]
 /home/software/liftweb/lift-mapper/src/main/scala/net/liftweb/mapper/LoggingStatementWrappers.scala:267:
 error: class LoggedPreparedStatement needs to be abstract, since method
 setNClob in trait PreparedStatement of type (Int,java.io.Reader)Unit is not
 defined
 [WARNING] class LoggedPreparedStatement (stmt : String, underlying :
 PreparedStatement) extends LoggedStatement(underlying) with
 PreparedStatement {
 [WARNING]   ^


 Derek


 On Mon, Sep 28, 2009 at 2:29 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 The issue (and I may be overthinking this) is that we need 1.5 class
 libraries to compile against if we want to be able to verify that the code
 compiles under 1.5. If I, say, delete my JDK 5 install and decide to
 reinstall it down the road, it's not going to be available without a
 purchased license.


 I can stash away a bunch of different copies of the JDK and give them to
 you when you need them.

 A 32 bit Linux JDK 1.5 should be enough to at least do smoke test builds
 with.



 Derek



 On Mon, Sep 28, 2009 at 1:33 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 My main concern is that after October 30, Java 5 costs money (I'm
 guessing not a trivial amount, either). I can get the JDK right now, but 
 if
 some bug in the Java libraries pops up that would prevent things from
 working, I don't know how we'll work around that.


 I don't see the condition under which that could happen.  When we
 compile against Java 1.5, we are simply defining the contract between our
 classes and the library classes.  None of the library seeps into our code
 (this is not true of Scala traits).  So, as long as the running library has
 the classes/methods that we are calling, we're fine.  Compiling against 1.5
 simply means that we have fewer calls that we can make.  If there is an
 issue in 1.5 that a user is experiencing, that is the user's issue, not
 ours.  If the code compiles (and runs tests) against 1.5 and does not
 generate the particular issue that the user is seeing under 1.6, then that
 use has to contact Sun, not us.



 Derek

 On Mon, Sep 28, 2009 at 12:29 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 I was just about to work on issue #67 (build breaks on Java 5), but
 when I went to get a Java 5 JDK to compile/test with, Sun says that 
 it's EOL
 as of October 30, 2009. I don't have a problem fixing things to work 
 with
 Java 5, but I don't want to do work that's going to be tossed out in a
 month.


 Lift will be JDK 1.5 compatible for at least 1 year (and probably
 longer).  LinkedIn and SAP are both 1.5 shops.  There are tons of other 
 Bay
 Area companies (Wells Fargo, Kaiser, etc.) that are also 1.5 shops.  For 
 the
 next 2-3 years, OS X 10.5 will be common and 10.5 + old MacBooks == 1.5.

 It will not be lost work.


 Derek





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









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








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




 



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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to 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: Java 5 support?

2009-09-28 Thread Ross Mellgren
In some code we have at work that has to support Java 1.6 and down for  
certain things, we had to resort to having multiple versions and  
dynamically Class.forName the right one in at runtime. I would be  
overjoyed to hear of a better solution :-/

-Ross

On Sep 28, 2009, at 6:00 PM, David Pollak wrote:

 Crud.  This just isn't going to be easy, is it?

 On Mon, Sep 28, 2009 at 2:04 PM, Derek Chen-Becker dchenbec...@gmail.com 
  wrote:
 Another issue, which may be more problematic, is that in my case I'm  
 compiling against the java.sql.Statement interface. If I remove the  
 troublesome methods so that it compiles for 1.5, it no longer  
 compiles for 1.6 because of the missing methods:

 [WARNING] /home/software/liftweb/lift-mapper/src/main/scala/net/ 
 liftweb/mapper/LoggingStatementWrappers.scala:70: error: class  
 LoggedStatement needs to be abstract, since method isPoolable in  
 trait Statement of type ()Boolean is not defined
 [WARNING] class LoggedStatement(underlying : Statement) extends  
 Statement with DBLog {
 [WARNING]   ^
 [WARNING] /home/software/liftweb/lift-mapper/src/main/scala/net/ 
 liftweb/mapper/LoggingStatementWrappers.scala:267: error: class  
 LoggedPreparedStatement needs to be abstract, since method setNClob  
 in trait PreparedStatement of type (Int,java.io.Reader)Unit is not  
 defined
 [WARNING] class LoggedPreparedStatement (stmt : String, underlying :  
 PreparedStatement) extends LoggedStatement(underlying) with  
 PreparedStatement {
 [WARNING]   ^


 Derek


 On Mon, Sep 28, 2009 at 2:29 PM, David Pollak feeder.of.the.be...@gmail.com 
  wrote:


 On Mon, Sep 28, 2009 at 1:19 PM, Derek Chen-Becker dchenbec...@gmail.com 
  wrote:
 The issue (and I may be overthinking this) is that we need 1.5 class  
 libraries to compile against if we want to be able to verify that  
 the code compiles under 1.5. If I, say, delete my JDK 5 install and  
 decide to reinstall it down the road, it's not going to be available  
 without a purchased license.

 I can stash away a bunch of different copies of the JDK and give  
 them to you when you need them.

 A 32 bit Linux JDK 1.5 should be enough to at least do smoke test  
 builds with.


 Derek



 On Mon, Sep 28, 2009 at 1:33 PM, David Pollak feeder.of.the.be...@gmail.com 
  wrote:


 On Mon, Sep 28, 2009 at 11:51 AM, Derek Chen-Becker dchenbec...@gmail.com 
  wrote:
 My main concern is that after October 30, Java 5 costs money (I'm  
 guessing not a trivial amount, either). I can get the JDK right now,  
 but if some bug in the Java libraries pops up that would prevent  
 things from working, I don't know how we'll work around that.

 I don't see the condition under which that could happen.  When we  
 compile against Java 1.5, we are simply defining the contract  
 between our classes and the library classes.  None of the library  
 seeps into our code (this is not true of Scala traits).  So, as  
 long as the running library has the classes/methods that we are  
 calling, we're fine.  Compiling against 1.5 simply means that we  
 have fewer calls that we can make.  If there is an issue in 1.5 that  
 a user is experiencing, that is the user's issue, not ours.  If the  
 code compiles (and runs tests) against 1.5 and does not generate the  
 particular issue that the user is seeing under 1.6, then that use  
 has to contact Sun, not us.


 Derek

 On Mon, Sep 28, 2009 at 12:29 PM, David Pollak feeder.of.the.be...@gmail.com 
  wrote:


 On Mon, Sep 28, 2009 at 11:14 AM, Derek Chen-Becker dchenbec...@gmail.com 
  wrote:
 I was just about to work on issue #67 (build breaks on Java 5), but  
 when I went to get a Java 5 JDK to compile/test with, Sun says that  
 it's EOL as of October 30, 2009. I don't have a problem fixing  
 things to work with Java 5, but I don't want to do work that's going  
 to be tossed out in a month.


 Lift will be JDK 1.5 compatible for at least 1 year (and probably  
 longer).  LinkedIn and SAP are both 1.5 shops.  There are tons of  
 other Bay Area companies (Wells Fargo, Kaiser, etc.) that are also  
 1.5 shops.  For the next 2-3 years, OS X 10.5 will be common and  
 10.5 + old MacBooks == 1.5.

 It will not be lost work.

 Derek





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









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








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








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

 



[Lift] Re: Seeking for Simple Sample .scala and .html that mimics CRUDify/Seam-Gen

2009-09-28 Thread yk

Dont mind my previous message. I've finally located
net.liftweb.example package from git.

The Simple example is exactly what I am looking for.

Cheers

On Sep 28, 8:45 pm, yk ying.kwang...@gmail.com wrote:
 I have had plowing through the internet for two weeks now, for a
 simple tutorial that can point me in the right direction to catch on
 the Lift/Scala bandwagon.

 I am a CodeCharge studio coder and have had exposed toseam-gen codes
 deploying on JBoss AS at the rookie level.

 I had tried RoR and have liked the instant gratification joy but not
 the performance issue(s) that I stumbled across on the internet.

 At this junction, I had went through examples of Starting with Lift,
 Exploring Lift, and the tutorial from IBM involving Comet. I had also
 went through the OneToMany tutorial on Wiki (along with source code)
 and the ManyToMany (UserMon) example from one of the posting.

 I believe Scala/Lift will be the probable solution for the portal I am
 building and wish for some additional help.

 I am shamelessly asking for a bunch of sample codes (Both snippets and
 html) of the OneToMany tutorial (the one involving Author and Book)
 that mimics CRUDify/Seam-Gen generated code with clear add/remove/
 update/delete defs so a noob like myself can understand better =S

 Thank you in advance.
     yk

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