[Lift] Re: Welcome Lee Mighdoll to the Lift committers

2009-03-18 Thread marius d.

Lee, you're most welcomed !

On Mar 18, 5:11 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
 Folks,
 I'm pleased to welcome Lee Mighdoll to the Lift committers.  Lee wrote the
 brilliant line:

 Lift is an expressive and elegant framework for writing web applications.

 Almost 18 months ago... but he's not a marketing guy, he's a code slinger
 and he's going to be slinging some pretty cool code into Lift.

 Please join me in welcoming Lee on board!

 Thanks,

 David

 --
 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: SQL Server Errors

2009-03-18 Thread Timothy Perrett

Hey Derek,

I know ­ this confused me too. The current MappedText for SQL Server is
being implemented as Varchar(MAX) in the database.

I always to m.description.toString and this way I get the clob reference.

Excuse my ignorance, but shouldn¹t MappedText actually be using ³text²
column type?

Cheers, Tim

On 17/03/2009 19:19, Derek Chen-Becker dchenbec...@gmail.com wrote:

 Actually, now I'm more confused. In the MappedText source it's using the JDBC
 type VARCHAR. In MetaMapper's buildMapper method it appears that VARCHAR
 should be retrieved via a resultSet.getString call, which should return the
 String form of the data. I confirmed this in jTDS source:
 
 http://jtds.cvs.sourceforge.net/viewvc/jtds/jtds/src/java/net/sourceforge/jtds
 /jdbc/Support.java?revision=1.1view=markuppathrev=MAIN
 
 Line 289. I have no idea how you're getting a real ClobImpl object, since the
 source seems to indicate that it should just be a String:
 
 class MappedText[T:Mapper[T]](val fieldOwner: T) extends MappedField[String,
 T]
 
 Derek
 
 On Tue, Mar 17, 2009 at 2:08 PM, Derek Chen-Becker dchenbec...@gmail.com
 wrote:
 OK, check out the wip-dcb-datetime branch and test that.
 
 It looks like the CLOB object that jTDS returns doesn't override toString to
 return the contents of the CLOB. It does, however, implement the
 java.sql.Clob interface, so it may be possible to match that somehow and make
 it work. I'm diving into parts of Mapper that I haven't really worked with
 before, so no guarantees. Just to confirm, can you change your snippet to
 use:
 
 description - m.description.toString
 
 and see if you get the same thing?
 
 Thanks,
 
 Derek
 
 
 
 
 On Tue, Mar 17, 2009 at 1:05 PM, Timothy Perrett timo...@getintheloop.eu
 wrote:
 
 Hey Derek,
 
 Awesome - thanks. I knew the DataTime one would be a simple fix - I
 just don't know enough about mapper.
 
 #17 is the one thats really hurting me right now... if you could fix
 that I would be sooo grateful!
 
 Cheers, Tim
 
 On Mar 17, 6:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
  OK, actually, the change is in SqlServerDriver. I've made the change and
 I'm
  running a build before committing. Once I push the branch could you check
 it
  out and test? I'm looking at #17 right now, too.
 
  Derek
 
  On Tue, Mar 17, 2009 at 12:44 PM, Derek Chen-Becker
  dchenbec...@gmail.comwrote:
 
   I think the DateTime issue should be fixed pretty easily in
 MappedDateTime
   itself. Let me make a new branch and make a minor change.
 
   Derek
 
   On Tue, Mar 17, 2009 at 12:09 PM, Timothy Perrett
 timo...@getintheloop.eu
wrote:
 
   *bump*
 
   Al, any progress on these?
 
   Cheers, Tim
 
   On Mar 10, 11:04 am, Timothy Perrett timo...@getintheloop.eu
 wrote:
Is someone able to take ownership of these tickets?
 
Cheers, Tim
 
On Mar 9, 5:52 pm, Tim Perrett timo...@getintheloop.eu wrote:
 
 Guys,
 
 Just logged a couple of bugs for SQL Server drivers:
 

 http://liftweb.lighthouseapp.com/projects/26102/tickets/18-sql-server.
   ..
 

 http://liftweb.lighthouseapp.com/projects/26102/tickets/17-mappedtext.
   ..
 
 Can someone take a look? This really is not my speciality.
 
 Cheers, Tim
 
 
 
 
  
 


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



[Lift] Explicitly shutting down comet actor in a single session

2009-03-18 Thread Tim Perrett

Guys,

I have a situation where by im using comet actors to watch something
on a 3rd party system. Now, when the monitoring needs to stop, I want
to explicitly shutdown that comet actor and redirect some to place
else. However, when I pass the comet actor the ShutDown message, the
page redirects to /

So, my question: is it possible to do something in localShutdown to
redirect the user? Or in some other-way stop the redirecting to / ?
I want to do this because by keeping it to a single comet actor
lifecycle, jobs are submitted on the 3rd party system only once even
if they refresh the page etc.

Thoughts?

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



[Lift] Re: SQL Server Errors

2009-03-18 Thread Derek Chen-Becker
Yeah, I saw the varchar(max) definition. I searched around and it looks like
TEXT is deprecated in favor of VARCHAR(MAX) in Sql Server 2005.

http://stackoverflow.com/questions/564755/sql-server-text-type-v-s-varchar-data-type

Maybe we need to make a new SqlServer2005 Driver that uses VARCHAR(MAX) and
change the current one to use TEXT. Thoughts? Part of my confusion is that
MappedText has an explicit String type parameter, but it *appears* that
you're getting a ClobImpl. Could you me a favor and print out

m.description.is.getClass

and see what is really being stored in the field? I'm wondering if somehow
the Clob is being converted to a string lower in the chain so you're just
getting a string of net.sourceforge.jtds.jdbc.clobi...@aeaf68.

Derek


On Wed, Mar 18, 2009 at 3:45 AM, Timothy Perrett timo...@getintheloop.euwrote:


 Hey Derek,

 I know – this confused me too. The current MappedText for SQL Server is
 being implemented as Varchar(MAX) in the database.

 I always to m.description.toString and this way I get the clob reference.

 Excuse my ignorance, but shouldn’t MappedText actually be using “text”
 column type?

 Cheers, Tim


 On 17/03/2009 19:19, Derek Chen-Becker dchenbec...@gmail.com wrote:

 Actually, now I'm more confused. In the MappedText source it's using the
 JDBC type VARCHAR. In MetaMapper's buildMapper method it appears that
 VARCHAR should be retrieved via a resultSet.getString call, which should
 return the String form of the data. I confirmed this in jTDS source:


 http://jtds.cvs.sourceforge.net/viewvc/jtds/jtds/src/java/net/sourceforge/jtds/jdbc/Support.java?revision=1.1view=markuppathrev=MAIN

 Line 289. I have no idea how you're getting a real ClobImpl object, since
 the source seems to indicate that it should just be a String:

 class MappedText[T:Mapper[T]](val fieldOwner: T) extends
 MappedField[String, T]

 Derek

 On Tue, Mar 17, 2009 at 2:08 PM, Derek Chen-Becker dchenbec...@gmail.com
 wrote:

 OK, check out the wip-dcb-datetime branch and test that.

 It looks like the CLOB object that jTDS returns doesn't override toString
 to return the contents of the CLOB. It does, however, implement the
 java.sql.Clob interface, so it may be possible to match that somehow and
 make it work. I'm diving into parts of Mapper that I haven't really worked
 with before, so no guarantees. Just to confirm, can you change your snippet
 to use:

 description - m.description.toString

 and see if you get the same thing?

 Thanks,

 Derek




 On Tue, Mar 17, 2009 at 1:05 PM, Timothy Perrett timo...@getintheloop.eu
 wrote:


 Hey Derek,

 Awesome - thanks. I knew the DataTime one would be a simple fix - I
 just don't know enough about mapper.

 #17 is the one thats really hurting me right now... if you could fix
 that I would be sooo grateful!

 Cheers, Tim

 On Mar 17, 6:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
  OK, actually, the change is in SqlServerDriver. I've made the change and
 I'm
  running a build before committing. Once I push the branch could you check
 it
  out and test? I'm looking at #17 right now, too.
 
  Derek
 
  On Tue, Mar 17, 2009 at 12:44 PM, Derek Chen-Becker
  dchenbec...@gmail.comwrote:
 
   I think the DateTime issue should be fixed pretty easily in
 MappedDateTime
   itself. Let me make a new branch and make a minor change.
 
   Derek
 
   On Tue, Mar 17, 2009 at 12:09 PM, Timothy Perrett 
 timo...@getintheloop.eu
wrote:
 
   *bump*
 
   Al, any progress on these?
 
   Cheers, Tim
 
   On Mar 10, 11:04 am, Timothy Perrett timo...@getintheloop.eu wrote:
Is someone able to take ownership of these tickets?
 
Cheers, Tim
 
On Mar 9, 5:52 pm, Tim Perrett timo...@getintheloop.eu wrote:
 
 Guys,
 
 Just logged a couple of bugs for SQL Server drivers:
 

 http://liftweb.lighthouseapp.com/projects/26102/tickets/18-sql-server.
   ..
 

 http://liftweb.lighthouseapp.com/projects/26102/tickets/17-mappedtext.
   ..
 
 Can someone take a look? This really is not my speciality.
 
 Cheers, Tim







 


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



[Lift] Re: SQL Server Errors

2009-03-18 Thread Timothy Perrett

Ok thats interesting about Text/Varchar(max)... I didnt know that.
Whats the JTDS support for that? Is it ok?

This is where things get freaky! Doing m.description.is.getClass gives
me class java.lang.String. I mean, wtf, which are you? Clob or
String! HAHA

Thoughts?

Tim

On Mar 18, 2:05 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
 Yeah, I saw the varchar(max) definition. I searched around and it looks like
 TEXT is deprecated in favor of VARCHAR(MAX) in Sql Server 2005.

 http://stackoverflow.com/questions/564755/sql-server-text-type-v-s-va...

 Maybe we need to make a new SqlServer2005 Driver that uses VARCHAR(MAX) and
 change the current one to use TEXT. Thoughts? Part of my confusion is that
 MappedText has an explicit String type parameter, but it *appears* that
 you're getting a ClobImpl. Could you me a favor and print out

 m.description.is.getClass

 and see what is really being stored in the field? I'm wondering if somehow
 the Clob is being converted to a string lower in the chain so you're just
 getting a string of net.sourceforge.jtds.jdbc.clobi...@aeaf68.

 Derek

 On Wed, Mar 18, 2009 at 3:45 AM, Timothy Perrett 
 timo...@getintheloop.euwrote:



  Hey Derek,

  I know – this confused me too. The current MappedText for SQL Server is
  being implemented as Varchar(MAX) in the database.

  I always to m.description.toString and this way I get the clob reference.

  Excuse my ignorance, but shouldn’t MappedText actually be using “text”
  column type?

  Cheers, Tim

  On 17/03/2009 19:19, Derek Chen-Becker dchenbec...@gmail.com wrote:

  Actually, now I'm more confused. In the MappedText source it's using the
  JDBC type VARCHAR. In MetaMapper's buildMapper method it appears that
  VARCHAR should be retrieved via a resultSet.getString call, which should
  return the String form of the data. I confirmed this in jTDS source:

 http://jtds.cvs.sourceforge.net/viewvc/jtds/jtds/src/java/net/sourcef...

  Line 289. I have no idea how you're getting a real ClobImpl object, since
  the source seems to indicate that it should just be a String:

  class MappedText[T:Mapper[T]](val fieldOwner: T) extends
  MappedField[String, T]

  Derek

  On Tue, Mar 17, 2009 at 2:08 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

  OK, check out the wip-dcb-datetime branch and test that.

  It looks like the CLOB object that jTDS returns doesn't override toString
  to return the contents of the CLOB. It does, however, implement the
  java.sql.Clob interface, so it may be possible to match that somehow and
  make it work. I'm diving into parts of Mapper that I haven't really worked
  with before, so no guarantees. Just to confirm, can you change your snippet
  to use:

  description - m.description.toString

  and see if you get the same thing?

  Thanks,

  Derek

  On Tue, Mar 17, 2009 at 1:05 PM, Timothy Perrett timo...@getintheloop.eu
  wrote:

  Hey Derek,

  Awesome - thanks. I knew the DataTime one would be a simple fix - I
  just don't know enough about mapper.

  #17 is the one thats really hurting me right now... if you could fix
  that I would be sooo grateful!

  Cheers, Tim

  On Mar 17, 6:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
   OK, actually, the change is in SqlServerDriver. I've made the change and
  I'm
   running a build before committing. Once I push the branch could you check
  it
   out and test? I'm looking at #17 right now, too.

   Derek

   On Tue, Mar 17, 2009 at 12:44 PM, Derek Chen-Becker
   dchenbec...@gmail.comwrote:

I think the DateTime issue should be fixed pretty easily in
  MappedDateTime
itself. Let me make a new branch and make a minor change.

Derek

On Tue, Mar 17, 2009 at 12:09 PM, Timothy Perrett 
  timo...@getintheloop.eu
 wrote:

*bump*

Al, any progress on these?

Cheers, Tim

On Mar 10, 11:04 am, Timothy Perrett timo...@getintheloop.eu wrote:
 Is someone able to take ownership of these tickets?

 Cheers, Tim

 On Mar 9, 5:52 pm, Tim Perrett timo...@getintheloop.eu wrote:

  Guys,

  Just logged a couple of bugs for SQL Server drivers:

 http://liftweb.lighthouseapp.com/projects/26102/tickets/18-sql-server.
..

 http://liftweb.lighthouseapp.com/projects/26102/tickets/17-mappedtext.
..

  Can someone take a look? This really is not my speciality.

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



[Lift] Re: Forms validation formatter

2009-03-18 Thread Clemens Oertel
I admit to only having worked with mapper. I will look closer into  
record, (quick glance: it comes with next-to-the-field messages, nice).

Marius, are you referring to the toForm functions? I'm probably just  
not seeing how to use them in a flexible manner. With respect to  
validation, I was wondering how to apply conditional formatting based  
on failed/succeeded validation.

Maybe a word or two to the background of my questions: I'm currently  
trying to port a web application from RoR to lift. All I know is that  
RoR does not work for me any longer, but I'm not sure where to go yet,  
so I started to look around, and lift seems to be the most promising  
candidate. The heavy exposure to RoR might have tainted my mind, true,  
and I'm open to be shown the light.

Anyways, this app is of medical nature, very database heavy, lots and  
lots of fields. In order to avoid error upon data entry, the record's  
form on screen must looks as closely like the paper version as  
possible. A record's field can appear (and may be edited) in different  
contexts. Sometimes, the same text field is displayed with different  
lengths, the same text area may have different heights, all text  
fields may be limited to a max length of n in some contexts, etc.

Other aspect of the story: While working on the RoR version, the  
directive was: Some boolean fields are to be displayed as drop downs  
with 3 values (empty, yes, no). This now has changed, these boolean  
fields are to be displayed as 3 radio buttons. One of course wants to  
ensure that such a change only affects one area in the code base.

That's what got me wondering: Is the toForm approach the best one for  
my case?

Thanks for listening,
Clemens



On 18-Mar-09, at 3:18 AM, marius d. wrote:


 FWIW please also take a look on Record and formvalidation support.

 Br's,
 Marius

 On Mar 17, 11:07 pm, Clemens Oertel clemens.oer...@gmail.com wrote:
 Hello everybody,

 Still trying to learn how to use lift efficiently and effectively, I
 got a little bit confused about the toForm function in the model/
 mappers. Admittedly, my web framework background may be limited, but
 this looked to me as if some view code snuck into the model space
 there (I must admit that I do like how RoR tries to keep the models
 fairly clean of both controller  code and of view code).

 For my first little project, I was going to encapsulate the HTML  
 field
 formatting into a separate class (similar to what RoR does, but  
 making
 use of the type system).

 This is a very quick brain dump, not running code.

 // The different field types, at a higher level than HTML
 abstract class InputType
 case class TextField extends InputType
 case class DateField extends InputType
 case class DateTimeField extends InputType

 // Rendering hints that an form field formatter may use, could also  
 be
 called FormGenerator ...
 abstract class RenderingHint
 case class MinLength(l: Int) extends RenderingHint
 case class MaxLength(l: Int) extends RenderingHint

 // Input-type aware callback'ed formatter, from the model's  
 perspective
 trait InputTypeHandler {
def handleTextField(fieldID: String, presetValue: String,
 renderingHints: RenderingHint*)

def handleDateField(fieldID: String, presetValue: Date,
 renderingHints: RenderingHint*)

 }

 // A model class using the callback
 class ModelClass {
object aField extends MappedString(this, 128) {
  def inputTypeCallback(InputTypeHandler handler) {
// A reasonable default should/could be pushed upwards in the
 type hierarchy
handler.handleTextField(fieldID, this.is,  
 MaxLength(this.length))
  }
}

 }

 This InputTypeHandler could be a nice spot to deal with validation
 result formatting:

 class AnInputFormatter(errors: List[FieldError]) extends
 InputTypeHandler {
def handleTextField(fieldID: String, presetValue: String,
 renderingHints: RenderingHint*) {
  errors.filter(_._1 == fieldID).match {
case Nil = /* format field normally */
case xs = /* format as error, i.e. red background, error
 messages right of field  */
  }
}

...

 }

 // A snippet
 ...
 val inputFormatter = new AnInputFormatter(errorsFromValidation)
 bind(form, html, aField - aModelClass.aField.
 inputTypeCallback(inputFormatter))
 ...

 Maybe a partial function, potentially on case classes, is better?  
 Many
 options ...

 I'm looking forward to any feedback.

 Best,
 Clemens
 

Clemens Oertel
clem...@oertel.ca





Clemens Oertel
clem...@oertel.ca




--~--~-~--~~~---~--~~
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: Welcome Lee Mighdoll to the Lift committers

2009-03-18 Thread David Bernard

Bienvenue !

On Wed, Mar 18, 2009 at 10:33, Timothy Perrett timo...@getintheloop.eu wrote:

 Welcome Lee - good to have you on board.

 Send me a picture and bio of yourself and i'll add you to the
 liftweb.net team list :-)

 Cheers, Tim

 On Mar 18, 9:12 am, marius d. marius.dan...@gmail.com wrote:
 Lee, you're most welcomed !

 On Mar 18, 5:11 am, David Pollak feeder.of.the.be...@gmail.com
 wrote:

  Folks,
  I'm pleased to welcome Lee Mighdoll to the Lift committers.  Lee wrote the
  brilliant line:

  Lift is an expressive and elegant framework for writing web applications.

  Almost 18 months ago... but he's not a marketing guy, he's a code slinger
  and he's going to be slinging some pretty cool code into Lift.

  Please join me in welcoming Lee on board!

  Thanks,

  David

  --
  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: SQL Server Errors

2009-03-18 Thread Derek Chen-Becker
Just to confirm, you're using the latest jTDS driver, right?

Derek

On Wed, Mar 18, 2009 at 8:39 AM, Timothy Perrett timo...@getintheloop.euwrote:


 Ok thats interesting about Text/Varchar(max)... I didnt know that.
 Whats the JTDS support for that? Is it ok?

 This is where things get freaky! Doing m.description.is.getClass gives
 me class java.lang.String. I mean, wtf, which are you? Clob or
 String! HAHA

 Thoughts?

 Tim

 On Mar 18, 2:05 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
  Yeah, I saw the varchar(max) definition. I searched around and it looks
 like
  TEXT is deprecated in favor of VARCHAR(MAX) in Sql Server 2005.
 
  http://stackoverflow.com/questions/564755/sql-server-text-type-v-s-va...
 
  Maybe we need to make a new SqlServer2005 Driver that uses VARCHAR(MAX)
 and
  change the current one to use TEXT. Thoughts? Part of my confusion is
 that
  MappedText has an explicit String type parameter, but it *appears* that
  you're getting a ClobImpl. Could you me a favor and print out
 
  m.description.is.getClass
 
  and see what is really being stored in the field? I'm wondering if
 somehow
  the Clob is being converted to a string lower in the chain so you're just
  getting a string of net.sourceforge.jtds.jdbc.clobi...@aeaf68.
 
  Derek
 
  On Wed, Mar 18, 2009 at 3:45 AM, Timothy Perrett timo...@getintheloop.eu
 wrote:
 
 
 
   Hey Derek,
 
   I know – this confused me too. The current MappedText for SQL Server is
   being implemented as Varchar(MAX) in the database.
 
   I always to m.description.toString and this way I get the clob
 reference.
 
   Excuse my ignorance, but shouldn’t MappedText actually be using “text”
   column type?
 
   Cheers, Tim
 
   On 17/03/2009 19:19, Derek Chen-Becker dchenbec...@gmail.com
 wrote:
 
   Actually, now I'm more confused. In the MappedText source it's using
 the
   JDBC type VARCHAR. In MetaMapper's buildMapper method it appears that
   VARCHAR should be retrieved via a resultSet.getString call, which
 should
   return the String form of the data. I confirmed this in jTDS source:
 
  http://jtds.cvs.sourceforge.net/viewvc/jtds/jtds/src/java/net/sourcef.
 ..
 
   Line 289. I have no idea how you're getting a real ClobImpl object,
 since
   the source seems to indicate that it should just be a String:
 
   class MappedText[T:Mapper[T]](val fieldOwner: T) extends
   MappedField[String, T]
 
   Derek
 
   On Tue, Mar 17, 2009 at 2:08 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
   wrote:
 
   OK, check out the wip-dcb-datetime branch and test that.
 
   It looks like the CLOB object that jTDS returns doesn't override
 toString
   to return the contents of the CLOB. It does, however, implement the
   java.sql.Clob interface, so it may be possible to match that somehow
 and
   make it work. I'm diving into parts of Mapper that I haven't really
 worked
   with before, so no guarantees. Just to confirm, can you change your
 snippet
   to use:
 
   description - m.description.toString
 
   and see if you get the same thing?
 
   Thanks,
 
   Derek
 
   On Tue, Mar 17, 2009 at 1:05 PM, Timothy Perrett
 timo...@getintheloop.eu
   wrote:
 
   Hey Derek,
 
   Awesome - thanks. I knew the DataTime one would be a simple fix - I
   just don't know enough about mapper.
 
   #17 is the one thats really hurting me right now... if you could fix
   that I would be sooo grateful!
 
   Cheers, Tim
 
   On Mar 17, 6:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
OK, actually, the change is in SqlServerDriver. I've made the change
 and
   I'm
running a build before committing. Once I push the branch could you
 check
   it
out and test? I'm looking at #17 right now, too.
 
Derek
 
On Tue, Mar 17, 2009 at 12:44 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
 
 I think the DateTime issue should be fixed pretty easily in
   MappedDateTime
 itself. Let me make a new branch and make a minor change.
 
 Derek
 
 On Tue, Mar 17, 2009 at 12:09 PM, Timothy Perrett 
   timo...@getintheloop.eu
  wrote:
 
 *bump*
 
 Al, any progress on these?
 
 Cheers, Tim
 
 On Mar 10, 11:04 am, Timothy Perrett timo...@getintheloop.eu
 wrote:
  Is someone able to take ownership of these tickets?
 
  Cheers, Tim
 
  On Mar 9, 5:52 pm, Tim Perrett timo...@getintheloop.eu wrote:
 
   Guys,
 
   Just logged a couple of bugs for SQL Server drivers:
 
  http://liftweb.lighthouseapp.com/projects/26102/tickets/18-sql-server.
 ..
 
  http://liftweb.lighthouseapp.com/projects/26102/tickets/17-mappedtext.
 ..
 
   Can someone take a look? This really is not my speciality.
 
   Cheers, Tim
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit 

[Lift] Re: Welcome Lee Mighdoll to the Lift committers

2009-03-18 Thread Lee Mighdoll
Happy to be able to help.

Lee

On Wed, Mar 18, 2009 at 7:54 AM, David Bernard
david.bernard...@gmail.comwrote:


 Bienvenue !

 On Wed, Mar 18, 2009 at 10:33, Timothy Perrett timo...@getintheloop.eu
 wrote:
 
  Welcome Lee - good to have you on board.
 
  Send me a picture and bio of yourself and i'll add you to the
  liftweb.net team list :-)
 
  Cheers, Tim
 
  On Mar 18, 9:12 am, marius d. marius.dan...@gmail.com wrote:
  Lee, you're most welcomed !
 
  On Mar 18, 5:11 am, David Pollak feeder.of.the.be...@gmail.com
  wrote:
 
   Folks,
   I'm pleased to welcome Lee Mighdoll to the Lift committers.  Lee wrote
 the
   brilliant line:
 
   Lift is an expressive and elegant framework for writing web
 applications.
 
   Almost 18 months ago... but he's not a marketing guy, he's a code
 slinger
   and he's going to be slinging some pretty cool code into Lift.
 
   Please join me in welcoming Lee on board!
 
   Thanks,
 
   David
 
   --
   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: SQL Server Errors

2009-03-18 Thread Derek Chen-Becker
FYI, the datetime fix is merged to master.

Derek

On Wed, Mar 18, 2009 at 9:16 AM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 Also, as Tim pointed out we may need to change the varchar defs on the SQL
 Server Driver to nvarchar. There's also the issue of VARCHAR(MAX) (SQL
 Server 2005 and up) vs TEXT (older versions). Perhaps we need n additional
 SqlServerPre2005Driver class?

 Derek


 On Wed, Mar 18, 2009 at 8:56 AM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 Just to confirm, you're using the latest jTDS driver, right?

 Derek


 On Wed, Mar 18, 2009 at 8:39 AM, Timothy Perrett timo...@getintheloop.eu
  wrote:


 Ok thats interesting about Text/Varchar(max)... I didnt know that.
 Whats the JTDS support for that? Is it ok?

 This is where things get freaky! Doing m.description.is.getClass gives
 me class java.lang.String. I mean, wtf, which are you? Clob or
 String! HAHA

 Thoughts?

 Tim

 On Mar 18, 2:05 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
  Yeah, I saw the varchar(max) definition. I searched around and it looks
 like
  TEXT is deprecated in favor of VARCHAR(MAX) in Sql Server 2005.
 
  http://stackoverflow.com/questions/564755/sql-server-text-type-v-s-va.
 ..
 
  Maybe we need to make a new SqlServer2005 Driver that uses VARCHAR(MAX)
 and
  change the current one to use TEXT. Thoughts? Part of my confusion is
 that
  MappedText has an explicit String type parameter, but it *appears* that
  you're getting a ClobImpl. Could you me a favor and print out
 
  m.description.is.getClass
 
  and see what is really being stored in the field? I'm wondering if
 somehow
  the Clob is being converted to a string lower in the chain so you're
 just
  getting a string of net.sourceforge.jtds.jdbc.clobi...@aeaf68.
 
  Derek
 
  On Wed, Mar 18, 2009 at 3:45 AM, Timothy Perrett
 timo...@getintheloop.euwrote:
 
 
 
   Hey Derek,
 
   I know – this confused me too. The current MappedText for SQL Server
 is
   being implemented as Varchar(MAX) in the database.
 
   I always to m.description.toString and this way I get the clob
 reference.
 
   Excuse my ignorance, but shouldn’t MappedText actually be using
 “text”
   column type?
 
   Cheers, Tim
 
   On 17/03/2009 19:19, Derek Chen-Becker dchenbec...@gmail.com
 wrote:
 
   Actually, now I'm more confused. In the MappedText source it's using
 the
   JDBC type VARCHAR. In MetaMapper's buildMapper method it appears that
   VARCHAR should be retrieved via a resultSet.getString call, which
 should
   return the String form of the data. I confirmed this in jTDS source:
 
  
 http://jtds.cvs.sourceforge.net/viewvc/jtds/jtds/src/java/net/sourcef...
 
   Line 289. I have no idea how you're getting a real ClobImpl object,
 since
   the source seems to indicate that it should just be a String:
 
   class MappedText[T:Mapper[T]](val fieldOwner: T) extends
   MappedField[String, T]
 
   Derek
 
   On Tue, Mar 17, 2009 at 2:08 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
   wrote:
 
   OK, check out the wip-dcb-datetime branch and test that.
 
   It looks like the CLOB object that jTDS returns doesn't override
 toString
   to return the contents of the CLOB. It does, however, implement the
   java.sql.Clob interface, so it may be possible to match that somehow
 and
   make it work. I'm diving into parts of Mapper that I haven't really
 worked
   with before, so no guarantees. Just to confirm, can you change your
 snippet
   to use:
 
   description - m.description.toString
 
   and see if you get the same thing?
 
   Thanks,
 
   Derek
 
   On Tue, Mar 17, 2009 at 1:05 PM, Timothy Perrett
 timo...@getintheloop.eu
   wrote:
 
   Hey Derek,
 
   Awesome - thanks. I knew the DataTime one would be a simple fix - I
   just don't know enough about mapper.
 
   #17 is the one thats really hurting me right now... if you could fix
   that I would be sooo grateful!
 
   Cheers, Tim
 
   On Mar 17, 6:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
OK, actually, the change is in SqlServerDriver. I've made the
 change and
   I'm
running a build before committing. Once I push the branch could you
 check
   it
out and test? I'm looking at #17 right now, too.
 
Derek
 
On Tue, Mar 17, 2009 at 12:44 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:
 
 I think the DateTime issue should be fixed pretty easily in
   MappedDateTime
 itself. Let me make a new branch and make a minor change.
 
 Derek
 
 On Tue, Mar 17, 2009 at 12:09 PM, Timothy Perrett 
   timo...@getintheloop.eu
  wrote:
 
 *bump*
 
 Al, any progress on these?
 
 Cheers, Tim
 
 On Mar 10, 11:04 am, Timothy Perrett timo...@getintheloop.eu
 wrote:
  Is someone able to take ownership of these tickets?
 
  Cheers, Tim
 
  On Mar 9, 5:52 pm, Tim Perrett timo...@getintheloop.eu
 wrote:
 
   Guys,
 
   Just logged a couple of bugs for SQL Server drivers:
 
  http://liftweb.lighthouseapp.com/projects/26102/tickets/18-sql-server
 .

[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-18 Thread Derek Chen-Becker
OK, I tested locally and it works for me. I just pushed to master and it
should show up in Hudson soon.

Derek

On Tue, Mar 17, 2009 at 1:52 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 OK, new code is checked in on wip-dcb-mailer-charset branch. Does anyone
 have time to test?

 Derek


 On Tue, Mar 17, 2009 at 2:39 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 This is strictly MIME, so the plain text part of the message will have
 an explicit charset associated with the text. The JavaMail framework is very
 flexible in terms of what you can send, how it's encoded, etc, but Lift's
 interface only exposes a small subset appropriate for sending either text
 emails or XHtml w/ optional images. The BodyPart interface that we're using
 doesn't directly allow you to specify content encoding, just the charset:

 http://java.sun.com/products/javamail/javadocs/javax/mail/BodyPart.html

 If you want to do more interesting things (ie send a file attachment) you
 would want to use JavaMail directly.

 Derek


 On Tue, Mar 17, 2009 at 2:31 PM, Marc Boschma 
 marc+lift...@boschma.cxmarc%2blift...@boschma.cx
  wrote:

 It depends upon what is meant by plain. According to RFC 2045 (5.2) the
 default character encoding for a non-MIME message is us-ascii and the
 transfer encoding would be 7bit.
 Given that I think we are speaking of MIME encoded messages I think that
 the default of UTF-8 is ok in a lift context, but that you should provide
 the case class as not all email clients understand UTF-8 and if building a
 message that has the widest support is desired then it should be easy to
 specify alternatives that can be interpreted.

 What is the treatment of character encoding in the interface? ie. can I
 specify base64 or quoted-printable, etc?

 Marc

 On 18/03/2009, at 1:23 AM, Derek Chen-Becker wrote:

 I'm looking at ticket #19:


 http://liftweb.lighthouseapp.com/projects/26102/tickets/19-mailer-doesnt-handle-plain-text-encoding

 The setText method is essentially a shortcut for setContent(...,
 text/plain), but it also allows you to specify the character encoding.
 Would anyone be opposed to modifying the code so that PlainMailBodyType uses
 UTF-8 for character encoding? Would it be useful to provide an additional
 case class, a la

 PlainPlusBodyType(text : String, charset : String)

 Derek





 




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



[Lift] Re: SQL Server Errors

2009-03-18 Thread Timothy Perrett

I've just committed the patch for the CLOB issue.

Cheers, Tim

On Mar 18, 3:42 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
 FYI, the datetime fix is merged to master.

 Derek

 On Wed, Mar 18, 2009 at 9:16 AM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

  Also, as Tim pointed out we may need to change the varchar defs on the SQL
  Server Driver to nvarchar. There's also the issue of VARCHAR(MAX) (SQL
  Server 2005 and up) vs TEXT (older versions). Perhaps we need n additional
  SqlServerPre2005Driver class?

  Derek

  On Wed, Mar 18, 2009 at 8:56 AM, Derek Chen-Becker 
  dchenbec...@gmail.comwrote:

  Just to confirm, you're using the latest jTDS driver, right?

  Derek

  On Wed, Mar 18, 2009 at 8:39 AM, Timothy Perrett timo...@getintheloop.eu
   wrote:

  Ok thats interesting about Text/Varchar(max)... I didnt know that.
  Whats the JTDS support for that? Is it ok?

  This is where things get freaky! Doing m.description.is.getClass gives
  me class java.lang.String. I mean, wtf, which are you? Clob or
  String! HAHA

  Thoughts?

  Tim

  On Mar 18, 2:05 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
   Yeah, I saw the varchar(max) definition. I searched around and it looks
  like
   TEXT is deprecated in favor of VARCHAR(MAX) in Sql Server 2005.

  http://stackoverflow.com/questions/564755/sql-server-text-type-v-s-va.
  ..

   Maybe we need to make a new SqlServer2005 Driver that uses VARCHAR(MAX)
  and
   change the current one to use TEXT. Thoughts? Part of my confusion is
  that
   MappedText has an explicit String type parameter, but it *appears* that
   you're getting a ClobImpl. Could you me a favor and print out

   m.description.is.getClass

   and see what is really being stored in the field? I'm wondering if
  somehow
   the Clob is being converted to a string lower in the chain so you're
  just
   getting a string of net.sourceforge.jtds.jdbc.clobi...@aeaf68.

   Derek

   On Wed, Mar 18, 2009 at 3:45 AM, Timothy Perrett
  timo...@getintheloop.euwrote:

Hey Derek,

I know – this confused me too. The current MappedText for SQL Server
  is
being implemented as Varchar(MAX) in the database.

I always to m.description.toString and this way I get the clob
  reference.

Excuse my ignorance, but shouldn’t MappedText actually be using
  “text”
column type?

Cheers, Tim

On 17/03/2009 19:19, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

Actually, now I'm more confused. In the MappedText source it's using
  the
JDBC type VARCHAR. In MetaMapper's buildMapper method it appears that
VARCHAR should be retrieved via a resultSet.getString call, which
  should
return the String form of the data. I confirmed this in jTDS source:

 http://jtds.cvs.sourceforge.net/viewvc/jtds/jtds/src/java/net/sourcef...

Line 289. I have no idea how you're getting a real ClobImpl object,
  since
the source seems to indicate that it should just be a String:

class MappedText[T:Mapper[T]](val fieldOwner: T) extends
MappedField[String, T]

Derek

On Tue, Mar 17, 2009 at 2:08 PM, Derek Chen-Becker 
  dchenbec...@gmail.com
wrote:

OK, check out the wip-dcb-datetime branch and test that.

It looks like the CLOB object that jTDS returns doesn't override
  toString
to return the contents of the CLOB. It does, however, implement the
java.sql.Clob interface, so it may be possible to match that somehow
  and
make it work. I'm diving into parts of Mapper that I haven't really
  worked
with before, so no guarantees. Just to confirm, can you change your
  snippet
to use:

description - m.description.toString

and see if you get the same thing?

Thanks,

Derek

On Tue, Mar 17, 2009 at 1:05 PM, Timothy Perrett
  timo...@getintheloop.eu
wrote:

Hey Derek,

Awesome - thanks. I knew the DataTime one would be a simple fix - I
just don't know enough about mapper.

#17 is the one thats really hurting me right now... if you could fix
that I would be sooo grateful!

Cheers, Tim

On Mar 17, 6:02 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
 OK, actually, the change is in SqlServerDriver. I've made the
  change and
I'm
 running a build before committing. Once I push the branch could you
  check
it
 out and test? I'm looking at #17 right now, too.

 Derek

 On Tue, Mar 17, 2009 at 12:44 PM, Derek Chen-Becker
 dchenbec...@gmail.comwrote:

  I think the DateTime issue should be fixed pretty easily in
MappedDateTime
  itself. Let me make a new branch and make a minor change.

  Derek

  On Tue, Mar 17, 2009 at 12:09 PM, Timothy Perrett 
timo...@getintheloop.eu
   wrote:

  *bump*

  Al, any progress on these?

  Cheers, Tim

  On Mar 10, 11:04 am, Timothy Perrett timo...@getintheloop.eu
  wrote:
   Is someone able to take ownership of these tickets?

   Cheers, Tim

   On Mar 9, 5:52 pm, 

[Lift] Re: Forms validation formatter

2009-03-18 Thread marius d.



On Mar 18, 1:30 pm, Clemens Oertel clemens.oer...@gmail.com wrote:
 I admit to only having worked with mapper. I will look closer into  
 record, (quick glance: it comes with next-to-the-field messages, nice).

 Marius, are you referring to the toForm functions? I'm probably just  
 not seeing how to use them in a flexible manner. With respect to  
 validation, I was wondering how to apply conditional formatting based  
 on failed/succeeded validation.

Yes I am referring to toForm but note that you can provide your own
template. Please see formTemplate. I think the existent scaladocs can
be quite helpful. You can also apply an extremely flexible validation
model. Each field can have multiple validators and when you are
calling S.error(MetaRecord.validate(myRecord)) Lift will automatically
place the error messages near by your fields.

Nevertheless for youimediate needs the Record is probably not very
relevant yet as DB for Recrd is not yet implemented. I was just
pointing out that formsform validations are consistently provided by
Record. I think there is still some level of validation in mappers but
I haven't played with it yet ...


 Maybe a word or two to the background of my questions: I'm currently  
 trying to port a web application from RoR to lift. All I know is that  
 RoR does not work for me any longer, but I'm not sure where to go yet,  
 so I started to look around, and lift seems to be the most promising  
 candidate. The heavy exposure to RoR might have tainted my mind, true,  
 and I'm open to be shown the light.

 Anyways, this app is of medical nature, very database heavy, lots and  
 lots of fields. In order to avoid error upon data entry, the record's  
 form on screen must looks as closely like the paper version as  
 possible. A record's field can appear (and may be edited) in different  
 contexts. Sometimes, the same text field is displayed with different  
 lengths, the same text area may have different heights, all text  
 fields may be limited to a max length of n in some contexts, etc.

 Other aspect of the story: While working on the RoR version, the  
 directive was: Some boolean fields are to be displayed as drop downs  
 with 3 values (empty, yes, no). This now has changed, these boolean  
 fields are to be displayed as 3 radio buttons. One of course wants to  
 ensure that such a change only affects one area in the code base.

 That's what got me wondering: Is the toForm approach the best one for  
 my case?

 Thanks for listening,
 Clemens

 On 18-Mar-09, at 3:18 AM, marius d. wrote:





  FWIW please also take a look on Record and formvalidation support.

  Br's,
  Marius

  On Mar 17, 11:07 pm, Clemens Oertel clemens.oer...@gmail.com wrote:
  Hello everybody,

  Still trying to learn how to use lift efficiently and effectively, I
  got a little bit confused about the toForm function in the model/
  mappers. Admittedly, my web framework background may be limited, but
  this looked to me as if some view code snuck into the model space
  there (I must admit that I do like how RoR tries to keep the models
  fairly clean of both controller  code and of view code).

  For my first little project, I was going to encapsulate the HTML  
  field
  formatting into a separate class (similar to what RoR does, but  
  making
  use of the type system).

  This is a very quick brain dump, not running code.

  // The different field types, at a higher level than HTML
  abstract class InputType
  case class TextField extends InputType
  case class DateField extends InputType
  case class DateTimeField extends InputType

  // Rendering hints that an form field formatter may use, could also  
  be
  called FormGenerator ...
  abstract class RenderingHint
  case class MinLength(l: Int) extends RenderingHint
  case class MaxLength(l: Int) extends RenderingHint

  // Input-type aware callback'ed formatter, from the model's  
  perspective
  trait InputTypeHandler {
     def handleTextField(fieldID: String, presetValue: String,
  renderingHints: RenderingHint*)

     def handleDateField(fieldID: String, presetValue: Date,
  renderingHints: RenderingHint*)

  }

  // A model class using the callback
  class ModelClass {
     object aField extends MappedString(this, 128) {
       def inputTypeCallback(InputTypeHandler handler) {
         // A reasonable default should/could be pushed upwards in the
  type hierarchy
         handler.handleTextField(fieldID, this.is,  
  MaxLength(this.length))
       }
     }

  }

  This InputTypeHandler could be a nice spot to deal with validation
  result formatting:

  class AnInputFormatter(errors: List[FieldError]) extends
  InputTypeHandler {
     def handleTextField(fieldID: String, presetValue: String,
  renderingHints: RenderingHint*) {
       errors.filter(_._1 == fieldID).match {
         case Nil = /* format field normally */
         case xs = /* format as error, i.e. red background, error
  messages right of field  */
       }
     }

     

[Lift] Re: Forms validation formatter

2009-03-18 Thread Clemens

 Yes I am referring to toForm but note that you can provide your own
 template. Please see formTemplate.

I did, thanks for the pointer. formTemplate applies to the record as a
whole, right? If I want to render a record differently, I could set
different templates one after the other - even though this introduces
more evil state dependence.

Just trying to figure out how to how to solve my case where a field is
supposed to be rendered differently in different contexts - a single
asXHtml variable doesn't seem to allow this.

Also, all the formatting happens in what I thought was the DB
abstraction layer, which still makes context-sensitive formatting
difficult (again, as I understand things right know) - it's just
personal style, but I like to keep control flow and view stuff outside
my data models.

But record promises to give me a lot more flexibility than mapper,
that's great.

 I think the existent scaladocs can
 be quite helpful.

Point taken ;-)

 Nevertheless for youimediate needs the Record is probably not very
 relevant yet as DB for Recrd is not yet implemented. I was just
 pointing out that formsform validations are consistently provided by
 Record. I think there is still some level of validation in mappers but
 I haven't played with it yet ...

Oh, the validation is working just fine with mapper. It's only the
lack of flexibility with respect to automated output that's I'm
talking about.

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] Re: Forms validation formatter

2009-03-18 Thread marius d.



On Mar 18, 8:54 pm, Clemens clemens.oer...@gmail.com wrote:
  Yes I am referring to toForm but note that you can provide your own
  template. Please see formTemplate.

 I did, thanks for the pointer. formTemplate applies to the record as a
 whole, right? If I want to render a record differently, I could set
 different templates one after the other - even though this introduces
 more evil state dependence.

Well you can use different RecordMeta implementations if you need to
different representation of a record without sequential template
change. So no state dependency.


 Just trying to figure out how to how to solve my case where a field is
 supposed to be rendered differently in different contexts - a single
 asXHtml variable doesn't seem to allow this.

 Also, all the formatting happens in what I thought was the DB
 abstraction layer, which still makes context-sensitive formatting
 difficult (again, as I understand things right know) - it's just
 personal style, but I like to keep control flow and view stuff outside
 my data models.

Well keeping close view representation and backend abstraction makes a
lot of sense as it reduces lots of complexity. Having records/mappers
that know how to represent themselves in different contexts (DB,
xhtml) brings a lot of benefits an simplicity. I admit thought that
it's quire a paradigm shift from ... say MVC mindset. But let's not
get into a patterns debate now .. we had plenty of those :)


 But record promises to give me a lot more flexibility than mapper,
 that's great.

  I think the existent scaladocs can
  be quite helpful.

 Point taken ;-)

  Nevertheless for youimediate needs the Record is probably not very
  relevant yet as DB for Recrd is not yet implemented. I was just
  pointing out that formsform validations are consistently provided by
  Record. I think there is still some level of validation in mappers but
  I haven't played with it yet ...

 Oh, the validation is working just fine with mapper. It's only the
 lack of flexibility with respect to automated output that's I'm
 talking about.

I'm sorry maybe I'm missing something but can you give a Minimalistic
example that would yield the lack of flexibility of Mapper for your
needs? Perhaps we can improve things or perhaps certain things are
already there waiting to be discovered.


 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] Re: Forms validation formatter

2009-03-18 Thread Clemens

Thank you for your patience, Marius.

 Well you can use different RecordMeta implementations if you need to
 different representation of a record without sequential template
 change. So no state dependency.

I'm really not trying to be difficult, but having multiple RecordMeta
instances, for which the HTML output seems to be only one of many
functionalities, seems to be shooting with canons at sparrows. Having
a toForm functions that takes some template provider as input could be
one option.

Anyways, I was not even thinking at record level, but rather at field
level. See below.

 Well keeping close view representation and backend abstraction makes a
 lot of sense as it reduces lots of complexity. Having records/mappers
 that know how to represent themselves in different contexts (DB,
 xhtml) brings a lot of benefits an simplicity. I admit thought that

(Btw, by context I meant different HTML display contexts.)

I agree that a field should be able to provide hints about how it
should be represented, such as max/min length, type, defaults, etc.

Depending on the logical context within the app I'm working on, a
record (and thus its fields) can have multiple representations: row in
a table, complete record as a table, abbreviated record as a table,
complete form as table, form as row in a table, form with mandatory
fields only, records have to be printed out as ini-files, etc.
Unfortunately, it's not me making this stuff up, it's fixed
requirements.

At field level, there are also different possible representations. For
example, I would like to be able to represent a record as a tabular
form, with every input field being shown with its preferred length. In
addition to this, I would like to have a different form with a fixed
with multi-column layout; for this form, no input field must be wider
than 40 characters. Somehow I have to tell the fields not to make
themselves wider than 40 characters, and not just use the maximum
length.

Again, what it boils down to is the desire to be able to have
different representations for a single record, and to have different
possible representations for each field. This while maintaining as
much encapsulation as possible.

Hence my original idea to have fields provide representation hints
(eg. I'd like to be 80 characters wide), and then have another
something that uses these hints for the actual output, while
potentially adding additional hints/constrains (eg. No one get's more
than 40 characters), css directives, a little red star in front of
mandatory fields (based on a rendering hint),  Depending on how
the record is being displayed, I would use a different something,
and neither the record nor the fields would have to know anything
about application context.

If I then had a default something, which renders fields the way they
are rendered right now, and have the various record fields
(StringField, etc.) call upon this default something whenever their
toForm-function is called, no one would notice something has changed.
But I could also call toForm(formRenderer) for non-default rendering.

 it's quire a paradigm shift from ... say MVC mindset. But let's not
 get into a patterns debate now .. we had plenty of those :)

Agreed.

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] Re: FieldType and ForeignType

2009-03-18 Thread David Pollak
On Tue, Mar 17, 2009 at 9:49 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 I'm going to fix the problem tomorrow... but I was wondering why the
 compilation issues.


Fixed.  Please verify.




 On Tue, Mar 17, 2009 at 9:44 PM, Jorge Ortiz jorge.or...@gmail.comwrote:

 Argh. Good call. I don't know as I was debugging through IRC, but it was
 probably 2.7.2 since he was using the todo example site from the Lift
 workshop.

 And I told him to upgrade to Lift 1.0. That's going to cause problems. Oh
 well.

 --j

 On Tue, Mar 17, 2009 at 8:23 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What version of Scala?


 On Tue, Mar 17, 2009 at 5:45 PM, Jorge Ortiz jorge.or...@gmail.comwrote:

 And if they're useful, can subclasses of MappedForeignKey define them
 more exactly?

 Errors looked like this:

 [WARNING] 
 C:\workspace\liftapp\src\main\scala\com\liftworkshop\model\ToDo.scala:

 16: error: object creation impossible, since type ForeignType in trait 
 MappedFor
 eignKey with bounds : Nothing : 
 net.liftweb.mapper.KeyedMapper[Long,my.liftapp
 .model.User] is not defined
 [WARNING]   object owner extends MappedLongForeignKey( this , User )




 [WARNING]  ^


 [WARNING] 
 C:\workspace\liftapp\src\main\scala\com\liftworkshop\model\ToDo.scala:
 16: error: object creation impossible, since type FieldType in trait 
 MappedForei

 gnKey with bounds : Nothing : Long is not defined
 [WARNING]   object owner extends MappedLongForeignKey( this , User )
 [WARNING]  ^


 --j


 On Tue, Mar 17, 2009 at 5:42 PM, Jorge Ortiz jorge.or...@gmail.comwrote:

 Anyone know what these two types:

   type FieldType : KeyType
   type ForeignType : KeyedMapper[KeyType, Other]

 in trait MappedForeignKey are doing?

 They're never fully defined and never used, but somehow were causing
 compile problems in someone's code.

 If they're useless, can they be axed?

 --j







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




-- 
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: Where to continue after Getting Started?

2009-03-18 Thread Derek Chen-Becker
I whipped up a quick page on the wiki:

http://wiki.liftweb.net/index.php?title=Lift_Compared_to_Other_Frameworks

Let me know if that's OK before adding the link to the site.

Derek

On Tue, Mar 17, 2009 at 7:26 AM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 On Tue, Mar 17, 2009 at 1:34 AM, erik.fris...@googlemail.com 
 erik.fris...@googlemail.com wrote:


 Thanks for the responses, guys.

 So far I have developed big PHP apps with the Zend Framework, and I
 found the apps quite manageable. Yes, it requires some careful
 planning to not end up with a big mess of undocumented code, but so
 far we always got there ;)

 I think I will look into the Programming in Scala Book to get an
 overview of Scala,


 Really great summaries from Charles and Derek.  I'd like to see these on
 the wiki with a link from the Lift home page.

 I'd like to suggest starting with Beginning 
 Scalahttp://apress.com/book/view/1430219890rather than Programming in 
 Scala.  Programming in Scala is a heavier text
 that is a much broader view of the language.  Beginning Scala is shorter and
 much more of an introductory text (at least the first 6 chapters.)  I view
 Beginning Scala as a gateway drug to Programming in Scala.  Finally, the
 Scala idioms in Beginning Scala are unsurprisingly similar to the idioms in
 Lift (although I spend very little time actually discussing Lift in the
 book.)


 then the Lift Book. I think it will all come to me
 when I develop a small app. Thanks for all your feedback, it's really
 exciting to get into this new language. I will stick around and let
 you know how I progress.

 Anyways, you guys are an amazing help. I really appreciate that.

 Erik

 On Mar 17, 4:45 pm, Derek Chen-Becker dchenbec...@gmail.com wrote:
  Over the years I've written a fair amount of PHP code for in-house
  applications (enterprise ticket tracking system, network equipment
  management, etc) and the experience has generally not been great. I
 think
  PHP functions very well for compact, well-defined apps, but the lack of
  structure in the PHP libraries ends up being a burden to non-trivial
  projects IMHO. In particular, the library is inconsistent and often
  incoherent. As an example, compare database access (pretty common
  functionality) in PHP vs Java. One app I wrote in PHP started out
 running
  against MySQL and then later needed to change to SQL Server. What would
 have
  been a simple database URL change (and replacing a jar file) in Java was
 a
  non-trivial search and replace of code throughout the app. I seem to
  remember there also being some functions that didn't correlate between
 the
  two driver types. In short, it was a very painful experience. I know
 that
  Pear and some other facades have been developed to make this more
  transparent, but overall I still feel like the library doesn't have an
  overarching theme. It's more a whole lot of bits and pieces stitched
  together.
 
  Another advantage that Lift has, being built atop the JVM, is full
 access to
  all Java libs, and the simplicity of adding libraries as needed. If I
 need
  to add SNMP support to my Lift app (network equipment), I just drop the
 jar
  file in. To add SNMP to PHP I had to compile a whole slew of libraries
 and
  recompile the PHP module. On a similar vein, the ecosystem of Java
 libraries
  is (in my estimation) at least an order of magnitude larger and more
 mature
  than for what's out there for PHP.
 
  Finally, and most importantly, the view-first structure of Lift is
 huge.
  It's difficult to overstate how much this can help improve code
 organization
  and page structure. Essentially, you're writing a whole bunch of little
  components in Scala and then composing them using pure XML templates.
  Templates can embed other templates, and can embed themselves into other
  templates as well, so you have incredible flexibility in how you lay
 things
  out while keeping things fairly simple. The ability to keep your code
 and
  presentation layer stuff in small, easily digestible chunks is what will
  keep you and your team sane when you tackle big projects. Of course, you
 can
  do this in PHP as well, but with Lift the capability is an integral part
 of
  the overall design.
 
  You might want to take a look at our demo app for the book:
 
  http://github.com/tjweir/pocketchangeapp/tree/master
 
  It covers a lot of Liftisms (not all), and I'd be happy to answer any
  questions you have about it.
 
  Derek
 
  On Mon, Mar 16, 2009 at 7:29 PM, Charles F. Munat c...@munat.com
 wrote:
 
 
 
   PHP is a language that's easy to learn thus easy to get started with.
   But down the road, that ease comes with a steep price unless you are
   very disciplined about establishing protocols for coding and sticking
 to
   them. It is very easy to end up with unmaintainable spaghetti code. I
   speak from painful experience.
 
   PHP grew up by aggregation, thus it has an odd mixture of syntax and
   conventions, some from 

[Lift] List of existing Lift deployments

2009-03-18 Thread Alex

I am very interested in using Scala and Lift for my next project or
startup, but it is difficult right now to persuade anyone to take a
chance on the platform.

Is there a good list somewhere of existing Lift sites and the
experiences of developing and deploying them?  Or a list of startups
or projects in progress?  I heard a rumor Twitter is porting to Scala
- anyone know if that's true?



--~--~-~--~~~---~--~~
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: List of existing Lift deployments

2009-03-18 Thread David Pollak
Twitter uses Scala as part of their back end infrastructure.  Evan Weaver
presented on this at QCon in London last week and Al3x Payne will be
presenting on it at Web 2.0 on April 1.  See
http://www.scala-lang.org/node/1225
Siemens is using Lift and Scala as part of their ESME deployment.  See
http://www.scala-lang.org/node/1154

The ESME project is currently an Apache incubatee:
http://incubator.apache.org/esme/ and for more on ESME, see
http://blog.esme.us

SAP runs a Lift and Scala based component as part of their Collaboration
Workspace.

Enthiosys' Innovation Games Online (http://buyafeature.com) is entirely
Lift-based.

See the Lift quotes page: http://liftweb.net/quotes.html

Search GitHub for Scala-based projects.  You will find some interesting
copyrights on them.

Hope this helps.

On Wed, Mar 18, 2009 at 5:33 PM, Alex a...@liivid.com wrote:


 I am very interested in using Scala and Lift for my next project or
 startup, but it is difficult right now to persuade anyone to take a
 chance on the platform.

 Is there a good list somewhere of existing Lift sites and the
 experiences of developing and deploying them?  Or a list of startups
 or projects in progress?  I heard a rumor Twitter is porting to Scala
 - anyone know if that's true?



 



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