[Lift] Re: Rails - Lift

2009-04-10 Thread Alexander Kellett

well, fwiw :P i eventually chose ideavim with intellij. best of both worlds.
thanks all for the input!

On Thu, Apr 9, 2009 at 10:20 PM, TylerWeir tyler.w...@gmail.com wrote:

 It's not an editor/IDE war unless someone brings up Vim or Emacs,
 so...

 I've been using Vim+Scala+Ctags since I started.

 I'd recommend not getting hung-up on which editor is the best  just
 start coding.


 On Apr 9, 3:01 pm, Charles F. Munat c...@munat.com wrote:
 I was thinking that I'd start with Textmate, since I've used that the
 most and it's what most Rails developers use, and then move to NetBeans,
 since that seems to be pretty popular. But I could take a quick look at
 Eclipse, too.



 David Pollak wrote:

  On Thu, Apr 9, 2009 at 2:38 AM, Alexander Kellett lypa...@gmail.com
  mailto:lypa...@gmail.com wrote:

      actually my biggest blocker (and still my blocker) is getting a
      working coding environment.

      there is so much contradictory information on which ide is the best.
      it would be really nice to have a document that talks about the pro's
      and con's of each ide.

      in the rails/osx world its easy: use textmate unless you have a
      predisposition for something else.

  I spent a lot of time coding Scala and Lift with emacs and Textmate.
   They work fine.

  While my current IDE of choice is NetBeans, I'm not convinced that an
  IDE is better than a good text editor.

      not the case for lift / scala in general.

      i know, boring... but i think it really would help to have such a
      document to help people decide.

      On Thu, Apr 9, 2009 at 5:58 AM, Charles F. Munat c...@munat.com
      mailto:c...@munat.com wrote:

        I'm writing a proposal for a presentation on moving from Rails to
      Lift.

        A couple of stumbling blocks that I've mentioned are:

        1. Understanding and taking advantage of immutable constructs.

        2. Getting the hang of the view-centric approach to MVC.

        Before I go much further, I'd like to poll this list for things that
        others think should be included. For former or current Rails
      developers
        like myself, What sorts of things gave you the most trouble when
      moving
        to Lift (or trying it out)? What would you like to have had someone
        explain to you to make the transition easier?

        Thanks for any help!

        Chas.

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


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



[Lift] Re: Rails - Lift

2009-04-10 Thread Timothy Perrett

I think a lot of people coming to scala from ruby are more familiar
with the terminal and textmate style combination... using large IDE's
with boat loads of features is more for people coming from a
traditional java background. Thats not to say they don't have merit,
of course they do, but I think they wouldn't add a lot of value to
people who arnt used to using an IDE full stop and possibly dont see
why they should use one.

Having gone Java - Ruby - Scala, I started off being an eclipse guy
but after coding in ruby for a few years just didnt want to step back
into eclipse or netbeans: neither felt right

Cheers, Tim

On Apr 9, 8:01 pm, Charles F. Munat c...@munat.com wrote:
 I was thinking that I'd start with Textmate, since I've used that the
 most and it's what most Rails developers use, and then move to NetBeans,
 since that seems to be pretty popular. But I could take a quick look at
 Eclipse, too.

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



[Lift] Re: Big Domain Model - Lift and Persistence

2009-04-10 Thread Tim P

more a scala question this: but with the JPA can I create Traits that
encapsulate the annotations for example an Id trait that includes @Id.
Any obvious drawbacks in doing so?
Thanks
Tim

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



[Lift] Re: Rails - Lift

2009-04-10 Thread David Pollak
I think this thread points out something important about Lift... what
matters most is what works for you.  There are plenty of people on this list
that use one editor or another... use mapper or JPA... use lots of
comet/ajax or use very little.  The only thing that's right is what works
for you... and if you do something different than everyone, please share...
I expect we'll learn something.

Thanks,

David

On Apr 9, 2009 1:20 PM, TylerWeir tyler.w...@gmail.com wrote:


It's not an editor/IDE war unless someone brings up Vim or Emacs,
so...

I've been using Vim+Scala+Ctags since I started.

I'd recommend not getting hung-up on which editor is the best  just
start coding.

On Apr 9, 3:01 pm, Charles F. Munat c...@munat.com wrote:  I was
thinking that I'd start with...

  On Thu, Apr 9, 2009 at 2:38 AM, Alexander Kellett lypa...@gmail.com  
mailto:lypa...@gmail.c...
  On Thu, Apr 9, 2009 at 5:58 AM, Charles F. Munat c...@munat.com

  mailto:c...@munat.com wrote:  I'm writing a proposal
for a presentation on mo...
  Beginning Scalahttp://www.apress.com/book/view/1430219890

  Follow me:http://twitter.com/dpp   Git 
  some:http://github.com/dpp--~--~-~--~~...

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



[Lift] Re: Big Domain Model - Lift and Persistence

2009-04-10 Thread Derek Chen-Becker
I've only ever done something like this with the joined subclass support in
JPA, so I don't know if using raw traits for independent classes would work.
Easy to test, though.

Derek

On Fri, Apr 10, 2009 at 5:38 AM, Tim P tim.pig...@optrak.co.uk wrote:


 more a scala question this: but with the JPA can I create Traits that
 encapsulate the annotations for example an Id trait that includes @Id.
 Any obvious drawbacks in doing so?
 Thanks
 Tim

 


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



[Lift] Re: Rails - Lift

2009-04-10 Thread Ben Diola

Does anyone know how to get a console in netbeans that I can run mvn
scala:cc?


On Apr 10, 8:12 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 I think this thread points out something important about Lift... what
 matters most is what works for you.  There are plenty of people on this list
 that use one editor or another... use mapper or JPA... use lots of
 comet/ajax or use very little.  The only thing that's right is what works
 for you... and if you do something different than everyone, please share...
 I expect we'll learn something.

 Thanks,

 David

 On Apr 9, 2009 1:20 PM, TylerWeir tyler.w...@gmail.com wrote:

 It's not an editor/IDE war unless someone brings up Vim or Emacs,
 so...

 I've been using Vim+Scala+Ctags since I started.

 I'd recommend not getting hung-up on which editor is the best  just
 start coding.

 On Apr 9, 3:01 pm, Charles F. Munat c...@munat.com wrote:  I was
 thinking that I'd start with...

   On Thu, Apr 9, 2009 at 2:38 AM, Alexander Kellett lypa...@gmail.com  

 mailto:lypa...@gmail.c...

       On Thu, Apr 9, 2009 at 5:58 AM, Charles F. Munat c...@munat.com
       mailto:c...@munat.com wrote:      I'm writing a proposal

 for a presentation on mo...

   Beginning Scalahttp://www.apress.com/book/view/1430219890
   Follow me:http://twitter.com/dpp  Git 
   some:http://github.com/dpp--~--~-~--~~...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Object typecast to Mapper

2009-04-10 Thread David Pollak
I think the .asJs method on all Mapper instances should give you the object
in JavaScript representation.
If you can post an entire file, I can work on helping you if the above
doesn't work.

On Thu, Apr 9, 2009 at 6:53 AM, Amit Kumar Verma cdac.a...@gmail.comwrote:


 copied the the same code but getting this error

 type arguments [_] do not conform to trait MetaMapper's type parameter
 bounds [A : net.liftweb.mapper.Mapper[A]]
  TravelMerchantTest/src/main/
 scala/com/vtech/travelmerchant/snippet  default.scala   line 142
 1239284830763   85593

 Actually I am trying to make the JSON object using a mapper object. My
 function is this :

 def getJSONStringGeneric(anyObject :Any):NodeSeq = {

  //Console.println(anyObject.getClass 
 +anyObject.getClass);

  //Console.println(anyObject.getClass.getName 
 +anyObject.getClass.getName);

  //var objTemp = anyObject.asInstanceOf[MetaMapper
 [TestGearLogin]];

  var sJSONString = {\bindings\: [;

  anyObject match {
   case mm: MetaMapper[_] =
mm.findAll.map(
 (userdetails: Mapper[_]) ={


  var tempJSON = ;

  val ret = new StringBuilder

  ret.append({)

  ret.append(userdetails.getSingleton.appendFieldToStrings
 (userdetails))

  ret.append(})

  // ret will be like
 {username=222,password=222,audit_dt=2009-04-06
 00:00:00.0,login_pid=26}

  tempJSON = ret.toString();

  tempJSON = tempJSON.replaceAll(\\{,\\{\);
  tempJSON = tempJSON.replaceAll(\\},\\\});
  tempJSON = tempJSON.replaceAll(=,\:\);
  tempJSON = tempJSON.replaceAll(, , \,\);
  tempJSON += ,;

  sJSONString +=tempJSON
}
)
  }

  sJSONString = sJSONString.substring(0,sJSONString.length-1); //
 for slicing the last comma
  sJSONString += ]};

  Text(sJSONString);
  }


 but not getting a way of doing this. Please advise.

 Thanks
 Amit Kumar Verma


 On Apr 9, 6:14 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
  Howdy,
  Scala is a static language, so the class for casting must be known at
  compile time.  It's not possible to construct a String at runtime and
 cast
  an object into a class represented by that String.
 
  However, casting to a known class is easy in Scala... and it's done
  primarily using pattern matching.  The following code:
 
def foo(in: Any) = in match {
  case mm: MetaMapper[_] =
mm.findAll.map(
  (m: Mapper[_]) =
  m.asJs
)
  case _ =
}
 
  Does what I think you want.  It takes an incoming instance, in and
 matches
  it against being an instance of MetaMapper[_].  This means its some type
 of
  MetaMapper (we don't know or care what the type parameter is).  If it is
 a
  MetaMapper, it's assigned to the mm variable.  We can then call findAll
 on
  that variable and we have a bunch of Mapper[_] instances.  Note that I
  explicitly called out the type of m in the function, but that line could
 be
  re-written mm.findAll.map(m = m.asJs) because the compiler infers the
 type
  of m.
 
  Does this help?
 
  Thanks,
 
  David
 
  On Thu, Apr 9, 2009 at 3:55 AM, Amit Kumar Verma cdac.a...@gmail.com
 wrote:
 
 
 
 
 
   Hi All,
 
   I am trying to type cast an scala object to its mapper object
 
   1 def getJSONString(anyObject :Object):NodeSeq = {
 
   2 var obj = anyObject.asInstanceOf[anyObject.getClass
   ().getName()];
 
   3 obj.findAll.map(userdetails = {
  // some code will go here
   }
   Text(any string)
}
 
   but i am getting erroe as expected [ but found ( on line 2.
 
   please help me to typecast the object to its mapper object.
 
   Thanks
   Amit Kumar Verma
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Git some:http://github.com/dpp

 



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

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



[Lift] directives versus snippets

2009-04-10 Thread bob

if I see lift:/, it could mean one of two things: a directive,
e.g., lift:bind/ or lift:surround/ or shorthand for a snippet, eg
lift:myClass represents lift:snippet type=MyClass

i guess I would like to see these disambiguated a shorthand for
snippets that doesn't overlap with the directive namespace.

some possible solutions:

1. lift:bind/ would be the directive and lift:.bind/ would be the
snippet. please don't get hung up on my use of dot. it is only an
example, and not an actual suggestion.

2. lift:bind/ maps to a real class, not some internal code, much the
way lift:msgs/ maps to net.liftweb.builtin.snippets.Msgs  (thanks
Jorge)

3. lift:bind is the directive, and liftsnippet:bind is the snippet

comments?

thanks, bob


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



[Lift] Re: directives versus snippets

2009-04-10 Thread David Pollak
Bob,
They are actually the same thing.  Lift's processing directives are simply
built-in snippets.  You can, if you dare, override their functionality. :-)

Thanks,

David

On Fri, Apr 10, 2009 at 11:23 AM, bob rbpas...@gmail.com wrote:


 if I see lift:/, it could mean one of two things: a directive,
 e.g., lift:bind/ or lift:surround/ or shorthand for a snippet, eg
 lift:myClass represents lift:snippet type=MyClass

 i guess I would like to see these disambiguated a shorthand for
 snippets that doesn't overlap with the directive namespace.

 some possible solutions:

 1. lift:bind/ would be the directive and lift:.bind/ would be the
 snippet. please don't get hung up on my use of dot. it is only an
 example, and not an actual suggestion.

 2. lift:bind/ maps to a real class, not some internal code, much the
 way lift:msgs/ maps to net.liftweb.builtin.snippets.Msgs  (thanks
 Jorge)

 3. lift:bind is the directive, and liftsnippet:bind is the snippet

 comments?

 thanks, bob


 



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

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



[Lift] Re: directives versus snippets

2009-04-10 Thread bob

ok, Jorge told me on IRC that bind and surround are hard-coded

11:16 bobinator so,if lift:helloWorld.howdy/ maps to Class
HelloWorld#howdy,i assume lift:bindand lift:msgs map to Class Bind
and Class Msgs, with some special sauce for the method?
11:15 jorgeortiz85 actually, all the directives could be implemented
as snippets
11:16 jorgeortiz85 the fact that they aren't is just legacy cruft
11:16 jorgeortiz85 lift:msgs does
11:16 jorgeortiz85 lift:bind is hard-coded




On Apr 10, 11:26 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 Bob,
 They are actually the same thing.  Lift's processing directives are simply
 built-in snippets.  You can, if you dare, override their functionality. :-)

 Thanks,

 David



 On Fri, Apr 10, 2009 at 11:23 AM, bob rbpas...@gmail.com wrote:

  if I see lift:/, it could mean one of two things: a directive,
  e.g., lift:bind/ or lift:surround/ or shorthand for a snippet, eg
  lift:myClass represents lift:snippet type=MyClass

  i guess I would like to see these disambiguated a shorthand for
  snippets that doesn't overlap with the directive namespace.

  some possible solutions:

  1. lift:bind/ would be the directive and lift:.bind/ would be the
  snippet. please don't get hung up on my use of dot. it is only an
  example, and not an actual suggestion.

  2. lift:bind/ maps to a real class, not some internal code, much the
  way lift:msgs/ maps to net.liftweb.builtin.snippets.Msgs  (thanks
  Jorge)

  3. lift:bind is the directive, and liftsnippet:bind is the snippet

  comments?

  thanks, bob

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

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



[Lift] Re: directives versus snippets

2009-04-10 Thread Jorge Ortiz
Huh?

lift: snippet, surround, embed, ignore, comet, children, a, form, loc, and
with-param are all built-in in liftTagProcessing. Yes, they're overrideable,
but imo it'd be nicer if they were Just A Snippet, like, say, lift:msgs.

lift:bind is just bad naming. it's not actually a directive, it's just what
lift:surround looks for to bind at. should probably be called surround:bind
or something with a different namespace.

--j

On Fri, Apr 10, 2009 at 1:26 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 Bob,
 They are actually the same thing.  Lift's processing directives are simply
 built-in snippets.  You can, if you dare, override their functionality. :-)

 Thanks,

 David

 On Fri, Apr 10, 2009 at 11:23 AM, bob rbpas...@gmail.com wrote:


 if I see lift:/, it could mean one of two things: a directive,
 e.g., lift:bind/ or lift:surround/ or shorthand for a snippet, eg
 lift:myClass represents lift:snippet type=MyClass

 i guess I would like to see these disambiguated a shorthand for
 snippets that doesn't overlap with the directive namespace.

 some possible solutions:

 1. lift:bind/ would be the directive and lift:.bind/ would be the
 snippet. please don't get hung up on my use of dot. it is only an
 example, and not an actual suggestion.

 2. lift:bind/ maps to a real class, not some internal code, much the
 way lift:msgs/ maps to net.liftweb.builtin.snippets.Msgs  (thanks
 Jorge)

 3. lift:bind is the directive, and liftsnippet:bind is the snippet

 comments?

 thanks, bob






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

 


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



[Lift] Re: directives versus snippets

2009-04-10 Thread David Pollak
Who you gonna believe? :-)

There's a dispatcher in Lift and it checks for user-supplied snippets before
dispatching to the hard-coded snippet names.

You can override the built-in names and there are a bunch of different
snippet dispatch mechanisms (by convention, by partial function, hard-coded)
 This does not change the fact the the lift:xxx/ tag is encountered and
the body of the tag is dispatched someplace for processing.

On Fri, Apr 10, 2009 at 11:29 AM, bob rbpas...@gmail.com wrote:


 ok, Jorge told me on IRC that bind and surround are hard-coded

 11:16 bobinator so,if lift:helloWorld.howdy/ maps to Class
 HelloWorld#howdy,i assume lift:bindand lift:msgs map to Class Bind
 and Class Msgs, with some special sauce for the method?
 11:15 jorgeortiz85 actually, all the directives could be implemented
 as snippets
 11:16 jorgeortiz85 the fact that they aren't is just legacy cruft
 11:16 jorgeortiz85 lift:msgs does
 11:16 jorgeortiz85 lift:bind is hard-coded




 On Apr 10, 11:26 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:
  Bob,
  They are actually the same thing.  Lift's processing directives are
 simply
  built-in snippets.  You can, if you dare, override their functionality.
 :-)
 
  Thanks,
 
  David
 
 
 
  On Fri, Apr 10, 2009 at 11:23 AM, bob rbpas...@gmail.com wrote:
 
   if I see lift:/, it could mean one of two things: a directive,
   e.g., lift:bind/ or lift:surround/ or shorthand for a snippet, eg
   lift:myClass represents lift:snippet type=MyClass
 
   i guess I would like to see these disambiguated a shorthand for
   snippets that doesn't overlap with the directive namespace.
 
   some possible solutions:
 
   1. lift:bind/ would be the directive and lift:.bind/ would be the
   snippet. please don't get hung up on my use of dot. it is only an
   example, and not an actual suggestion.
 
   2. lift:bind/ maps to a real class, not some internal code, much the
   way lift:msgs/ maps to net.liftweb.builtin.snippets.Msgs  (thanks
   Jorge)
 
   3. lift:bind is the directive, and liftsnippet:bind is the snippet
 
   comments?
 
   thanks, bob
 
  --
  Lift, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://www.apress.com/book/view/1430219890
  Follow me:http://twitter.com/dpp
  Git some:http://github.com/dpp

 



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

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



[Lift] Re: directives versus snippets

2009-04-10 Thread David Pollak
On Fri, Apr 10, 2009 at 11:31 AM, Jorge Ortiz jorge.or...@gmail.com wrote:

 Huh?

 lift: snippet, surround, embed, ignore, comet, children, a, form, loc, and
 with-param are all built-in in liftTagProcessing. Yes, they're overrideable,
 but imo it'd be nicer if they were Just A Snippet, like, say, lift:msgs.


It's on my to-do list to do a little house cleaning in this area.




 lift:bind is just bad naming. it's not actually a directive, it's just what
 lift:surround looks for to bind at. should probably be called surround:bind
 or something with a different namespace.


Yeah... we should deprecate lift:bind/ because it's not the same thing.
 Please open a defect on this for me.




 --j

 On Fri, Apr 10, 2009 at 1:26 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 Bob,
 They are actually the same thing.  Lift's processing directives are simply
 built-in snippets.  You can, if you dare, override their functionality. :-)

 Thanks,

 David

 On Fri, Apr 10, 2009 at 11:23 AM, bob rbpas...@gmail.com wrote:


 if I see lift:/, it could mean one of two things: a directive,
 e.g., lift:bind/ or lift:surround/ or shorthand for a snippet, eg
 lift:myClass represents lift:snippet type=MyClass

 i guess I would like to see these disambiguated a shorthand for
 snippets that doesn't overlap with the directive namespace.

 some possible solutions:

 1. lift:bind/ would be the directive and lift:.bind/ would be the
 snippet. please don't get hung up on my use of dot. it is only an
 example, and not an actual suggestion.

 2. lift:bind/ maps to a real class, not some internal code, much the
 way lift:msgs/ maps to net.liftweb.builtin.snippets.Msgs  (thanks
 Jorge)

 3. lift:bind is the directive, and liftsnippet:bind is the snippet

 comments?

 thanks, bob






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




 



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

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



[Lift] Re: Snippets; having trouble with a simple example

2009-04-10 Thread David Pollak
On Wed, Apr 8, 2009 at 4:13 PM, Douglas F Shearer douga...@gmail.comwrote:


 I've found the solution to this. It seems that for some reason I
 needed to provide the return type on the posts method, as so:

 def posts(html: NodeSeq): NodeSeq = {
 ...

 Odd it should fail in such a manner without it, I would expect the
 return type to be inferred by the compiler, or an error given.


The type inferencer determines the type to be List[Node].  Lift's convention
is that it looks for NodeSeq (it's hard to do pattern matching on List[Node]
because of type erasure) so you have to explicitly define the return type.




 Thanks.

 On Apr 8, 9:10 pm, Douglas F Shearer douga...@gmail.com wrote:
  Hi there.
 
  I'm having issues with a simple snippets example.
 
  The error, view and template can be seen here:
 http://gist.github.com/91971
 
  I'm sure it's a trivial issue, my code seems identical to the example
  given in the Getting Started PDF.
 
  Help is much appreciated.
 
  Thanks.
 
  Douglas F Shearer
  douga...@gmail.comhttp://douglasfshearer.com

 



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

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



[Lift] Re: directives versus snippets

2009-04-10 Thread bob

done. thanks guys

On Apr 10, 11:36 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 On Fri, Apr 10, 2009 at 11:31 AM, Jorge Ortiz jorge.or...@gmail.com wrote:
  Huh?

  lift: snippet, surround, embed, ignore, comet, children, a, form, loc, and
  with-param are all built-in in liftTagProcessing. Yes, they're overrideable,
  but imo it'd be nicer if they were Just A Snippet, like, say, lift:msgs.

 It's on my to-do list to do a little house cleaning in this area.

http://liftweb.lighthouseapp.com/projects/26102/tickets/34-lift-processing-directives-should-be-implemented-as-snippets

  lift:bind is just bad naming. it's not actually a directive, it's just what
  lift:surround looks for to bind at. should probably be called surround:bind
  or something with a different namespace.

 Yeah... we should deprecate lift:bind/ because it's not the same thing.
  Please open a defect on this for me.

http://liftweb.lighthouseapp.com/projects/26102/tickets/33-deprecate-liftbind








  --j

  On Fri, Apr 10, 2009 at 1:26 PM, David Pollak 
  feeder.of.the.be...@gmail.com wrote:

  Bob,
  They are actually the same thing.  Lift's processing directives are simply
  built-in snippets.  You can, if you dare, override their functionality. :-)

  Thanks,

  David

  On Fri, Apr 10, 2009 at 11:23 AM, bob rbpas...@gmail.com wrote:

  if I see lift:/, it could mean one of two things: a directive,
  e.g., lift:bind/ or lift:surround/ or shorthand for a snippet, eg
  lift:myClass represents lift:snippet type=MyClass

  i guess I would like to see these disambiguated a shorthand for
  snippets that doesn't overlap with the directive namespace.

  some possible solutions:

  1. lift:bind/ would be the directive and lift:.bind/ would be the
  snippet. please don't get hung up on my use of dot. it is only an
  example, and not an actual suggestion.

  2. lift:bind/ maps to a real class, not some internal code, much the
  way lift:msgs/ maps to net.liftweb.builtin.snippets.Msgs  (thanks
  Jorge)

  3. lift:bind is the directive, and liftsnippet:bind is the snippet

  comments?

  thanks, bob

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

 --
 Lift, the simply functional web frameworkhttp://liftweb.net
 Beginning Scalahttp://www.apress.com/book/view/1430219890
 Follow me:http://twitter.com/dpp
 Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Small archetype bug?

2009-04-10 Thread Timothy Perrett

Ignore me... im being dumb! Basic archetype has lib but the blank one
doesnt. I'll add a lib dir to blank archetype tomorrow.

Cheers, Tim

On Apr 10, 12:22 pm, Tim Perrett timo...@getintheloop.eu wrote:
 Just looked at the blank archetype because im wanting to build another
 one for my own purposes and noticed that there is a lib dir in the
 resources for the archetype, but its never actually created upon
 generation.

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



[Lift] Re: Small archetype bug?

2009-04-10 Thread David Pollak
I put non-Lift related logic stuff in lib.

On Fri, Apr 10, 2009 at 12:23 PM, David Bernard
david.bernard...@gmail.comwrote:

 Why adding a lib dir if it's useless ?

 /davidB


 On Fri, Apr 10, 2009 at 21:01, Timothy Perrett timo...@getintheloop.euwrote:


 Ignore me... im being dumb! Basic archetype has lib but the blank one
 doesnt. I'll add a lib dir to blank archetype tomorrow.

 Cheers, Tim

 On Apr 10, 12:22 pm, Tim Perrett timo...@getintheloop.eu wrote:
  Just looked at the blank archetype because im wanting to build another
  one for my own purposes and noticed that there is a lib dir in the
  resources for the archetype, but its never actually created upon
  generation.
 
  Its not seriously important or anything but just an observation...



 



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

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



[Lift] Re: Small archetype bug?

2009-04-10 Thread Timothy Perrett


Agreed - this is exactly what I think most people do.

On 10/04/2009 20:25, David Pollak feeder.of.the.be...@gmail.com wrote:

 I put non-Lift related logic stuff in lib.



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



[Lift] Re: Big Domain Model - Lift and Persistence

2009-04-10 Thread Charles F. Munat

I've been wondering about this, too, but too busy to experiment. Please 
post your results if you try it.

Chas.

Derek Chen-Becker wrote:
 I've only ever done something like this with the joined subclass support 
 in JPA, so I don't know if using raw traits for independent classes 
 would work. Easy to test, though.
 
 Derek
 
 On Fri, Apr 10, 2009 at 5:38 AM, Tim P tim.pig...@optrak.co.uk 
 mailto:tim.pig...@optrak.co.uk wrote:
 
 
 more a scala question this: but with the JPA can I create Traits that
 encapsulate the annotations for example an Id trait that includes @Id.
 Any obvious drawbacks in doing so?
 Thanks
 Tim
 
 
 
 
  

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



[Lift] (created|updated|deleted)_(by|at) trait

2009-04-10 Thread Franz Bettag

Hey guys,

i had the (simple) idea of creating a trait for these fields:

  object created_by extends MappedLongForeignKey(this, User)
  object created_at extends MappedDateTime(this)
  object updated_by extends MappedLongForeignKey(this, User)
  object updated_at extends MappedDateTime(this)
  object deleted_by extends MappedLongForeignKey(this, User)
  object deleted_at extends MappedDateTime(this)

Any ideas how i might do that? I've tried a few things but nothing
worked. A simple example would be enought to get me going ;)

Thanks in advance

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



[Lift] Re: (created|updated|deleted)_(by|at) trait

2009-04-10 Thread David Pollak
The not overly helpful answer... please look for the IdPK trait... you can
see how to do stuff like this.
If you're still stuck, I'll provide a more helpful answer.

On Fri, Apr 10, 2009 at 4:39 PM, Franz Bettag i...@fbettag.de wrote:


 Hey guys,

 i had the (simple) idea of creating a trait for these fields:

  object created_by extends MappedLongForeignKey(this, User)
  object created_at extends MappedDateTime(this)
  object updated_by extends MappedLongForeignKey(this, User)
  object updated_at extends MappedDateTime(this)
  object deleted_by extends MappedLongForeignKey(this, User)
  object deleted_at extends MappedDateTime(this)

 Any ideas how i might do that? I've tried a few things but nothing
 worked. A simple example would be enought to get me going ;)

 Thanks in advance

 



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

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



[Lift] Re: (created|updated|deleted)_(by|at) trait

2009-04-10 Thread Clemens Oertel

Hi Franz,

Here's what I did, roughly:

trait TimeStamped[OwnerType : ExtMapper[OwnerType]] {
   this: ExtMapper[OwnerType] =

   private val thisTyped = this.asInstanceOf[MapperType]

   object createdOn extends ExtMappedDateTime(thisTyped) with  
LifecycleCallbacks {
 override def beforeCreate = this(new Date)
   }

   object updatedOn extends ExtMappedDateTime(thisTyped) with  
LifecycleCallbacks {
 override def beforeUpdate = this(new Date)
   }
}

trait ExtMapper[OwnerType : ExtMapper[OwnerType]] extends  
Mapper[OwnerType]
 with TimeStamped[OwnerType] with UserStamped[OwnerType]
{
   self: OwnerType =

   // A lot more stuff here ...
}

Best,
Clemens


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



[Lift] stateful vs stateless snippet

2009-04-10 Thread Oliver Lambert
I have a stateful snippet that doesn't always appear to work with the back
button.
Sometimes, when the back button is used, a new stateful snippet instance
appears to be created. Has this happened to anyone else?

Anyway, I've converted what I had to use a SessionVar to store the state.
Should I replace the stateful snippet with a stateless one - does a stateful
snippet that isn't storing any state have any extra overhead over a
stateless one?

If I do use a stateless snipet can I still have a dispatch method?

cheers
Oliver

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