[Lift] LiftRules.jQueryVersion ... :(

2010-02-23 Thread Marius
Guys,

This has been added not so long ago, and I am aware that I should
express my perspective on this back then as now it might be too late.
IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
ResourceServer should not even be aware of the underlying JS framework
thus the JQuery  name in LiftRules is very unsound to me.


Here is other proposal of keeping things decoupled:

.
We currently have JQueryArtifacts which holds the JQuery
implementation.

We add in the JsArtifacts this:

trait JsArtifacts {
  ...
  def version
}

then

case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
  def version = 1.3.2-min
}

case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
  def version = 1.4.1-min
}

Then to select one or another we use the existent mechanism:

LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
can change this easily


then in ResourceServer we can easily make the version selection.


In this way LiftRules has no idea about JQuery, YUI etc  and it
doesn't need to. it is only about feeding different implementations of
JsArtifact.

Thoughts?

Br's,
Marius

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



Re: [Lift] LiftRules.jQueryVersion ... :(

2010-02-23 Thread Jeppe Nejsum Madsen
+1 (and we might as well add 1.4.2 as well/instead :-)

On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
 Guys,

 This has been added not so long ago, and I am aware that I should
 express my perspective on this back then as now it might be too late.
 IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
 ResourceServer should not even be aware of the underlying JS framework
 thus the JQuery  name in LiftRules is very unsound to me.


 Here is other proposal of keeping things decoupled:

 .
 We currently have JQueryArtifacts which holds the JQuery
 implementation.

 We add in the JsArtifacts this:

 trait JsArtifacts {
  ...
  def version
 }

 then

 case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
  def version = 1.3.2-min
 }

 case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
  def version = 1.4.1-min
 }

 Then to select one or another we use the existent mechanism:

 LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
 can change this easily


 then in ResourceServer we can easily make the version selection.


 In this way LiftRules has no idea about JQuery, YUI etc  and it
 doesn't need to. it is only about feeding different implementations of
 JsArtifact.

 Thoughts?

 Br's,
 Marius

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



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



[Lift] Re: LiftRules.jQueryVersion ... :(

2010-02-23 Thread Marius
(yeah forgive me :) ...)

On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 +1 (and we might as well add 1.4.2 as well/instead :-)



 On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
  Guys,

  This has been added not so long ago, and I am aware that I should
  express my perspective on this back then as now it might be too late.
  IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
  ResourceServer should not even be aware of the underlying JS framework
  thus the JQuery  name in LiftRules is very unsound to me.

  Here is other proposal of keeping things decoupled:

  .
  We currently have JQueryArtifacts which holds the JQuery
  implementation.

  We add in the JsArtifacts this:

  trait JsArtifacts {
   ...
   def version
  }

  then

  case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
   def version = 1.3.2-min
  }

  case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
   def version = 1.4.1-min
  }

  Then to select one or another we use the existent mechanism:

  LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
  can change this easily

  then in ResourceServer we can easily make the version selection.

  In this way LiftRules has no idea about JQuery, YUI etc  and it
  doesn't need to. it is only about feeding different implementations of
  JsArtifact.

  Thoughts?

  Br's,
  Marius

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

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



[Lift] Re: Comet issue for Lift-2.0-scala280-SNAPSHOT

2010-02-23 Thread tbje
Excellent! The fix (merged from branch) solved all my 2.8 porting
issues so far.

Thank you for solving this problem so quickly!

On 23 Feb, 00:20, David Pollak feeder.of.the.be...@gmail.com wrote:
 On Mon, Feb 22, 2010 at 3:15 PM, Arie arie.lake...@gmail.com wrote:
  Hi,

  Can I clarify, is this a general issue to do with 2.8 Scala/Comet
  Actors?  I think I may be having the same problem.

 It's not CometActors that are causing the issue.  In Scala 2.8, XML Node
 equality testing is changed and supplying a label method that returns a
 String (rather than Nothing) is a requirement.  The fix for this issue is on
 Review Board and has been approved.  I'll likely get it rolled into
 master/280_port_refresh tomorrow.







  Arie

  On Feb 22, 12:02 pm, Indrajit Raychaudhuri indraj...@gmail.com
  wrote:
   Understood, just wanted to ensure.

   Cheers, Indrajit

   On 22/02/10 4:25 PM, tbje wrote:

Hi Indrajit,
I was a little bit lazy and updated an old pom by hand.

Just pushed a new pom.xml using the following mvn
archetype:generate :

mvn archetype:generate -U -DarchetypeGroupId=net.liftweb -
DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=2.0-
scala280-SNAPSHOT -DarchetypeRepository=http://scala-tools.org/repo-
snapshots -DremoteRepositories=http://scala-tools.org/repo-snapshots

Didn't solve the problem :(

Best regards
Trond

On 19 Feb, 16:32, Indrajit Raychaudhuriindraj...@gmail.com  wrote:
Trond,

  From cursory glance it appears that some old form of archetype (pre
   Lift2.0) had been used to generate the project. What command line
option did you use in mvn archetype:generate to create the project?

This is just a request for qualification.

Cheers, Indrajit

On 19/02/10 8:22 PM, tbje wrote:

Thank you for rapid replies and a great framework. I opened ticket
#357 for this issue.

Best regards
Trond

On 19 Feb, 15:22, Mariusmarius.dan...@gmail.com    wrote:
Yeah AFAIK Scala 2.8 integration is not 100% done and fully tested.

Br's,
Marius

On Feb 19, 3:52 pm, tbjetrond.bjerkestr...@gmail.com    wrote:

Hi Marius,
I discovered the issue while porting a working application from
  2.7.7
tolift2.0-scala280-SNAPSHOT and scala 2.8.0.Beta1.

In the example application I provided it's possible to change the
pom.xml by replacing
    scala.version2.8.0.Beta1/scala.version
    lift.version2.0-scala280-SNAPSHOT/lift.version
with
    scala.version2.7.7/scala.version
    lift.version2.0-SNAPSHOT/lift.version
and the application is working as I'd like it to :)

I therefor believe it's alift2.0-scala280 issue.

Best regards
Trond

On 19 Feb, 14:12, Mariusmarius.dan...@gmail.com    wrote:

Can you also try with Scala 2.7.7 ?

On Feb 19, 2:26 pm, tbjetrond.bjerkestr...@gmail.com    wrote:

Hi,
I've been testing out theLift-2.0-scala280-SNAPSHOT a little bit
  and
found a issue with Cometactor, setHtml and ajaxInvoke.

When trying to invoke the following partial update nothing seems
  to
happen:
partialUpdate(SetHtml(field,input type=button
onclick={ajaxInvoke(() =    JsRaw(alert('hi')))._2} value=Say
  hi /

))

This works as expected however:
partialUpdate(SetHtml(field, a(() =    JsRaw(alert('hi')),
spanLink/span)))

I've created a example app to illustrate the problem if someone
  is
interested:

git://github.com/tbje/Lift-2.0-scala280-SNAPSHOT-issue.git

Best regards
Trond

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

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

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



[Lift] Re: LiftRules.jQueryVersion ... :(

2010-02-23 Thread Marius
I opened this ticket: 
http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryversion-should-not-be-there-

I realize that this would bring a slight breaking change but I believe
it is worth it.

Folks please speak up if you think otherwise.

Br's,
Marius

On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
 (yeah forgive me :) ...)

 On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:



  +1 (and we might as well add 1.4.2 as well/instead :-)

  On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
   Guys,

   This has been added not so long ago, and I am aware that I should
   express my perspective on this back then as now it might be too late.
   IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
   ResourceServer should not even be aware of the underlying JS framework
   thus the JQuery  name in LiftRules is very unsound to me.

   Here is other proposal of keeping things decoupled:

   .
   We currently have JQueryArtifacts which holds the JQuery
   implementation.

   We add in the JsArtifacts this:

   trait JsArtifacts {
    ...
    def version
   }

   then

   case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
    def version = 1.3.2-min
   }

   case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
    def version = 1.4.1-min
   }

   Then to select one or another we use the existent mechanism:

   LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
   can change this easily

   then in ResourceServer we can easily make the version selection.

   In this way LiftRules has no idea about JQuery, YUI etc  and it
   doesn't need to. it is only about feeding different implementations of
   JsArtifact.

   Thoughts?

   Br's,
   Marius

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

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



Re: [Lift] Re: LiftRules.jQueryVersion ... :(

2010-02-23 Thread Timothy Perrett
No, sounds good Marius... go for it.

Cheers, Tim

On 23 Feb 2010, at 11:00, Marius wrote:

 I opened this ticket: 
 http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryversion-should-not-be-there-
 
 I realize that this would bring a slight breaking change but I believe
 it is worth it.
 
 Folks please speak up if you think otherwise.
 
 Br's,
 Marius
 
 On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
 (yeah forgive me :) ...)
 
 On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 
 
 
 +1 (and we might as well add 1.4.2 as well/instead :-)
 
 On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
 Guys,
 
 This has been added not so long ago, and I am aware that I should
 express my perspective on this back then as now it might be too late.
 IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
 ResourceServer should not even be aware of the underlying JS framework
 thus the JQuery  name in LiftRules is very unsound to me.
 
 Here is other proposal of keeping things decoupled:
 
 .
 We currently have JQueryArtifacts which holds the JQuery
 implementation.
 
 We add in the JsArtifacts this:
 
 trait JsArtifacts {
  ...
  def version
 }
 
 then
 
 case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
  def version = 1.3.2-min
 }
 
 case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
  def version = 1.4.1-min
 }
 
 Then to select one or another we use the existent mechanism:
 
 LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
 can change this easily
 
 then in ResourceServer we can easily make the version selection.
 
 In this way LiftRules has no idea about JQuery, YUI etc  and it
 doesn't need to. it is only about feeding different implementations of
 JsArtifact.
 
 Thoughts?
 
 Br's,
 Marius
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 

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



[Lift] Re: Cached CSS (and Javascript?) issue

2010-02-23 Thread Marius


On Feb 22, 8:12 pm, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 On Sun, Feb 21, 2010 at 9:49 AM, Marius marius.dan...@gmail.com wrote:
  Guys,

  I'm starting to have second thoughts about having css or js combine
  (concatenation of multiple files into a single response) on lift side.
  I'm starting to question that real benefits as in production sites in
  many cases the lift app has a http reverse proxy front end that can
  serve static content js/css etc. Thus combining multiple js/css with
  simple tools seems more practical.

  Thoughts?

 By simple tools I assume you mean at build time? How would this handle
 classpath resources?

Yes on build time.
/classpath/myresourcescombined.css will reside in the reverse proxy.
This file will reside in the reverse proxy document root.


 I don't think that doing it on the lift side conflicts with the
 reverse proxy. If everything is configured correctly, the proxy should
 only fetch the resource from lift once, see that the resource expires
 far in the future and cache it.

 There are a number of (I think) conflicting scenarios that Lift should 
 support:

 1) Good defaults that deliver great performance out of the box without
 too much hassle during development/build/deploy time. This is where I
 think Lift combining resources would be used.

I somehow disagree. IMO production tuning is necessary regardless of
the web framework used. How do other frameworks behave in this are. I
don't know of any that does the resources combining and claim that
this is preferable then using the reverse proxy.

 2) The absolute best performance no matter what.

I think this is a utopia.In my experience having reverse proxies
serving static content (combined wherever possible) will give you
best performance. The application server should not be burden with
serving static content as long as there are cheap reverse proxies out
there.

 This probably
 includes multiple hosts for static resources, CDNs etc. If you're
 going this route you're willing to sacrifice ease of use for that last
 ounce of speed.

Application performance should be tuned in production environments. I
don't see where the ease of use sacrifice is. Lift apps will
function properly without a reverse proxy but the reverse proxy is
much more suitable for serving static content than the application
server which will be burden with other requests.


 If/when load time becomes an issue for us this will be one of the
 first things I'll try to investigate :-)

 /Jeppe

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



[Lift] Freelance

2010-02-23 Thread donfranciscodequevedo
Hi,
Don't know if this is the right place to ask this, but I'm urgently
seaching for someone experienced with Webservices, Scala and Lift,
interested in implementing a small webservice project based on Lift
Framework.
Detailed DB Specification and API Reference exist.

Timeframe: 1 month
Budget: $1.500



If interested please contact me under donfranciscodequev...@gmail.com.

Best regards

Gregor


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



Re: [Lift] Re: First comet steps

2010-02-23 Thread Nolan Darilek
Cool, thanks for all your help here. It's been quite a bit to digest, 
and I finally got around to revisiting this problem today.


So I'm not sure why my initial attempts to return a lift:embed from 
the render method failed, but today that seems to work. Need to see if 
Firefox is doing anything odd with caching, because I seem to have lots 
of odd problems of this sort. In the meantime, I'll poke at things with 
Curl before claiming that they don't work.


I'm trying to create a cleaner design based on returning lift:embed, but 
I'm still having problems, even after Curl. :) Here's what I have thus far.


My status.html:

lift:surround with=default at=content

h2Imports/h2

lift:comet type=ImportMonitor/
/lift:surround

templateshidden/importing.html, returned by comet render:

table
tr
thName/ththComplete/ththTotal/ththStatus/th
/tr
tr
tdimport:name//td
/tr
/table

And part of my ImportMonitor code:

class ImportMonitor extends CometActor {
...
  def render = {
if(importsCount == 0)
pNo imports are currently in progress./p
else {
  bind(import, lift:embed what=importing/,
name - Name
  )
}
  }

...
}

I've tried a variety of things at that bind call. What it ultimately 
does is returns my template as is, including the 
import:name/import:name. I also tried eager_eval=true on the embed 
element, but with no luck.


Thoughts on what I'm missing? I feel like binding keeps tripping me up. 
I understand the concept, in essence, but it seems like this should work 
to me and I don't see why it isn't.


Thanks for being such a newbie-friendly community.


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



Re: [Lift] Freelance

2010-02-23 Thread David Pollak
On Tue, Feb 23, 2010 at 4:30 AM, donfranciscodequevedo 
donfranciscodequev...@gmail.com wrote:

 Hi,
 Don't know if this is the right place to ask this,


Job postings are always welcome on this list.


 but I'm urgently
 seaching for someone experienced with Webservices, Scala and Lift,
 interested in implementing a small webservice project based on Lift
 Framework.
 Detailed DB Specification and API Reference exist.

 Timeframe: 1 month
 Budget: $1.500



 If interested please contact me under donfranciscodequev...@gmail.com.

 Best regards

 Gregor


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




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

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



Re: [Lift] Textmate bundle with codecompletion (beta)

2010-02-23 Thread Mads Hartmann Jensen
Duh, I comittet a wrong version of the bundle to git! The right version is up 
now if you wan't to give it a try Indrajit :) I would appreciate the feedback:
http://github.com/mads379/Lift-TextMate-Bundle

On 22/02/2010, at 13.12, Mads Hartmann Jensen wrote:

 Don't get too excited, it's very beta right now ;)
 
 Sent from my iPhone
 
 On 22/02/2010, at 13.04, Indrajit Raychaudhuri indraj...@gmail.com wrote:
 
 Heavens! Need to give this a shot.
 
 On 22/02/10 4:55 PM, Mads Hartmann wrote:
 Hello everyone,
 I've been working a bit on a TextMate bundle for Lift projects that
 has codecompletion. It's still very beta but I'm sure someone would
 find it helpfull :)
 
 If you're interested you can read a bit more about it here:
 http://www.sidewayscoding.com/2010/02/lift-textmate-bundle-now-with-primitive.html
 
 NB: It's nowhere near as good as what I've seen in intelliJ (haven't
 tried netbeans or eclipse) but that doesn't mean it isn't helpful :)
 
 If you want to help out, please fork me on github http://github.com/mads379
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 

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



Re: [Lift] Freelance

2010-02-23 Thread Tamer Rizk
Hi Gregor,

Although I am new to Scala/Lift, based on what I have seen you are seriously
undervaluing the community here. I can only hope that your request does not
discourage new talent from investing their time into these technologies.

In my humble opinion, and just my 2c.

Kind Regards,
Tamer


On Tue, Feb 23, 2010 at 2:30 PM, donfranciscodequevedo 
donfranciscodequev...@gmail.com wrote:

 Hi,
 Don't know if this is the right place to ask this, but I'm urgently
 seaching for someone experienced with Webservices, Scala and Lift,
 interested in implementing a small webservice project based on Lift
 Framework.
 Detailed DB Specification and API Reference exist.

 Timeframe: 1 month
 Budget: $1.500



 If interested please contact me under donfranciscodequev...@gmail.com.

 Best regards

 Gregor


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



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



Re: [Lift] Re: Tricky question regarding menus

2010-02-23 Thread Heiko Seeberger
Jeppe,

Thanks for your answer!

On 23 February 2010 08:47, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:


 I have the same scenario and it works for me. In the parent menu I do this:

  Menu(Loc(parent, List(parent, index), Parent, Loc.EarlyResponse(()
 = Full(RedirectResponse(/subpage

 We're using our own menu snippet and I can't recall if this was one of
 the things we changed :-(


Your solution solves one problem: Clicking the parent leads to the child.
But the other problem still exists: doesMatch_? will not return true for the
parent and hence the parent menu will not be treated special (different
style, no link).

Heiko

Work: weiglewilczek.com
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 lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



RE: [Lift] Re: redirectTo in (Stateful)Snippets

2010-02-23 Thread Restel, Hannes
Hi David.
thanks for your answer. It helped me a lot!
Didn't knew that SiteMap disables serving unregistered pages..

Now two more questions to come:

1) citation from David: Second, you can define a subdirectory that all content 
will be served from.
How do I do that?

2) I found out some strange behaviour: I named my page to redirect to 
search.html.
When calling that page, an error occured:
Exception occured while processing /search

Message: java.lang.IllegalArgumentException: line 1 does not exist

scala.io.Source.getLine(Source.scala:280)

scala.io.Source.report(Source.scala:368)

scala.io.Source.reportError(Source.scala:355) (..)
 
When chosing another name for the page then all works fine.
So the question is: is the page name search an reserved keyword in Lift?

Thanks!



Hannes Restel | Fraunhofer Institut für Software- und Systemtechnik
Sichere Business IT-Infrastrukuren, Studentischer Mitarbeiter
Steinplatz 2, 10623 Berlin, Germany
Telefon: +49 (0)30/24 306-324
mailto:hannes.res...@isst.fraunhofer.de
http://www.isst.fraunhofer.de

From: liftweb@googlegroups.com [mailto:lift...@googlegroups.com] On Behalf Of 
David Pollak
Sent: Monday, February 22, 2010 7:20 PM
To: liftweb@googlegroups.com
Subject: Re: [Lift] Re: redirectTo in (Stateful)Snippets


On Mon, Feb 22, 2010 at 1:53 AM, Restel, Hannes 
hannes.res...@isst.fraunhofer.demailto:hannes.res...@isst.fraunhofer.de 
wrote:
Hi Nico,
thanks for your answer.

I think you misunderstood me: I want to redirect to a HTML-page without using a 
SiteMap at all. So the page I redirect to is not registered in any place. It 
simply resides in my 'webapp' folder.
But when trying to redirect to that page, the resource (i.e. my page) is not 
found.

Yes.  This is correct behavior.  If you have defined a SiteMap, Lift will not 
serve any pages except those that are defined in the SiteMap.  If you are using 
Lift  1.0.x, there will be a polite message as part of the 404 informing you 
why the page was not served (if you're running in development mode.)

You have a couple of choices to serve additional pages.  First, you can include 
them in the SiteMap and mark them as Hidden such that there's no menu item 
displayed, but the page will still be served.  Second, you can define a 
subdirectory that all content will be served from.


So please try again :-)

(And yes: I did read The Lift Book :-)

Cheers,
   Hannes



-Original Message-
From: liftweb@googlegroups.commailto:liftweb@googlegroups.com 
[mailto:liftweb@googlegroups.commailto:liftweb@googlegroups.com] On Behalf Of 
Nico Tromp
Sent: Friday, February 19, 2010 2:46 PM
To: Lift
Subject: [Lift] Re: redirectTo in (Stateful)Snippets

Hannes, sorry for the strange :) sentence. It should read:

did you register the page in the Boot class?

If you want to know more about the SiteMap have a look at chapter 5
from the lift book. At the bottom of the page (http://
groups.google.com/group/the-lift-bookhttp://groups.google.com/group/the-lift-book)
 there is a link to the PDF
version.

Happy reading

Nico Tromp

On Feb 19, 1:49 pm, Nico Tromp 
nico.tr...@gmail.commailto:nico.tr...@gmail.com wrote:
 Hannes,

 did you registered the page in the in the Boot class? Below is a small
 example.

 ===
 class Boot {
   def boot {
 // where to search snippet
 // LiftRules.addToPackages(enter your package)

  // Build SiteMap
 val entries = Menu(Loc(Home, List(index), Home)) ::
   Menu(Loc(Search, List(search), Search page)) ::
   Nil
 LiftRules.setSiteMap(SiteMap(entries:_*))
   }}

 ===
 Hope this is helpfull

 Cheers Nico Tromp

 On Feb 19, 1:26 pm, Restel, Hannes



 hannes.res...@isst.fraunhofer.demailto:hannes.res...@isst.fraunhofer.de 
 wrote:
  Hi,

  I am new to Lift (and Scala) and need help with dispatching/redirecting to 
  a page after processing a form.

  My problem: I get a The Requested URL /search was not found on this 
  server error message although the page search.html does exist.

  When adding the page search.html to the LiftRules-SiteMap, then the page 
  does exist!
  So is there any need to register HTML pages? I hope not!

  This is my HTML fragment:
  lift:surround with=default at=content
   h3 class=alt Search
lift:HelloWorld.search form=POST
  entry:searchfield/
  entry:submit/
/lift:HelloWorld.search
   /h3
  /lift:surround

  And this is the corresponding Scala code:
  class HelloWorld extends StatefulSnippet {

override def dispatch:DispatchIt = {
  case search = search _
}

def search(xhtml : NodeSeq) : NodeSeq = {
  object searchExpression extends RequestVar()

  def processSearch () {
if (searchExpression.isEmpty) {
  S.error(Must not be empty!)
}
else {
  S.notice(Value was:  + searchExpression)
  redirectTo(/search)
}
  }

  bind(entry, xhtml,
  searchfield 

Re: [Lift] Re: LiftRules.jQueryVersion ... :(

2010-02-23 Thread Naftoli Gugenheim
You probably mean case object...
Also, personally I prefer the version without the underscores.

-
Timothy Perretttimo...@getintheloop.eu wrote:

No, sounds good Marius... go for it.

Cheers, Tim

On 23 Feb 2010, at 11:00, Marius wrote:

 I opened this ticket: 
 http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryversion-should-not-be-there-
 
 I realize that this would bring a slight breaking change but I believe
 it is worth it.
 
 Folks please speak up if you think otherwise.
 
 Br's,
 Marius
 
 On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
 (yeah forgive me :) ...)
 
 On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 
 
 
 +1 (and we might as well add 1.4.2 as well/instead :-)
 
 On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
 Guys,
 
 This has been added not so long ago, and I am aware that I should
 express my perspective on this back then as now it might be too late.
 IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
 ResourceServer should not even be aware of the underlying JS framework
 thus the JQuery  name in LiftRules is very unsound to me.
 
 Here is other proposal of keeping things decoupled:
 
 .
 We currently have JQueryArtifacts which holds the JQuery
 implementation.
 
 We add in the JsArtifacts this:
 
 trait JsArtifacts {
  ...
  def version
 }
 
 then
 
 case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
  def version = 1.3.2-min
 }
 
 case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
  def version = 1.4.1-min
 }
 
 Then to select one or another we use the existent mechanism:
 
 LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
 can change this easily
 
 then in ResourceServer we can easily make the version selection.
 
 In this way LiftRules has no idea about JQuery, YUI etc  and it
 doesn't need to. it is only about feeding different implementations of
 JsArtifact.
 
 Thoughts?
 
 Br's,
 Marius
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 

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

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



Re: [Lift] Re: redirectTo in (Stateful)Snippets

2010-02-23 Thread David Pollak
On Tue, Feb 23, 2010 at 7:54 AM, Restel, Hannes 
hannes.res...@isst.fraunhofer.de wrote:

  Hi David.

 thanks for your answer. It helped me a lot!

 Didn't knew that SiteMap disables serving unregistered pages..



 Now two more questions to come:



 1) citation from David: Second, you can define a subdirectory that all
 content will be served from.

 How do I do that?


 Menu(Loc(Static, Link(List(static), true, /static/index),
 Static Content))






 2) I found out some strange behaviour: I named my page to redirect to
 search.html.

 When calling that page, an error occured:


There is a problem with the XML in your search.html file.  You should be
using Lift 2.0-M2 or 2.0-SNAPSHOT... you'll get much more polite error
messages.


 Exception occured while processing /search

 Message: java.lang.IllegalArgumentException: line 1 does not exist

 scala.io.Source.getLine(Source.scala:280)

 scala.io.Source.report(Source.scala:368)

 scala.io.Source.reportError(Source.scala:355) (……)

  

 When chosing another name for the page then all works fine.

 So the question is: is the page name search an reserved keyword in Lift?



 Thanks!







 Hannes Restel | Fraunhofer Institut für Software- und Systemtechnik

 Sichere Business IT-Infrastrukuren, Studentischer Mitarbeiter

 Steinplatz 2, 10623 Berlin, Germany

 Telefon: +49 (0)30/24 306-324

 mailto:hannes.res...@isst.fraunhofer.de hannes.res...@isst.fraunhofer.de

 http://www.isst.fraunhofer.de



 *From:* liftweb@googlegroups.com [mailto:lift...@googlegroups.com] *On
 Behalf Of *David Pollak
 *Sent:* Monday, February 22, 2010 7:20 PM
 *To:* liftweb@googlegroups.com
 *Subject:* Re: [Lift] Re: redirectTo in (Stateful)Snippets





 On Mon, Feb 22, 2010 at 1:53 AM, Restel, Hannes 
 hannes.res...@isst.fraunhofer.de wrote:

 Hi Nico,
 thanks for your answer.

 I think you misunderstood me: I want to redirect to a HTML-page without
 using a SiteMap at all. So the page I redirect to is not registered in any
 place. It simply resides in my 'webapp' folder.
 But when trying to redirect to that page, the resource (i.e. my page) is
 not found.


 Yes.  This is correct behavior.  If you have defined a SiteMap, Lift will
 not serve any pages except those that are defined in the SiteMap.  If you
 are using Lift  1.0.x, there will be a polite message as part of the 404
 informing you why the page was not served (if you're running in development
 mode.)

 You have a couple of choices to serve additional pages.  First, you can
 include them in the SiteMap and mark them as Hidden such that there's no
 menu item displayed, but the page will still be served.  Second, you can
 define a subdirectory that all content will be served from.



 So please try again :-)

 (And yes: I did read The Lift Book :-)

 Cheers,
Hannes




 -Original Message-
 From: liftweb@googlegroups.com [mailto:lift...@googlegroups.com] On Behalf
 Of Nico Tromp
 Sent: Friday, February 19, 2010 2:46 PM
 To: Lift
 Subject: [Lift] Re: redirectTo in (Stateful)Snippets

 Hannes, sorry for the strange :) sentence. It should read:

 did you register the page in the Boot class?

 If you want to know more about the SiteMap have a look at chapter 5
 from the lift book. At the bottom of the page (http://
 groups.google.com/group/the-lift-book) there is a link to the PDF
 version.

 Happy reading

 Nico Tromp

 On Feb 19, 1:49 pm, Nico Tromp nico.tr...@gmail.com wrote:
  Hannes,
 
  did you registered the page in the in the Boot class? Below is a small
  example.
 
  ===
  class Boot {
def boot {
  // where to search snippet
  // LiftRules.addToPackages(enter your package)
 
   // Build SiteMap
  val entries = Menu(Loc(Home, List(index), Home)) ::
Menu(Loc(Search, List(search), Search page)) ::
Nil
  LiftRules.setSiteMap(SiteMap(entries:_*))
}}
 
  ===
  Hope this is helpfull
 
  Cheers Nico Tromp
 
  On Feb 19, 1:26 pm, Restel, Hannes
 
 
 
  hannes.res...@isst.fraunhofer.de wrote:
   Hi,
 
   I am new to Lift (and Scala) and need help with dispatching/redirecting
 to a page after processing a form.
 
   My problem: I get a The Requested URL /search was not found on this
 server error message although the page search.html does exist.
 
   When adding the page search.html to the LiftRules-SiteMap, then the
 page does exist!
   So is there any need to register HTML pages? I hope not!
 
   This is my HTML fragment:
   lift:surround with=default at=content
h3 class=alt Search
 lift:HelloWorld.search form=POST
   entry:searchfield/
   entry:submit/
 /lift:HelloWorld.search
/h3
   /lift:surround
 
   And this is the corresponding Scala code:
   class HelloWorld extends StatefulSnippet {
 
 override def dispatch:DispatchIt = {
   case search = search _
 }
 
 def search(xhtml : NodeSeq) : NodeSeq = {
   object searchExpression 

[Lift] What is LDAP doing in modules?

2010-02-23 Thread Timothy Perrett
Hey all,

I see the LDAP has finally been committed... what is it doing in
modules? Its a read / write to LDAP based on record... shouldn't it be
in persistence?

Cheers, Tim

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



Re: [Lift] What is LDAP doing in modules?

2010-02-23 Thread Ross Mellgren
There's no record code in there -- it uses mapper in fact.

I think this is just for auth.

-Ross

On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:

 Hey all,
 
 I see the LDAP has finally been committed... what is it doing in
 modules? Its a read / write to LDAP based on record... shouldn't it be
 in persistence?
 
 Cheers, Tim
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 

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



Re: [Lift] Re: Tricky question regarding menus

2010-02-23 Thread Heiko Seeberger
On 23 February 2010 15:24, Heiko Seeberger
heiko.seeber...@googlemail.comwrote:


 But the other problem still exists: doesMatch_? will not return true for
 the parent and hence the parent menu will not be treated special (different
 style, no link).


Using a custom menu snippet solves the problem. Thanks!

Heiko

Work: weiglewilczek.com
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 lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.



Re: [Lift] Re: Comet issue for Lift-2.0-scala280-SNAPSHOT

2010-02-23 Thread David Pollak
On Tue, Feb 23, 2010 at 1:29 AM, tbje trond.bjerkestr...@gmail.com wrote:

 Excellent! The fix (merged from branch) solved all my 2.8 porting
 issues so far.


Cool.  Please keep identifying issues like this.



 Thank you for solving this problem so quickly!

 On 23 Feb, 00:20, David Pollak feeder.of.the.be...@gmail.com wrote:
  On Mon, Feb 22, 2010 at 3:15 PM, Arie arie.lake...@gmail.com wrote:
   Hi,
 
   Can I clarify, is this a general issue to do with 2.8 Scala/Comet
   Actors?  I think I may be having the same problem.
 
  It's not CometActors that are causing the issue.  In Scala 2.8, XML Node
  equality testing is changed and supplying a label method that returns a
  String (rather than Nothing) is a requirement.  The fix for this issue is
 on
  Review Board and has been approved.  I'll likely get it rolled into
  master/280_port_refresh tomorrow.
 
 
 
 
 
 
 
   Arie
 
   On Feb 22, 12:02 pm, Indrajit Raychaudhuri indraj...@gmail.com
   wrote:
Understood, just wanted to ensure.
 
Cheers, Indrajit
 
On 22/02/10 4:25 PM, tbje wrote:
 
 Hi Indrajit,
 I was a little bit lazy and updated an old pom by hand.
 
 Just pushed a new pom.xml using the following mvn
 archetype:generate :
 
 mvn archetype:generate -U -DarchetypeGroupId=net.liftweb -
 DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=2.0-
 scala280-SNAPSHOT -DarchetypeRepository=
 http://scala-tools.org/repo-
 snapshots -DremoteRepositories=
 http://scala-tools.org/repo-snapshots
 
 Didn't solve the problem :(
 
 Best regards
 Trond
 
 On 19 Feb, 16:32, Indrajit Raychaudhuriindraj...@gmail.com
  wrote:
 Trond,
 
   From cursory glance it appears that some old form of archetype
 (pre
Lift2.0) had been used to generate the project. What command line
 option did you use in mvn archetype:generate to create the
 project?
 
 This is just a request for qualification.
 
 Cheers, Indrajit
 
 On 19/02/10 8:22 PM, tbje wrote:
 
 Thank you for rapid replies and a great framework. I opened
 ticket
 #357 for this issue.
 
 Best regards
 Trond
 
 On 19 Feb, 15:22, Mariusmarius.dan...@gmail.comwrote:
 Yeah AFAIK Scala 2.8 integration is not 100% done and fully
 tested.
 
 Br's,
 Marius
 
 On Feb 19, 3:52 pm, tbjetrond.bjerkestr...@gmail.com
  wrote:
 
 Hi Marius,
 I discovered the issue while porting a working application from
   2.7.7
 tolift2.0-scala280-SNAPSHOT and scala 2.8.0.Beta1.
 
 In the example application I provided it's possible to change
 the
 pom.xml by replacing
 scala.version2.8.0.Beta1/scala.version
 lift.version2.0-scala280-SNAPSHOT/lift.version
 with
 scala.version2.7.7/scala.version
 lift.version2.0-SNAPSHOT/lift.version
 and the application is working as I'd like it to :)
 
 I therefor believe it's alift2.0-scala280 issue.
 
 Best regards
 Trond
 
 On 19 Feb, 14:12, Mariusmarius.dan...@gmail.comwrote:
 
 Can you also try with Scala 2.7.7 ?
 
 On Feb 19, 2:26 pm, tbjetrond.bjerkestr...@gmail.com
  wrote:
 
 Hi,
 I've been testing out theLift-2.0-scala280-SNAPSHOT a little
 bit
   and
 found a issue with Cometactor, setHtml and ajaxInvoke.
 
 When trying to invoke the following partial update nothing
 seems
   to
 happen:
 partialUpdate(SetHtml(field,input type=button
 onclick={ajaxInvoke(() =JsRaw(alert('hi')))._2}
 value=Say
   hi /
 
 ))
 
 This works as expected however:
 partialUpdate(SetHtml(field, a(() =
  JsRaw(alert('hi')),
 spanLink/span)))
 
 I've created a example app to illustrate the problem if
 someone
   is
 interested:
 
 git://github.com/tbje/Lift-2.0-scala280-SNAPSHOT-issue.git
 
 Best regards
 Trond
 
   --
   You received this message because you are subscribed to the Google
 Groups
   Lift group.
   To post to this group, send email to lift...@googlegroups.com.
   To unsubscribe from this group, send email to
   liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
 liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
 ­
   .
   For more options, visit this group at
  http://groups.google.com/group/liftweb?hl=en.
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Surf the harmonics

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




-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890

Re: [Lift] Re: LiftRules.jQueryVersion ... :(

2010-02-23 Thread Jonathan Hoffman
I originally added LiftRules.jQueryVersion, but I agree that this is a much 
better solution.

thanks,

- Jon
On Feb 23, 2010, at 6:00 AM, Marius wrote:

 I opened this ticket: 
 http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryversion-should-not-be-there-
 
 I realize that this would bring a slight breaking change but I believe
 it is worth it.
 
 Folks please speak up if you think otherwise.
 
 Br's,
 Marius
 
 On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
 (yeah forgive me :) ...)
 
 On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 
 
 
 +1 (and we might as well add 1.4.2 as well/instead :-)
 
 On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
 Guys,
 
 This has been added not so long ago, and I am aware that I should
 express my perspective on this back then as now it might be too late.
 IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
 ResourceServer should not even be aware of the underlying JS framework
 thus the JQuery  name in LiftRules is very unsound to me.
 
 Here is other proposal of keeping things decoupled:
 
 .
 We currently have JQueryArtifacts which holds the JQuery
 implementation.
 
 We add in the JsArtifacts this:
 
 trait JsArtifacts {
  ...
  def version
 }
 
 then
 
 case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
  def version = 1.3.2-min
 }
 
 case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
  def version = 1.4.1-min
 }
 
 Then to select one or another we use the existent mechanism:
 
 LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
 can change this easily
 
 then in ResourceServer we can easily make the version selection.
 
 In this way LiftRules has no idea about JQuery, YUI etc  and it
 doesn't need to. it is only about feeding different implementations of
 JsArtifact.
 
 Thoughts?
 
 Br's,
 Marius
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 

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



[Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Timothy Perrett
Oh yeah, you are right Ross!
Doh... in that case, might have to do some refactoring on that module
to give it a more functional style.

Cheers, Tim

On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote:
 There's no record code in there -- it uses mapper in fact.

 I think this is just for auth.

 -Ross

 On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:



  Hey all,

  I see the LDAP has finally been committed... what is it doing in
  modules? Its a read / write to LDAP based on record... shouldn't it be
  in persistence?

  Cheers, Tim

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

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



[Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Dick Hirsch
Any chance that the LDAP functionality will be independent of
MetaMegaProtoUser and MegaProtoUser?

Or maybe some sort of guidance (how-to?) on how to use it without
these classes.

We've (Apache ESME) have been waiting for a while for LDAP to be
supported in Lift but we don't use MegaProtoUser.

Thanks

D.

On Feb 23, 8:15 pm, Ross Mellgren dri...@gmail.com wrote:
 There's no record code in there -- it uses mapper in fact.

 I think this is just for auth.

 -Ross

 On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:

  Hey all,

  I see the LDAP has finally been committed... what is it doing in
  modules? Its a read / write to LDAP based on record... shouldn't it be
  in persistence?

  Cheers, Tim

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

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



[Lift] Re: Lucene (Full text indexing and searching) and Lift

2010-02-23 Thread Dick Hirsch
Apache ESME still uses compass:

Look here for an example:
https://svn.apache.org/repos/asf/incubator/esme/tags/apache-esme-1.0-RC1-incubating/server/src/main/scala/org/apache/esme/model/Message.scala

D.

On Feb 13, 12:14 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Fri, Feb 12, 2010 at 11:43 AM, donfranciscodequevedo 

 donfranciscodequev...@gmail.com wrote:
  Hi,

  I searched for this on the groups, but didn't find a clear statement.

  I'm new to Lift and just wanted to clear this out:  Is full text
  indexing and searching(e.g. Lucene)  already included in the Lift
  Framework or not?

 There's no Lift/Lucene module that I know of, although at one point ESME 
 (http://incubator.apache.org/esme/) had Lift/Lucene integration.





  Thx

  Gregor

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

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

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



[Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Timothy Perrett
Dick, that is exactly what I want also... I was expected the dude who
added it to lift to tidy it up and make it more abstract before adding
it to the project.

I would suggest have a base LDAP module (perhaps record based) and
remove the mapper stuff.

Cheers, Tim

On Feb 23, 8:01 pm, Dick Hirsch hirsch.d...@gmail.com wrote:
 Any chance that the LDAP functionality will be independent of
 MetaMegaProtoUser and MegaProtoUser?

 Or maybe some sort of guidance (how-to?) on how to use it without
 these classes.

 We've (Apache ESME) have been waiting for a while for LDAP to be
 supported in Lift but we don't use MegaProtoUser.

 Thanks

 D.

 On Feb 23, 8:15 pm, Ross Mellgren dri...@gmail.com wrote:



  There's no record code in there -- it uses mapper in fact.

  I think this is just for auth.

  -Ross

  On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:

   Hey all,

   I see the LDAP has finally been committed... what is it doing in
   modules? Its a read / write to LDAP based on record... shouldn't it be
   in persistence?

   Cheers, Tim

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

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



[Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Timothy Perrett
Seems like the current lift-ldap ought to be gutted and turned into a
pure LDAP wrapper for scala. Then we can add a record abstraction and
any other abstractions people want.

Cheers, Tim

On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote:
 It might turn out that we'll need an actual LDAP record backend at work, so I 
 may write one in the future ;-)

 -Ross

 On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote:



  Oh yeah, you are right Ross!
  Doh... in that case, might have to do some refactoring on that module
  to give it a more functional style.

  Cheers, Tim

  On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote:
  There's no record code in there -- it uses mapper in fact.

  I think this is just for auth.

  -Ross

  On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:

  Hey all,

  I see the LDAP has finally been committed... what is it doing in
  modules? Its a read / write to LDAP based on record... shouldn't it be
  in persistence?

  Cheers, Tim

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

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

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



Re: [Lift] anybody used OPA?

2010-02-23 Thread Martin Ellis
On 22 February 2010 21:45, Raoul Duke rao...@gmail.com wrote:
 This is related to Lift how? It appears to be a framework itself...

 i figure people who use Lift are the kinds of people who might have
 their ear to the ground for other approaches to the web problem, and
 might have insight into Competitor X, Y, or Z. i've certainly seen
 people talk about other Java solutions before, admittedly ML is
 further afield, although given Scala, not that much.

I must admit, my initial interest in Scala came from prior use of ML.

I can't answer your question, I'm afraid, but can offer some other
links you might find interesting if you haven't seen them already:

Ur/Web - web application language/framework.
http://impredicative.com/ur/

Yeti - ML-like language on the JVM.
http://wiki.github.com/mth/yeti/

Martin

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



Re: [Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Ross Mellgren
Perhaps eventually (or if someone right now has a strong use), but maybe in the 
short term it should be just mildly split up a bit so that it can be used 
separate of MetaMegaTron? I'm sure there are plenty of people who just need 
authentication and have no intent of using more sophisticated LDAP integration.

-Ross

On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote:

 Seems like the current lift-ldap ought to be gutted and turned into a
 pure LDAP wrapper for scala. Then we can add a record abstraction and
 any other abstractions people want.
 
 Cheers, Tim
 
 On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote:
 It might turn out that we'll need an actual LDAP record backend at work, so 
 I may write one in the future ;-)
 
 -Ross
 
 On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote:
 
 
 
 Oh yeah, you are right Ross!
 Doh... in that case, might have to do some refactoring on that module
 to give it a more functional style.
 
 Cheers, Tim
 
 On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote:
 There's no record code in there -- it uses mapper in fact.
 
 I think this is just for auth.
 
 -Ross
 
 On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:
 
 Hey all,
 
 I see the LDAP has finally been committed... what is it doing in
 modules? Its a read / write to LDAP based on record... shouldn't it be
 in persistence?
 
 Cheers, Tim
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 

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



Re: [Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Timothy Perrett
Ross my good man, did you just volunteer? :-D

+1 on the MegaUberRobotTronFromOuterSpace. There is also a fair amount of 
Java-ish code in there; it would be nice if that went away sometime too :-)

Cheers, Tim

On 23 Feb 2010, at 20:32, Ross Mellgren wrote:

 Perhaps eventually (or if someone right now has a strong use), but maybe in 
 the short term it should be just mildly split up a bit so that it can be used 
 separate of MetaMegaTron? I'm sure there are plenty of people who just need 
 authentication and have no intent of using more sophisticated LDAP 
 integration.
 
 -Ross
 
 On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote:
 
 Seems like the current lift-ldap ought to be gutted and turned into a
 pure LDAP wrapper for scala. Then we can add a record abstraction and
 any other abstractions people want.
 
 Cheers, Tim
 
 On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote:
 It might turn out that we'll need an actual LDAP record backend at work, so 
 I may write one in the future ;-)
 
 -Ross
 
 On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote:
 
 
 
 Oh yeah, you are right Ross!
 Doh... in that case, might have to do some refactoring on that module
 to give it a more functional style.
 
 Cheers, Tim
 
 On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote:
 There's no record code in there -- it uses mapper in fact.
 
 I think this is just for auth.
 
 -Ross
 
 On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:
 
 Hey all,
 
 I see the LDAP has finally been committed... what is it doing in
 modules? Its a read / write to LDAP based on record... shouldn't it be
 in persistence?
 
 Cheers, Tim
 
 --
 You received this message because you are subscribed to the Google 
 Groups Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 

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



Re: [Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Ross Mellgren
Hah maybe if I have some extra moments I'll look at it. I'm preparing for a 
short trip this weekend so my spare time this week is short.

If you didn't have a book to write I'd make you do it! ;-)

-Ross

On Feb 23, 2010, at 3:40 PM, Timothy Perrett wrote:

 Ross my good man, did you just volunteer? :-D
 
 +1 on the MegaUberRobotTronFromOuterSpace. There is also a fair amount of 
 Java-ish code in there; it would be nice if that went away sometime too :-)
 
 Cheers, Tim
 
 On 23 Feb 2010, at 20:32, Ross Mellgren wrote:
 
 Perhaps eventually (or if someone right now has a strong use), but maybe in 
 the short term it should be just mildly split up a bit so that it can be 
 used separate of MetaMegaTron? I'm sure there are plenty of people who just 
 need authentication and have no intent of using more sophisticated LDAP 
 integration.
 
 -Ross
 
 On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote:
 
 Seems like the current lift-ldap ought to be gutted and turned into a
 pure LDAP wrapper for scala. Then we can add a record abstraction and
 any other abstractions people want.
 
 Cheers, Tim
 
 On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote:
 It might turn out that we'll need an actual LDAP record backend at work, 
 so I may write one in the future ;-)
 
 -Ross
 
 On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote:
 
 
 
 Oh yeah, you are right Ross!
 Doh... in that case, might have to do some refactoring on that module
 to give it a more functional style.
 
 Cheers, Tim
 
 On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote:
 There's no record code in there -- it uses mapper in fact.
 
 I think this is just for auth.
 
 -Ross
 
 On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:
 
 Hey all,
 
 I see the LDAP has finally been committed... what is it doing in
 modules? Its a read / write to LDAP based on record... shouldn't it be
 in persistence?
 
 Cheers, Tim
 
 --
 You received this message because you are subscribed to the Google 
 Groups Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 

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



Re: [Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Timothy Perrett
haha yeah, well I was originally planning on writing a record backend in my 
book for LDAP, but thought we already had one... so maybe i'll do it in a month 
or two ;-)

Cheers, Tim

On 23 Feb 2010, at 20:46, Ross Mellgren wrote:

 Hah maybe if I have some extra moments I'll look at it. I'm preparing for a 
 short trip this weekend so my spare time this week is short.
 
 If you didn't have a book to write I'd make you do it! ;-)
 
 -Ross
 
 On Feb 23, 2010, at 3:40 PM, Timothy Perrett wrote:
 
 Ross my good man, did you just volunteer? :-D
 
 +1 on the MegaUberRobotTronFromOuterSpace. There is also a fair amount of 
 Java-ish code in there; it would be nice if that went away sometime too :-)
 
 Cheers, Tim
 
 On 23 Feb 2010, at 20:32, Ross Mellgren wrote:
 
 Perhaps eventually (or if someone right now has a strong use), but maybe in 
 the short term it should be just mildly split up a bit so that it can be 
 used separate of MetaMegaTron? I'm sure there are plenty of people who just 
 need authentication and have no intent of using more sophisticated LDAP 
 integration.
 
 -Ross
 
 On Feb 23, 2010, at 3:14 PM, Timothy Perrett wrote:
 
 Seems like the current lift-ldap ought to be gutted and turned into a
 pure LDAP wrapper for scala. Then we can add a record abstraction and
 any other abstractions people want.
 
 Cheers, Tim
 
 On Feb 23, 8:07 pm, Ross Mellgren dri...@gmail.com wrote:
 It might turn out that we'll need an actual LDAP record backend at work, 
 so I may write one in the future ;-)
 
 -Ross
 
 On Feb 23, 2010, at 3:00 PM, Timothy Perrett wrote:
 
 
 
 Oh yeah, you are right Ross!
 Doh... in that case, might have to do some refactoring on that module
 to give it a more functional style.
 
 Cheers, Tim
 
 On Feb 23, 7:15 pm, Ross Mellgren dri...@gmail.com wrote:
 There's no record code in there -- it uses mapper in fact.
 
 I think this is just for auth.
 
 -Ross
 
 On Feb 23, 2010, at 2:12 PM, Timothy Perrett wrote:
 
 Hey all,
 
 I see the LDAP has finally been committed... what is it doing in
 modules? Its a read / write to LDAP based on record... shouldn't it be
 in persistence?
 
 Cheers, Tim
 
 --
 You received this message because you are subscribed to the Google 
 Groups Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 --
 You received this message because you are subscribed to the Google 
 Groups Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 

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



[Lift] Re: LiftRules.jQueryVersion ... :(

2010-02-23 Thread Marius
Personally I think Jon followed the correct process. I do remember
discussions on this list and on review board. JsArtifacts is somehow
under-explored ... I carry a good part of the blame as I should have
pointed the perspective towards JsArtifacts.

Anyways the proposed fix for #363 is on the review board now.
Essentially the JsArtifacts implementation owns the path rewriting
rules now for its own domain.

Br's,
Marius

On 23 feb., 22:04, Timothy Perrett timo...@getintheloop.eu wrote:
 Jon, did it go through a discussion on the mailing list? I dont
 remember seeing it? (and I cant find it in the archives if it was)

 Anything like this really needs discussion on the mailing list as its
 fundamental to the Lift story and we need to maintain a consistent
 API.

 Cheers, Tim

 On Feb 23, 7:48 pm, Jonathan Hoffman jonhoff...@gmail.com wrote:



  I originally added LiftRules.jQueryVersion, but I agree that this is a much 
  better solution.

  thanks,

  - Jon
  On Feb 23, 2010, at 6:00 AM, Marius wrote:

   I opened this 
   ticket:http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryve...

   I realize that this would bring a slight breaking change but I believe
   it is worth it.

   Folks please speak up if you think otherwise.

   Br's,
   Marius

   On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
   (yeah forgive me :) ...)

   On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:

   +1 (and we might as well add 1.4.2 as well/instead :-)

   On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
   Guys,

   This has been added not so long ago, and I am aware that I should
   express my perspective on this back then as now it might be too late.
   IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
   ResourceServer should not even be aware of the underlying JS framework
   thus the JQuery  name in LiftRules is very unsound to me.

   Here is other proposal of keeping things decoupled:

   .
   We currently have JQueryArtifacts which holds the JQuery
   implementation.

   We add in the JsArtifacts this:

   trait JsArtifacts {
    ...
    def version
   }

   then

   case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
    def version = 1.3.2-min
   }

   case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
    def version = 1.4.1-min
   }

   Then to select one or another we use the existent mechanism:

   LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
   can change this easily

   then in ResourceServer we can easily make the version selection.

   In this way LiftRules has no idea about JQuery, YUI etc  and it
   doesn't need to. it is only about feeding different implementations of
   JsArtifact.

   Thoughts?

   Br's,
   Marius

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

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

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



Re: [Lift] Re: LiftRules.jQueryVersion ... :(

2010-02-23 Thread Timothy Perrett
Fair enough Marius - I just didn't remember seeing it is all and wanted to 
check we were following the process for all the changes made to Lift. You know 
im a stickler for process ;-)

Your proposed solution sounds good though - I agree JsArtifacts is certainly 
under explored; like a lot of parts of Lift. 

Cheers, Tim

On 23 Feb 2010, at 21:21, Marius wrote:

 Personally I think Jon followed the correct process. I do remember
 discussions on this list and on review board. JsArtifacts is somehow
 under-explored ... I carry a good part of the blame as I should have
 pointed the perspective towards JsArtifacts.
 
 Anyways the proposed fix for #363 is on the review board now.
 Essentially the JsArtifacts implementation owns the path rewriting
 rules now for its own domain.
 
 Br's,
 Marius
 
 On 23 feb., 22:04, Timothy Perrett timo...@getintheloop.eu wrote:
 Jon, did it go through a discussion on the mailing list? I dont
 remember seeing it? (and I cant find it in the archives if it was)
 
 Anything like this really needs discussion on the mailing list as its
 fundamental to the Lift story and we need to maintain a consistent
 API.
 
 Cheers, Tim
 
 On Feb 23, 7:48 pm, Jonathan Hoffman jonhoff...@gmail.com wrote:
 
 
 
 I originally added LiftRules.jQueryVersion, but I agree that this is a much 
 better solution.
 
 thanks,
 
 - Jon
 On Feb 23, 2010, at 6:00 AM, Marius wrote:
 
 I opened this 
 ticket:http://www.assembla.com/spaces/liftweb/tickets/363-liftrules-jqueryve...
 
 I realize that this would bring a slight breaking change but I believe
 it is worth it.
 
 Folks please speak up if you think otherwise.
 
 Br's,
 Marius
 
 On Feb 23, 10:25 am, Marius marius.dan...@gmail.com wrote:
 (yeah forgive me :) ...)
 
 On Feb 23, 10:18 am, Jeppe Nejsum Madsen je...@ingolfs.dk wrote:
 
 +1 (and we might as well add 1.4.2 as well/instead :-)
 
 On Tue, Feb 23, 2010 at 9:11 AM, Marius marius.dan...@gmail.com wrote:
 Guys,
 
 This has been added not so long ago, and I am aware that I should
 express my perspective on this back then as now it might be too late.
 IMHO LiftRules or other Lift parts except the JsArtifacts and maybe
 ResourceServer should not even be aware of the underlying JS framework
 thus the JQuery  name in LiftRules is very unsound to me.
 
 Here is other proposal of keeping things decoupled:
 
 .
 We currently have JQueryArtifacts which holds the JQuery
 implementation.
 
 We add in the JsArtifacts this:
 
 trait JsArtifacts {
  ...
  def version
 }
 
 then
 
 case class JQueryArtifacts1_3_2 extends JQueryArtifacts  {
  def version = 1.3.2-min
 }
 
 case class JQueryArtifacts1_4_1 extends JQueryArtifacts {
  def version = 1.4.1-min
 }
 
 Then to select one or another we use the existent mechanism:
 
 LiftRules.jsArtifacts = JQueryArtifacts1_3_2 // by default and people
 can change this easily
 
 then in ResourceServer we can easily make the version selection.
 
 In this way LiftRules has no idea about JQuery, YUI etc  and it
 doesn't need to. it is only about feeding different implementations of
 JsArtifact.
 
 Thoughts?
 
 Br's,
 Marius
 
 --
 You received this message because you are subscribed to the Google 
 Groups Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 --
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group 
 athttp://groups.google.com/group/liftweb?hl=en.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Lift group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 

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



Re: [Lift] Re: What is LDAP doing in modules?

2010-02-23 Thread Francois Armand

Le 23/02/2010 21:14, Timothy Perrett a écrit :

Seems like the current lift-ldap ought to be gutted and turned into a
pure LDAP wrapper for scala. Then we can add a record abstraction and
any other abstractions people want.



In my company, we are building an LDAP-based application with a web UI 
in Lift, and so, I would be really interested in seing some kind a 
LDAP-Record integration be done, and why not help to achieve that.


If you want to make a real LDAP integration, I advice to not use 
LDAP-JNDI, which is really bad and awfull to use. And since the Java 
LDAP API projects leaded by ApachDS/OpenDS is still work in progress[1], 
I can point to UnboundID LDAP SDK[2], which is really pleasant to use.


Anyhow, I'm really happy to see that LDAP brings some interest in Lift 
community :)



[1] http://mail-archives.apache.org/mod_mbox/directory-api/
[2] http://www.unboundid.com/products/ldapsdk/

--
Francois Armand
http://fanf42.blogspot.com

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



[Lift] Hooking up custom login logic with ProtoUser's logUserIn and actionsAfterSignup

2010-02-23 Thread dave
Hello,

I'm working on an application that has until now primarily used Lift
for the mapper framework (1.1-M8).  This includes us extending Meta/
MegaProtoUser to get the basic user account functionality while
rolling our own servlets and front-end client (not using Lift).

Now we want to make use of the Lift ProtoUser views and functionality
for reset password, lost password, etc.  I've tried including calls to
User.actionsAfterSignup and User.logUserIn from our own signup/signin
service methods so that those included forms will be in-sync with the
login status of our application.

The problem is that calls to logUserIn and actionsAfterSignup don't
appear to do anything.  User.currentUserId is always Empty and
navigating to the /user_mgt/login page does not redirect as if the
user is logged in, unless I specifically login through those created
pages.

How can I hook our own signup/signin logic up to be in sync with the
ProtoUser functionality?

Thanks for any pointers!!
dave


For example, our signup/signin service methods went something like
(simplified):

def signUp(...) = {
  val user = User.create.email(email).password(password)
  user.validate match {
// ok to save/create
//user.save // old approach
User.finalizeSignup(user) //-- defers to
User.actionsAfterSignup(user)
  }
}

def signIn(...) = {
  User.findByUsername(username) match {
case Full(user) if (user.password.match_?(password)) = {
  // log user in
  // ...
  User.logUserIn(user)
}
  }
}

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



Re: [Lift] Re: fmapFunc and order of operations

2010-02-23 Thread David Pollak
I started working on ticket #349 (
https://liftweb.assembla.com/spaces/liftweb/tickets/349-make-shtml-%5Binput%5D-return-elem-with-answerholder%5Bt%5D)
and tried returning an Elem with Responder[T] (see
http://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_7_7_final/src/library/scala/Responder.scala?view=markup)
and found that Elem (which subclasses Node which subclasses Seq[Node])
already has map/flatMap/foreach.  So... the API is not as clean as it could
have been.

Do you have any thoughts on how to clean up the API to make it better?

On Mon, Feb 15, 2010 at 4:06 PM, Kris Nuttycombe
kris.nuttyco...@gmail.comwrote:

 On Mon, Feb 15, 2010 at 4:31 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:
  If all the SHtml stuff returned a NodeSeq (or Elem) with AnswerHolder and
  AnswerHolder[T] looked like:
 
  trait AnswerHolder[T] {
def hasAnswer: Boolean
def answer: Box[T]
def map[S](f: T = S): Box[S]
...
  }
 
  Then we could get what you want (no explicit mutability) and keep APIs
  working the way they work now.  What do you think?
 
  We could even introduce alternative SHtml stuff like:
 
  def text(original: String): Elem with AnswerHolder[String]
 
  What do you think?

 That looks good; I think it'd go a long way toward making the order of
 operations a little more foolproof. The idea of 'Elem with
 AnswerHolder' had never occurred to me; I guess I just always assumed
 that Elem or Node was sealed, but it doesn't appear to be from the
 scaladocs. That would certainly help on the backwards compatibility
 front and would alleviate the need for the implicit conversion I'd
 imagined from FormField[T] to NodeSeq.

 What do you think about the notion of a ! method that does the
 unsafe answer.open_! ? I would think that in the vast majority of
 cases, the Box being Empty would represent either a coding error or a
 framework error. In the case of a coding error (the answer attempting
 to be extracted during the initial rendering of the form elements)
 this would fail fast, and in the case where the response is actually
 being processed it should probably never be empty anyway.

 Kris

 
  On Mon, Jan 25, 2010 at 11:31 AM, Kris Nuttycombe
  kris.nuttyco...@gmail.com wrote:
 
  On Mon, Jan 25, 2010 at 12:16 PM, David Pollak
  feeder.of.the.be...@gmail.com wrote:
  
  
   On Mon, Jan 25, 2010 at 11:09 AM, Kris Nuttycombe
   kris.nuttyco...@gmail.com wrote:
  
   On Mon, Jan 25, 2010 at 11:51 AM, Kris Nuttycombe
   kris.nuttyco...@gmail.com wrote:
On Mon, Jan 25, 2010 at 11:40 AM, David Pollak
feeder.of.the.be...@gmail.com wrote:
   
   
On Mon, Jan 25, 2010 at 10:19 AM, Kris Nuttycombe
kris.nuttyco...@gmail.com wrote:
   
On Mon, Jan 25, 2010 at 11:07 AM, Marius 
 marius.dan...@gmail.com
wrote:
 S.formFuncName .. should guarantee proper ordering of functions
 application respecting the ordering of functions creation (and
 this
 is
 used by fmapFunc).

 I'm a bit tired to follow code from this page so could you
 please
 put
 together a minimalistic application that I could just try?

 Br's,
 Marius
   
Thanks, Marius, but I'm too time-crunched at the moment to boil
this
down. In any case, I found a solution. My frustration is
 primarily
that ordering of function creation matters in the first place;
making
the ordering of function creation less relevant is the point of
 my
proposal in the other thread. If the order that you do things in
matters, it completely hoses you for the purposes of composition
(as I
painfully found out with this example.) Here, the composition is
just
two calls deep and explicit, and even with only that small amount
of
composition it was a pain to track down.
   
Does this make my proposal in the other thread make any more
 sense
to
you?
   
Ordering is well defined:
   
The order in which the functions are mapped
Skewed plus or minus based on value of S.formGroup
   
There's no way to avoid ordering.  The functions have to be
 executed
in
some
order.  By default, the stuff in SHtml does this in the order the
elements
were defined, but sets S.formGroup to 1 for the submit button (so
it's
always the last function executed.)
   
They have to be executed in some order; I just wish that the
execution
could actually be performed by user code! That's the whole point of
my
suggestion from the other thread.
   
More broadly, I think you might want to look at what I did with
Screen
and
Wizard.  These are declarative mechanisms for defining forms,
validations,
and behaviors.  Where are these not working for you?
   
I simply haven't had the time to port thousands of lines of form
 code
I've already written over to stuff on SNAPSHOT. I was supposed to
have
this stuff released last Friday; my intention was to release on M8
since I 

[Lift] 35 open tickets for M3

2010-02-23 Thread David Pollak
Folks,

We are quickly approaching code slush for 2.0-M3.  We are aiming to build M3
on Wednesday March 3rd which means that all changes except those to fix
newly discovered defects have to be in master by end of day on Sunday.

Please look through the tickets in Assembla.  If your name is next to an M3
ticket, please either commit to closing it by end of day Sunday or move it
to M4.

Thanks,

David

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

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