Re: [Lift] Serious widget action

[Jim Barrows]

On Tue, Mar 9, 2010 at 8:45 PM, aw  wrote:

> It is time for me to add some serious widgets to my lift app.
>
> So far, I am most enamored by ExtJS.
> Another alternative could possibly be ZK.
>
> Does anybody have any experience with these frameworks?  Can you
> comment on why integrating them with Scala/Lift would be a bad idea
> (or not work)?
>
> I searched for some historical posts on ExtJS and discovered some
> threads about it's license and how it impacts inclusion in the lift
> framework.  Would a commercial license prohibit it from being a lift-
> widget submodule candidate?
>
> Does anybody have a better suggestion that you think can compete with
> ExtJS?
>

I'm using ExtJS in anger at 0rk.  3.1.1 is nice.  3.0.0 is weird.  Some odd
bugs being reported.  We're also getting some weird interactions with some
other js libraries ( I won't mention it, it's not available anymore, and if
it was it just leave you scarred) and CSS.  However, that's the other
libraries fault more then ExtJS's.

If you want something that looks and feels as close to a desktop app as you
can get.. ExtJS can do the job well.  With Lift providing the JSON, it would
be hard to go wrong.  That said.. ExtJS is not an easy beast to learn.  It's
even worse to try and L10N it easily.  I would not try and use just pieces
of it, it's really not designed to do that.  It seems to me to be an all or
nothing approach.  That's not say you can't use it piecemeal, I think you
lose a lot of flexibility (especially in layout) that way.

I wouldn't use it if left to my own devices though, unless I had a
requirement for a desktop app on the web.  It's serious overkill.


-- 
James A Barrows

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

Re: [Lift] Reorganize mapper specs?

[Jim Barrows]

On Mon, Mar 8, 2010 at 2:16 PM, Naftoli Gugenheim wrote:

> Not sure -- it sounded like you were describing a scenario with separate
> test files for each combination of area being tested and driver, where I was
> describing combining multiple areas in one file (like MapperSpecs is now).
> Maybe I misunderstood.
>

Both can go into one file.
The second one would have a file name of ItemUnderTest.scala while each
separate specs test could still follow the driver specific naming
convention.  The one that tests things that shouldn't care about driver
would be called ItemUnderTestSpecs.




>
> ---------
> Jim Barrows wrote:
>
> On Mon, Mar 8, 2010 at 1:59 PM, Naftoli Gugenheim  >wrote:
>
> > Currently what I did is combine ItemListSpecs with another test, so I
> gave
> > it a more generic name than ItemsList, hence MapperSpecs2. The idea is
> that
> > some tests really have zero to do with the vendor, but higher-level
> > behavior. H2MemoryProvider is incidental--in memory databases are perfect
> > for testing. So I'd prefer not putting the choice of testing db in the
> name
> > of a driver-independent test.
> > If an ORM is a form of caching then these are cache-related specs.
> > If David vetoes the change on RB, a name is irrelevant; and depending on
> > his proposal it may be temporary; but I'm looking for a name that says
> "More
> > Mapper Specs except these specs are run on one arbitrary driver rather
> than
> > on all of them, because these specs are driver-independent by
> definition."
> >
>
> I'm curious how my naming proposal doesn't do that?  In a much more
> structured way?
>
>
> --
> James A Barrows
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

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

Re: [Lift] Reorganize mapper specs?

[Jim Barrows]

On Mon, Mar 8, 2010 at 1:59 PM, Naftoli Gugenheim wrote:

> Currently what I did is combine ItemListSpecs with another test, so I gave
> it a more generic name than ItemsList, hence MapperSpecs2. The idea is that
> some tests really have zero to do with the vendor, but higher-level
> behavior. H2MemoryProvider is incidental--in memory databases are perfect
> for testing. So I'd prefer not putting the choice of testing db in the name
> of a driver-independent test.
> If an ORM is a form of caching then these are cache-related specs.
> If David vetoes the change on RB, a name is irrelevant; and depending on
> his proposal it may be temporary; but I'm looking for a name that says "More
> Mapper Specs except these specs are run on one arbitrary driver rather than
> on all of them, because these specs are driver-independent by definition."
>

I'm curious how my naming proposal doesn't do that?  In a much more
structured way?


-- 
James A Barrows

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

Re: [Lift] Reorganize mapper specs?

[Jim Barrows]

On Mon, Mar 8, 2010 at 1:00 PM, Naftoli Gugenheim wrote:

> I'm not 100% clear on your proposal.
> First of all, is what I've done (on RB) in the meantime okay (without a
> ticket)? Basically, I renamed ItemsListSpecs to MapperSpecs2 and put the
> test for issue 370 there. MapperSpecs2 only uses H2 memory db. (Any
> suggestions for a better name?)
>

ItemsListOnH2MemorySpecs.scala
ItemsListH2MemorySpecs.scala
ItemsList_H2Memory_Specs.scala -- this is probably the most readable and
sets up the pattern for names like
WhatsUnderTest_JDBCDriverSpecificName_Specs

It's wordy, but if you want everything in the same directory, then that's
what happens.  Probably better would be:

itemsList/ItemsListSpecs.scala
itemsList/H2MemorySpecs.scala
itemsList/JdbcDriverSpecs.scala

Less wordy, but you have one more directory to traverse to get there.
 However if you figure we'll have mysql, sqlserver, oracle, h2 & postgres at
a minimum, I think that this actually easier on the eyes when trying to find
the right jdbc driver specific tests.  In addition, we'll probably at some
point end up with version specific test cases as well.  That should probably
go in the same file, and use the version as part of the name.

So the specs name (ItemsList, in this case) is the cross driver tests, with
the driver specific specs test in the same directory.


Any other ideas?




> As for your proposal, are you saying that things like ItemsListSpecs and
> 370, which deal with high-level Mapper API not directly related to the
> database, should ideally be testable on every database vendor? And/or are
> you saying that *all* the tests should be run by default on only one driver
> but have the option to run on all?
> Also, is it possible to run MapperSpecs for all the drivers in parallel,
> and if so would that cause it to finish faster?
>
> Thanks.
>
> -
> David Pollak wrote:
>
> On Sun, Mar 7, 2010 at 12:47 PM, Naftoli Gugenheim  >wrote:
>
> > Based on discussion on Review Board item 247, I want to propose the
> > following change to the organization of Mapper specs.
> > Currently there are four files in
> > framework/lift-persistence/lift-mapper/src/test/scala/net/liftweb/mapper:
> > DBProviders - initalization for each provider to be tested
> > MapperSpecs - the original set of tests. Tested per provider, which makes
> > sense for tests that interact with the database
> > ManyToManySpecs - tests I added with an enhancement to ManyToMany to not
> > choke on broken joins. Only uses DBProviders.H2MemoryProvider. When FK
> > constraints are enabled in H2 this will have to disable them.
> > ItemsListSpecs - tests for a bugfix in ItemsList. Also only uses
> > DBProviders.H2MemoryProvider.
> >
> > Currently MapperSpecs takes about five minutes to run on my laptop. So
> any
> > new test that isn't driver dependent should probably not be tested on all
> > drivers. Thus I'm considering consolidating ItemsListSpecs and
> > ManyToManySpecs into one specs for all H2MemoryProvider-only tests.
> > Then, with two set of tests, one run for each driver and one not, maybe
> > their names should reflect that.
> > It's just a possible idea, but what do people think? Also, if I would go
> > ahead would it need a ticket or just straight to RB?
> >
>
> I agree with the goal of shortening the time it takes to run mapper tests.
>
> I would like there to be a way (not the default, but something that can be
> done with some form of compiler/maven flags) to run all cross-products of
> all tests so we just make 100% sure that things work on all RDBMSs.
>
> Please open a ticket first before putting stuff on RB.
>
>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com
> 
> >
> > .
> > For more options, visit this group at
> > http://groups.google.com/group/liftweb?hl=en.
> >
> >
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

-- 
You received this message because you are subscribed to the 

Re: [Lift] Re: IdPK Model boiler-plate

[Jim Barrows]

How about:  PrimaryKeyEquality

which would read something like: "class foo extends IdPk with
PrimaryKeyEquality"


On Mon, Mar 8, 2010 at 10:25 AM, David Pollak  wrote:

> I'm going to implement this as a sub-trait of IdPK (anyone got a good name
> for the trait).  So, by default, you'll get the current behavior, but if you
> think equality should be based on primary key rather than on the field
> values, you don't have to have all the boilerplate.
>
> On Sun, Mar 7, 2010 at 11:01 PM, aw  wrote:
>
>> What's wrong with KeyedMapper's implementation?
>>
>> Well, that was exactly why I was asking the question, "Is this
>> implementation for equals and hashCode a good idea?"  I had gotten
>> this at some point, been using it, and am only questioning it now
>> because if it truly is a good idea, I think it should be part of the
>> framework...
>>
>> The hashCode implementation for KeyedMapper looks essentially the
>> same:
>>
>>this.id.is.hashCode
>> vs.
>>primaryKeyField.is.hashCode
>>
>> However, the equals implementation for KeyedMapper is a little
>> different:
>>
>>  override def equals (other : Any) = other match {
>>case t : Team if t.id.is == this.id.is => true
>>case _ => false
>>  }
>>
>> vs.
>>
>>  override def equals (other : Any) : Boolean = {
>>other match {
>>  case null => false
>>  case km: KeyedMapper[Nothing,Nothing] if
>> this.getClass.isAssignableFrom(km.getClass) ||
>>km.getClass.isAssignableFrom(this.getClass) =>
>> this.primaryKeyField == km.primaryKeyField
>>  case k => super.equals(k)
>>}
>>  }
>>
>> There are some subtle differences.  I have never used inheritance with
>> Mapper to make a complex class hierarchy, so I'm not 100% sure of the
>> ramifications (or if it is even possible).
>>
>>
>> Personally, I would imagine that two mapper objects are equal using a
>> primary key comparison only as long as they are read-only singletons.
>> If I had instance #1 loaded into val A and again into var B, then
>> modified some elements of B, I would no longer expect A to equal B --
>> but with the above implementation, they remain equal as long as the
>> primary key field is not altered.
>>
>> In JPA/Hibernate land, I actually have a different approach for equals
>> and hashCode:  each field is compared with the exception of the @Id
>> and @Version columns because they can change upon persistence, and so
>> are not part of the equality.  I leverage Apache Commons-Lang
>> builders:
>>
>>@Override
>>public boolean equals (final Object obj) {
>>return EqualsBuilder.reflectionEquals(this, obj,
>>EXCLUDE_FROM_EQUALS_AND_HASH_CODE);
>>}
>>
>>@Override
>>public int hashCode () {
>>return HashCodeBuilder.reflectionHashCode(this,
>>EXCLUDE_FROM_EQUALS_AND_HASH_CODE);
>>}
>>
>>/**
>> * Exclude fields from equals, hashCode, and compareTo that may
>> change upon
>> * persistence.
>> *
>> * @see http://www.hibernate.org/109.html";>Best
>> strategies for
>> * implementation of equals() and hashcode() in your persistent
>> classes.
>> */
>>private static final String [] EXCLUDE_FROM_EQUALS_AND_HASH_CODE =
>> {"id", "version"};
>>
>> So, if Hibernate suggests that you should NOT just compare the primary
>> key field, why should Lift-Mapper be doing that?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] Re: SQL error

[Jim Barrows]

On Thu, Mar 4, 2010 at 2:10 PM, Mads Hartmann Jensen wrote:

> This has already been on reviewboard and comitted to master - should i send
> out a breaking change note?
>
> I'm not sure i get why this is a breaking change though?
>


Not sure if it is.  However it's certainly something folks will want to
upgrade to asap.

Naming columns keywords in SQL is bad.



> On 04/03/2010, at 22.07, Jim Barrows wrote:
>
> On Thu, Mar 4, 2010 at 1:47 PM, Naftoli Gugenheim wrote:
>
>> Is blob a standard reserved word or only on MySQL?
>> If the latter this is a potential breaking change.
>>
>
> Blob is not apparently part of the ANSI standard reserved word for SQL.  I
> would have sworn it was.   However, it is common in Oracle, MS SQL server
> and others.  Might as well be standard.
>
>
>
>>
>> -
>> Mads Hartmann wrote:
>>
>> Ah! That fixed it, thanks a lot Jeppe ;)
>>
>> I'm not sure what to say in the ticket though, the column-name blob
>> was a bad choise made by me.
>>
>> On Mar 4, 1:32 pm, Jeppe Nejsum Madsen  wrote:
>> > On Thu, Mar 4, 2010 at 1:25 PM, Mads Hartmann 
>> wrote:
>> > > Hello everyone,
>> > > I'm not sure if this is a lift problem or it's me. I'm trying to add
>> > > the ability to upload images to a project - I'm using the code
>> > > explained here:
>> > >http://groups.google.com/group/liftweb/browse_thread/thread/b0509263e.
>> ..
>> >
>> > > I added two mapper classes:
>> > > ---
>> > > class ImageInfo extends LongKeyedMapper[ImageInfo] with IdPK {
>> > >  def getSingleton = ImageInfo
>> >
>> > >  object date extends MappedLong(this) {
>> > >override def defaultValue = Helpers.millis
>> > >  }
>> > >  object mimeType extends MappedPoliteString(this, 64)
>> > >  object name extends MappedPoliteString(this, 256) {
>> > >override def dbIndexed_? = true
>> > >override def defaultValue = ""
>> >
>> > >private def noSlashes(s: String) : List[FieldError] =
>> > >  if (s.contains("/"))
>> > >List(FieldError(this, Text("Image name
>> \"" + s + "\" may not
>> > > contain \"/\"")))
>> > >  else
>> > >Nil
>> >
>> > >override def validations =
>> > >  valMinLen(1, "Image name must not be empty") _ ::
>> > >  valUnique("Image name must be unique") _ ::
>> > >  noSlashes _ ::
>> > >  super.validations
>> > >  }
>> >
>> > >  object blob extends MappedLongForeignKey(this, ImageBlob)
>> >
>> > >  def deleteWithBlob {
>> > >this.blob.obj match {
>> > >  case Full(x) => x.delete_!
>> > >  case _ =>
>> > >}
>> > >this.delete_!
>> > >  }
>> > > }
>> > > -
>> > > and
>> > > --
>> > > class ImageBlob extends LongKeyedMapper[ImageBlob] with IdPK {
>> > >  def getSingleton = ImageBlob
>> >
>> > >  object image extends MappedBinary(this)
>> > > }
>> > > -
>> >
>> > > The schemifier couldn't create the tables it gave to following
>> > > error ::
>> > > You have an error in your SQL syntax; check the manual that
>> > > corresponds to your MySQL server version for the right syntax to use
>> > > near 'blob BIGINT UNSIGNED)  ENGINE = InnoDB' at line 1
>> >
>> > > this is the sql statement it tried to execute
>> >
>> > > CREATE TABLE imageinfo (name VARCHAR(256) , id BIGINT UNSIGNED NOT
>> > > NULL AUTO_INCREMENT UNIQUE KEY , date_c BIGINT , mimetype
>> > > VARCHAR(64) , blob BIGINT UNSIGNED)  ENGINE = InnoDB
>> >
>> > I looks like it tries to create a column named blob, afaiks blob is a
>> > reserved word in MySqlhttp://
>> dev.mysql.com/doc/refman/5.0/en/reserved-words.html
>> >
>> > You could try renaming the field. If this solves the problem, please
>> > file a ticket
>> >
>> > /Jeppe
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this gr

Re: [Lift] Re: SQL error

[Jim Barrows]

On Thu, Mar 4, 2010 at 1:47 PM, Naftoli Gugenheim wrote:

> Is blob a standard reserved word or only on MySQL?
> If the latter this is a potential breaking change.
>

Blob is not apparently part of the ANSI standard reserved word for SQL.  I
would have sworn it was.   However, it is common in Oracle, MS SQL server
and others.  Might as well be standard.



>
> -
> Mads Hartmann wrote:
>
> Ah! That fixed it, thanks a lot Jeppe ;)
>
> I'm not sure what to say in the ticket though, the column-name blob
> was a bad choise made by me.
>
> On Mar 4, 1:32 pm, Jeppe Nejsum Madsen  wrote:
> > On Thu, Mar 4, 2010 at 1:25 PM, Mads Hartmann  wrote:
> > > Hello everyone,
> > > I'm not sure if this is a lift problem or it's me. I'm trying to add
> > > the ability to upload images to a project - I'm using the code
> > > explained here:
> > >http://groups.google.com/group/liftweb/browse_thread/thread/b0509263e.
> ..
> >
> > > I added two mapper classes:
> > > ---
> > > class ImageInfo extends LongKeyedMapper[ImageInfo] with IdPK {
> > >  def getSingleton = ImageInfo
> >
> > >  object date extends MappedLong(this) {
> > >override def defaultValue = Helpers.millis
> > >  }
> > >  object mimeType extends MappedPoliteString(this, 64)
> > >  object name extends MappedPoliteString(this, 256) {
> > >override def dbIndexed_? = true
> > >override def defaultValue = ""
> >
> > >private def noSlashes(s: String) : List[FieldError] =
> > >  if (s.contains("/"))
> > >List(FieldError(this, Text("Image name
> \"" + s + "\" may not
> > > contain \"/\"")))
> > >  else
> > >Nil
> >
> > >override def validations =
> > >  valMinLen(1, "Image name must not be empty") _ ::
> > >  valUnique("Image name must be unique") _ ::
> > >  noSlashes _ ::
> > >  super.validations
> > >  }
> >
> > >  object blob extends MappedLongForeignKey(this, ImageBlob)
> >
> > >  def deleteWithBlob {
> > >this.blob.obj match {
> > >  case Full(x) => x.delete_!
> > >  case _ =>
> > >}
> > >this.delete_!
> > >  }
> > > }
> > > -
> > > and
> > > --
> > > class ImageBlob extends LongKeyedMapper[ImageBlob] with IdPK {
> > >  def getSingleton = ImageBlob
> >
> > >  object image extends MappedBinary(this)
> > > }
> > > -
> >
> > > The schemifier couldn't create the tables it gave to following
> > > error ::
> > > You have an error in your SQL syntax; check the manual that
> > > corresponds to your MySQL server version for the right syntax to use
> > > near 'blob BIGINT UNSIGNED)  ENGINE = InnoDB' at line 1
> >
> > > this is the sql statement it tried to execute
> >
> > > CREATE TABLE imageinfo (name VARCHAR(256) , id BIGINT UNSIGNED NOT
> > > NULL AUTO_INCREMENT UNIQUE KEY , date_c BIGINT , mimetype
> > > VARCHAR(64) , blob BIGINT UNSIGNED)  ENGINE = InnoDB
> >
> > I looks like it tries to create a column named blob, afaiks blob is a
> > reserved word in MySqlhttp://
> dev.mysql.com/doc/refman/5.0/en/reserved-words.html
> >
> > You could try renaming the field. If this solves the problem, please
> > file a ticket
> >
> > /Jeppe
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

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

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

[Jim Barrows]

You can use the E editor for windows, and with luck soon on Linux as well.
 It will read and use all TextMate bundles.
http://www.e-texteditor.com/

On Thu, Mar 4, 2010 at 11:17 AM, David Pollak  wrote:

> I might have to fire up my Mac to try this out. ;-)
>
> On Wed, Mar 3, 2010 at 3:34 PM, Mads Hartmann Jensen wrote:
>
>> Ok,
>> This is the last time I'll bump this  (I promise) - anyone using TextMate
>> can follow the bundle on github.
>>
>> I improved the bundle and it's fairly usable now, check  out a teaser
>> video here:
>> http://www.sidewayscoding.com/2010/03/textmate-lift-bundle-v02.html
>>
>> Thanks
>>
>> On 23/02/2010, at 19.08, Mads Hartmann Jensen wrote:
>>
>> > Duh, I comittet a wrong version of the bundle to git! The right version
>> is up now if you wan't to give it a try Indrajit :) I would appreciate the
>> feedback:
>> > http://github.com/mads379/Lift-TextMate-Bundle
>> >
>> > On 22/02/2010, at 13.12, Mads Hartmann Jensen wrote:
>> >
>> >> Don't get too excited, it's very beta right now ;)
>> >>
>> >> Sent from my iPhone
>> >>
>> >> On 22/02/2010, at 13.04, Indrajit Raychaudhuri 
>> wrote:
>> >>
>> >>> Heavens! Need to give this a shot.
>> >>>
>> >>> On 22/02/10 4:55 PM, Mads Hartmann wrote:
>>  Hello everyone,
>>  I've been working a bit on a TextMate bundle for Lift projects that
>>  has codecompletion. It's still very beta but I'm sure someone would
>>  find it helpfull :)
>> 
>>  If you're interested you can read a bit more about it here:
>> 
>> http://www.sidewayscoding.com/2010/02/lift-textmate-bundle-now-with-primitive.html
>> 
>>  NB: It's nowhere near as good as what I've seen in intelliJ (haven't
>>  tried netbeans or eclipse) but that doesn't mean it isn't helpful :)
>> 
>>  If you want to help out, please fork me on github
>> http://github.com/mads379
>> 
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> Groups "Lift" group.
>> >>> To post to this group, send email to lift...@googlegroups.com.
>> >>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> >>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>> >>>
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] Re: LiftRules.rewrite, 404 error

[Jim Barrows]

On Thu, Mar 4, 2010 at 6:34 AM, Gang  wrote:

> Could somebody answer my question?  If it's too stupid a question to
> answer, please let me know that too.  It just seems to me that unless
> I add a link to SiteMap, the links( tag) in my page just return
> 404.  And I tried following URL rewrite without adding link to
> SiteMap, still 404 error.
>

That's correct.  If you're using sitemap you have to add the directory the
resource is in, or the resource itself to SiteMap.  SiteMap is more then
just a menu generator.  It's also the security system and other things.


>
> Thanks
>
> On Feb 28, 6:20 pm, Gang  wrote:
> > All,
> >
> > I have this rewrite returning 404 error.  Here are what I did:
> >
> > URL:  ../app-context-path//images/CBDU-1098-BCV?F1115261516749FQD=_
> >
> > Template:  src/main/webapp/viewImages.html
> >
> > LiftRules.rewrite.append( {
> >   case RewriteRequest(ParsePath("images" :: sku :: Nil, _, _,_),
> > _, _) =>
> > RewriteResponse("viewImages" :: Nil, Map("imageId" ->
> > sku))
> > } )
> >
> > Are there any other settings I need to set?  I have looked around but
> > couldn't find any other than the basics listed above.  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 lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

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

Re: [Lift] MapperRules.nameToDisplayName?

[Jim Barrows]

On Mon, Mar 1, 2010 at 12:54 PM, Jeppe Nejsum Madsen wrote:

> Jim Barrows  writes:
>
> > On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen  >wrote:
> >
> >> Hi,
> >>
> >> In the interest of cutting boilerplate from mapped objects, I would
> >> like to get the display name from a property file.
> >>
> >
> > So your replacing code boilerplate with property file boilerplate?  The
> > boilerplate has to go somewhere, and abstracting things like this out
> > doesn't change that.
>
> Yes it does. Now I have to go through all my 100+ fields and add:
>
> override def displayName = S.?(getClass.getName+"."+name)
>


My point was that you've moved the boilerplate, not eliminated it.  If what
you suggest was in place you'd have to add 100+ properties in a file.



>
> Same line in every field. That counts as boilerplate for me :-)
>
> > On the other hand, if you have to l10n your app, then this works.
>
> Exactly.
>
> > What about turning it off by default, and turned on in Boot though.  Also
> it
> > should probably use the existing method by default, rolling to the
> property
> > file if it's turned on and it's not provided.
>
> That was pretty much what I suggested.except I don't want to force
> people to use displayNameFromPropertyFile. They could provide their own
> function that looked it up in a db, generated random names etc.
>


Okay, so displayNameFactory maybe?



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


-- 
James A Barrows

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

Re: [Lift] Emerging Languages Face Off: Scala, Go, Clojure and Ruby

[Jim Barrows]

Best of luck!

Will you be facing off with swords or... oh wait.. never mind... ;)

On Mon, Mar 1, 2010 at 10:50 AM, David Pollak  wrote:

> Folks,
>
> I'll be representing Scala in an emerging languages face-off at
> http://www.sdforum.org/index.cfm?fuseaction=Calendar.eventDetail&eventID=13632
>
> Interestingly, Scala and Clojure and both functional languages...
> indicating that FP is gaining interest from folks inside 2 standard
> deviations from the mean.
>
> Looking forward to seeing lots of cool folks there.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] MapperRules.nameToDisplayName?

[Jim Barrows]

On Mon, Mar 1, 2010 at 7:19 AM, Jeppe Nejsum Madsen wrote:

> Hi,
>
> In the interest of cutting boilerplate from mapped objects, I would
> like to get the display name from a property file.
>

So your replacing code boilerplate with property file boilerplate?  The
boilerplate has to go somewhere, and abstracting things like this out
doesn't change that.  On the other hand, if you have to l10n your app, then
this works.

What about turning it off by default, and turned on in Boot though.  Also it
should probably use the existing method by default, rolling to the property
file if it's turned on and it's not provided.



>
> So I was thinking that it would be an idea to add a
> MapperRules.nameToDisplayName such as this
>
> var  nameToDisplayName: ( Mapper[_], String) = (_,name) => name
>

A department of redundancy department approved name? :) *LOL*

How about displayNameFromPropertyFile?  A little wordy, but it shouldn't
ever need to be typed except to be overridden.



>
> This would allow me to do things like nameToDisplayName = (m,name) =>
> S.?(m.getClass.getName+"."+name)
>
> Thoughts?
>
> /Jeppe
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

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

Re: [Lift] scala-time and Lift pom.xml

[Jim Barrows]

On Fri, Feb 26, 2010 at 11:12 AM, Hannes  wrote:

>  I swear that I ONLY use it to compare "if things are older than other
> things". I think comparison of long values is faster than string or date
> comparison, or?
>


In what timezone?  and for what calendar?



>
> thanks.
>
>
> On Fri, Feb 26, 2010 at 10:52 AM, Hannes  wrote:
>
>> THANKS!
>>
>> You saved my weekend
>>
>
> You're welcome.
>  On the other hand using a Long as a date terrifies me, and makes me
> think your weekend, and the next three are all toast... but, maybe
> not...
>
>
>
>
>>
>>
>>  On Fri, Feb 26, 2010 at 10:43 AM, Hannes  wrote:
>>
>>> Jim,
>>>
>>> Thanks that helped!
>>>
>>> Maybe its to late, or I don't know what, but.
>>>
>>> Its a bit complicated to use I think. What's about scala-time? For my
>>> purpose, I just need the the time as a number (e.g. long). How do I do that?
>>>
>>
>> java.util.Date will give it to you.
>>
>>
>>>
>>> thanks.
>>>
>>> In what fashion do you mean integrate?
>>> Adding this:
>>>
>>> 
>>> joda-time
>>> joda-time
>>> 1.6
>>>
>>> 
>>>
>>>
>>>
>>>  to the dependency section to your maven POM will bring in the jar files.
>>>
>>> On Fri, Feb 26, 2010 at 10:14 AM, Hannes  wrote:
>>>
 Hi Peter,

 I read your mail, maybe you can help me. I'm wondering how I can
 integrate JodaTime or scala-time into my project.

 thanks.
 Hannes

> This is more a question for Jorge than anyone else but since it's Lift-
> related I thought I'd put it here:
>
> What's the easiest way to add scala-tools to my Lift project's
> pom.xml? My knowledge of Maven is very limited, but I hope that it is
> simply a matter of adding another repository and dependency.
>
> Thanks,
> Peter Robinett
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>
>

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


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



-- 
James A Barrows

-- 
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubsc

Re: [Lift] scala-time and Lift pom.xml

[Jim Barrows]

On Fri, Feb 26, 2010 at 10:52 AM, Hannes  wrote:

>  THANKS!
>
> You saved my weekend
>

You're welcome.
 On the other hand using a Long as a date terrifies me, and makes me
think your weekend, and the next three are all toast... but, maybe
not...




>
>
>  On Fri, Feb 26, 2010 at 10:43 AM, Hannes  wrote:
>
>> Jim,
>>
>> Thanks that helped!
>>
>> Maybe its to late, or I don't know what, but.
>>
>> Its a bit complicated to use I think. What's about scala-time? For my
>> purpose, I just need the the time as a number (e.g. long). How do I do that?
>>
>
> java.util.Date will give it to you.
>
>
>>
>> thanks.
>>
>> In what fashion do you mean integrate?
>> Adding this:
>>
>> 
>> joda-time
>> joda-time
>> 1.6
>>
>> 
>>
>>
>>
>>  to the dependency section to your maven POM will bring in the jar files.
>>
>> On Fri, Feb 26, 2010 at 10:14 AM, Hannes  wrote:
>>
>>> Hi Peter,
>>>
>>> I read your mail, maybe you can help me. I'm wondering how I can
>>> integrate JodaTime or scala-time into my project.
>>>
>>> thanks.
>>> Hannes
>>>
 This is more a question for Jorge than anyone else but since it's Lift-
 related I thought I'd put it here:

 What's the easiest way to add scala-tools to my Lift project's
 pom.xml? My knowledge of Maven is very limited, but I hope that it is
 simply a matter of adding another repository and dependency.

 Thanks,
 Peter Robinett

 --

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




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



-- 
James A Barrows

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

Re: [Lift] scala-time and Lift pom.xml

[Jim Barrows]

On Fri, Feb 26, 2010 at 10:43 AM, Hannes  wrote:

>  Jim,
>
> Thanks that helped!
>
> Maybe its to late, or I don't know what, but.
>
> Its a bit complicated to use I think. What's about scala-time? For my
> purpose, I just need the the time as a number (e.g. long). How do I do that?
>

java.util.Date will give it to you.


>
> thanks.
>
> In what fashion do you mean integrate?
> Adding this:
>
> 
> joda-time
> joda-time
> 1.6
>
> 
>
>
>
>  to the dependency section to your maven POM will bring in the jar files.
>
> On Fri, Feb 26, 2010 at 10:14 AM, Hannes  wrote:
>
>> Hi Peter,
>>
>> I read your mail, maybe you can help me. I'm wondering how I can integrate
>> JodaTime or scala-time into my project.
>>
>> thanks.
>> Hannes
>>
>>> This is more a question for Jorge than anyone else but since it's Lift-
>>> related I thought I'd put it here:
>>>
>>> What's the easiest way to add scala-tools to my Lift project's
>>> pom.xml? My knowledge of Maven is very limited, but I hope that it is
>>> simply a matter of adding another repository and dependency.
>>>
>>> Thanks,
>>> Peter Robinett
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=.
>>>
>>>
>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
>
> --
> James A Barrows
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] scala-time and Lift pom.xml

[Jim Barrows]

In what fashion do you mean integrate?
Adding this:


joda-time
joda-time
1.6



 to the dependency section to your maven POM will bring in the jar files.

On Fri, Feb 26, 2010 at 10:14 AM, Hannes  wrote:

> Hi Peter,
>
> I read your mail, maybe you can help me. I'm wondering how I can integrate
> JodaTime or scala-time into my project.
>
> thanks.
> Hannes
>
>> This is more a question for Jorge than anyone else but since it's Lift-
>> related I thought I'd put it here:
>>
>> What's the easiest way to add scala-tools to my Lift project's
>> pom.xml? My knowledge of Maven is very limited, but I hope that it is
>> simply a matter of adding another repository and dependency.
>>
>> Thanks,
>> Peter Robinett
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=.
>>
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

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

Re: [Lift] This is the style of SQL persistence that I like ...

[Jim Barrows]

On Wed, Feb 24, 2010 at 1:27 PM, Timothy Perrett wrote:

> Agreed - its nice. The var's are a little unsettling though... shame there
> is not a way to make it more immutable.
>

Wouldn't the new copy functionality of case classes in 2.8 take care of
that?  I've been drooling over this and the migrations project combined
since marius posted this.

Very cool stuff.


>
> Cheers, Tim
>
> On 24 Feb 2010, at 17:35, David Pollak wrote:
>
> Yeah.  It's good stuff.  Would love to see it integrated with Mapper/Record
> (so it's not looking at var fields, but looking at the more complex objects
> that represent fields).
>
> On Wed, Feb 24, 2010 at 9:33 AM, Marius  wrote:
>
>> Maybe most of you have seen it:
>>
>>
>> http://max-l.github.com/Squeryl/
>>
>>
>> Br's,
>> Marius
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] Re: Has anyone gotten the uservoice javascript to work?

[Jim Barrows]

*grumble smurf*  Ok.  I'll just use the link then, and try to get an example
up.

On Sat, Feb 20, 2010 at 12:26 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

>
>
> On Sat, Feb 20, 2010 at 10:59 AM, Jeppe Nejsum Madsen wrote:
>
>> On Sat, Feb 20, 2010 at 7:36 PM, Marius  wrote:
>> > In boot try setting LiftRules.useXhtmlMimeType = false;
>>
>> I've had the same issues and iircc it's an issue with the Uservoice
>> script not being fully xhtml compliant even if the problem is marked
>> as fixed...
>>
>> What exactly does one loose by putting useXhtmlMimeType in Boot?
>>
>
> In my experience, the layout deltas in XHTML are fewer across browsers.
>
>
>>
>> /Jeppe
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

[Lift] Has anyone gotten the uservoice javascript to work?

[Jim Barrows]

I'm trying to get the uservoice widget working correctly, but it doesn't
like working from the server, but works from a file just fine when I view
source and copy and paste to a file.  Any help would be appreciated!

Uservoice adds it's "feedback" tab via some javascript that looks like:


var uservoiceOptions = {
  /* required */
  key: 'customerelevator',
  host: 'customerelevator.uservoice.com',
  forum: '39338',
  showTab: true,
  /* optional */
  alignment: 'left',
  background_color:'#f00',
  text_color: 'white',
  hover_color: '#06C',
  lang: 'en'
};

function _loadUserVoice() {
  var s = document.createElement('script');
  s.setAttribute('type', 'text/javascript');
  s.setAttribute('src', ("https:" == document.location.protocol ?
"https://"; : "http://";) +
"cdn.uservoice.com/javascripts/widgets/tab.js");
  document.getElementsByTagName('head')[0].appendChild(s);
}
_loadSuper = window.onload;
window.onload = (typeof window.onload != 'function') ? _loadUserVoice
: function() { _loadSuper(); _loadUserVoice(); };


You add it at the end of the page, near the  tag.  I put tthe
//

If I view source, and copy/paste the code to a file, it works just fine.
When I add http://localhost:8080 to all the now broken links, it works just
fine.  It's just when I view the page from the server that it's b0rked.
-- 
James A Barrows

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

Re: [Lift] setuid

[Jim Barrows]

On Wed, Feb 17, 2010 at 10:08 AM, Tamer Rizk  wrote:

> I am using Apache as a reverse proxy forwarding traffic to Jetty on port
> 8181. I am under the impression that a slight performance benefit offered by
> Apache would be offset by the bottleneck arising from double request
> handling (resulting in a reduction of throughput in comparison to direct
> requests to Jetty).


Depends on what you serve a lot of.  If it's anything but the page (i.e.
css, js, png, img, etc etc), then you'll see better performance with Apache
in front then jetty by itself.  On the other hand, if you're serving mostly
dynamic pages, then you won't see as much of a performance boost.

However, ultimately, you're going to be better off putting Apache/Nginx in
front.  the performance concerns vs horizontal scaling options doing so are
minor.  A web server in front of the application server model allows you to
easily add application servers to the mix.  Running an application server
alone won't do that.

As with any talk of optimization, you should do it only when you have a
problem.


> Thus, I would like the option to remove Apache down the road. In either
> case I would not want Jetty running as root. At this point its just an
> experiment, so I will try out a production scenario with Jetty server in the
> hopes that the issue with missing org.mortbay.setuid.SetUIDServer is due to
> building with Maven and using the plugin. Please let me know if you have a
> reason to believe otherwise. Thanks to all.
>

I've never heard of a way to get a command line from the Java VM.  The VM
doesn't really work that way, and so gives you a layer of protection you
don't have with a native app.
http://math.hws.edu/eck/cs124/javanotes4/c9/s1.html is a nice summary of
why.  While Scala is not Java, it does run in the Java VM, using the compile
Java Byte Code.



>
> Best,
> Tamer
>
> On Wed, Feb 17, 2010 at 5:16 PM, Timothy Perrett 
> wrote:
>
>> I would recommend using Nginx or similar up front and using a reverse
>> proxy setup - it is the most optiomal solution as Nginx can handle a vast
>> number more connections than Jetty so it makes scaling your app easier on a
>> single machine.
>>
>> Cheers, Tim
>>
>> On 17 Feb 2010, at 15:11, Jeppe Nejsum Madsen wrote:
>>
>> > On Wed, Feb 17, 2010 at 4:07 PM, Jeppe Nejsum Madsen 
>> wrote:
>> >> On Wed, Feb 17, 2010 at 3:40 PM, trizk  wrote:
>> >
>> > Ok, just reread your post and saw you want to run Jetty on port 80.
>> > I've not tried this,I usually run a frontend (such as nginx) in front.
>> > Not sure how the different distros support this ootb.
>> >
>> > The point about Maven still applies though :-)
>> >
>> > /Jeppe
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Lift" group.
>> > To post to this group, send email to lift...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> > For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] TableEditor enhancements

[Jim Barrows]

On Wed, Feb 3, 2010 at 5:23 AM, Naftoli Gugenheim wrote:

> It's very different -- you edit the whole table on one screen at the same
> time, and changes are buffered until you click save.
>


We're doing that in  a very heavy data entry app.  A really nice feature is
to be able for the client to go "Oh look the backend is down again, better
hold off on sending for a bit, and let the user know so they don't lose
everything."
Our user will typically enter 20-30 courses before finding out that the app
can't save :)



> -
> Jeppe Nejsum Madsen wrote:
>
> Naftoli Gugenheim  writes:
>
> [...]
>
> > They tickets are:
> > 299 - ItemsList should be have refresh method to clear added/removed
> > without requerying database
> >   Until now it only had a reload method, which reset the state to that
> > of the database, clearing pending additions and deletions. This adds a
> > refresh method, which only reloads items but remembers pending
> > additions and deletions.
> > 300 - ItemsList.save unremoves removed unsaved items
> >   This is a defect. After a number of attempts, I made a more
> > substantial change to fix it.
> > 301 - ItemsListEditor should allow custom columns
> >   Provide a hook so user code can add additional columns, e.g.,
> calculated data.
> > 302 - ItemsListEditor should display items pending removal, albeit in
> > strikeout font
> >   Previously when you click 'Remove' the item disappears, and only
> > reappears if you reload it without saving first. This places the items
> > at the end of the list, uneditable and in a strikeout font.
> >
> > I would like to add a new enhancement as well, namely to generate
> > javascript to prompt you if you try to leave the page with unsaved
> > items.
>
> These changes sound nice. I haven't used this before. How does it differ
> from CRUDify? Seems like it covers the same functionality?
>
> /Jeppe
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

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

Re: [Lift] Handle OOM

[Jim Barrows]

On Tue, Feb 2, 2010 at 9:18 PM, David Pollak
wrote:

>
>
> On Tue, Feb 2, 2010 at 5:49 PM, Naftoli Gugenheim wrote:
>
>> Hmm... Can the code catch the exception and try to execute a script that
>> restarts it? :)
>
>
> The Sun JVM has the following flag:
>
>  -XX:OnOutOfMemoryError="script_to_execute"
>
> This will allow an auto-restart.
>
>


Oh, very cool.  I didn't know that.



>
>>
>> On Tue, Feb 2, 2010 at 8:43 PM, Jim Barrows wrote:
>>
>>> Not generally within your code no.  The VM is out of memory, not the
>>> webapp, so the VM has to be restarted.  However you could have a nagios
>>> other monitoring service auto-restart in such cases.
>>> On the other hand... you really shouldn't be getting a OOM error in
>>> Java...
>>>
>>> On Tue, Feb 2, 2010 at 5:17 PM, Naftoli Gugenheim 
>>> wrote:
>>>
>>>> Is there any way to have a webapp handle an out of memory exception
>>>> semi-gracefully? E.g., release session, restart, something other than 
>>>> having
>>>> to ssh into the server?
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Lift" group.
>>>> To post to this group, send email to lift...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> liftweb+unsubscr...@googlegroups.com
>>>> .
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/liftweb?hl=en.
>>>>
>>>>
>>>
>>>
>>> --
>>> James A Barrows
>>>
>>>  --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=en.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] Handle OOM

[Jim Barrows]

That would require memory allocation etc to do so.  Which is of course, a
problem at this point.


On Tue, Feb 2, 2010 at 6:49 PM, Naftoli Gugenheim wrote:

> Hmm... Can the code catch the exception and try to execute a script that
> restarts it? :)
>
> On Tue, Feb 2, 2010 at 8:43 PM, Jim Barrows  wrote:
>
>> Not generally within your code no.  The VM is out of memory, not the
>> webapp, so the VM has to be restarted.  However you could have a nagios
>> other monitoring service auto-restart in such cases.
>> On the other hand... you really shouldn't be getting a OOM error in
>> Java...
>>
>> On Tue, Feb 2, 2010 at 5:17 PM, Naftoli Gugenheim 
>> wrote:
>>
>>> Is there any way to have a webapp handle an out of memory exception
>>> semi-gracefully? E.g., release session, restart, something other than having
>>> to ssh into the server?
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=en.
>>>
>>>
>>
>>
>> --
>> James A Barrows
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

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

Re: [Lift] Handle OOM

[Jim Barrows]

Not generally within your code no.  The VM is out of memory, not the webapp,
so the VM has to be restarted.  However you could have a nagios other
monitoring service auto-restart in such cases.
On the other hand... you really shouldn't be getting a OOM error in
Java...

On Tue, Feb 2, 2010 at 5:17 PM, Naftoli Gugenheim wrote:

> Is there any way to have a webapp handle an out of memory exception
> semi-gracefully? E.g., release session, restart, something other than having
> to ssh into the server?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
James A Barrows

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

Re: [Lift] Tomcat tips

[Jim Barrows]

Freezing randomly is usually gc related. I'd look at memory settings.

On Jan 24, 2010 3:10 PM, "aw"  wrote:

I have been developing my Lift app using the Jetty plugin on Windows,
but now am deploying "production" on a Tomcat 6 server on Solaris.  I
don't exactly have great details at this moment, but I will admit that
I am observing some behavior differences in Tomcat that I don't see
with Jetty.  I do still have a couple of configuration tweaks to make,
but I don't think that those are the underlying culprit.  My main
symptom is that Tomcat randomly seems to "freeze".  I need to drill
into this more to isolate the problem, recreate it, and inspect the
log files, but I thought I would ask first...

Does anybody have any tips for deploying Lift apps on Tomcat?  I
assumed that I could just deploy the war and everything would work
just like on Jetty.  Alas, I realize now that the Comet implementation
is different for Jetty vs. other containers.  I am assuming, however,
that Tomcat can still do Comet reliably.  If there are any
configuration tasks that are necessary or recommended, I would
appreciate a heads up.

I am using 2.0-M1.

Thanks.

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

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

Re: [Lift] Mapper question / autogenerate some number

[Jim Barrows]

On Wed, Jan 6, 2010 at 12:15 PM, Julian Backes
wrote:

> Thanks for your answer!!
>
>
>  You can use mapper by itself.  There's a dependency on lift webkit I
>> believe.  There might be some other issues, as i don't if anyone is
>> using it that way.
>>
> This is perfectly working
>
>
>  As for the number, are you talking about a userId?  Why would you think
>> you can't set an arbitrary field in Mapper?
>>
> no, it is not a userId, just think of it as some string. Let's call it
> userSpecialString for the moment. I know that I can set some field but my
> problem is that when *storing a new user in the database*, the system
> should:
>
> 1) start transaction
> 2) generate special number/string from database
> 3) set userSpecialString to this generated thing
> 4) store new user in the database
> 5) end transaction
>

In this previous question:
http://old.nabble.com/%28Newbie-Question%29-How-to-do-simple-transaction-with-mapper--td26191398.html

I find the following:
import net.liftweb.*mapper*.{DB, DefaultConnectionIdentifier}
DB.use(DefaultConnectionIdentifier) { conn =>
  conn.setAutoCommit(false)
  ... // CRUDs
  if(success) conn.commit
  else conn.rollback
  conn.setAutoCommit(true)
}

Have you tried something like this?


> Steps 2-4 are no problem. My problem is how to do this in one transaction
> (steps 1 and 5) and where the best place is so that steps 1-5 automatically
> happen when calling newUser.save()
>
> Julian
>
>
>>
>> On Wed, Jan 6, 2010 at 11:11 AM, Julian Backes
>> mailto:julianbac...@googlemail.com>> wrote:
>>
>>Does really nobody know something about my problem? Something like
>>"this is not possible at the moment" is also ok... :-)
>>
>>Am 03.01.10 22:46, schrieb Julian Backes:
>>
>>Hi,
>>
>>I have the following problem:
>>For simplicity, assume I want to store users in the database.
>> Before
>>storing a user the first time in the database (using
>>someNewUser.save),
>>I want to create a special unique number for this user (which we
>>need in
>>our company) and store this number together with the new user. This
>>number is based on several values and some of them need to be
>>read from
>>the database.
>>My first idea was to add something to beforeCreate in the meta
>>object
>>but I'm not sure how to do the computation of the number
>>together with
>>the save operation in one transaction (which is absolutely
>>necessary)?
>>And are there better places to do this?
>>I read something about putting the whole request in one
>>transaction but
>>this is not what I want. I'm currently only using the Mapper stuff
>>(because I want a pure scala ORM) and not the whole Lift framework.
>>
>>Thanks in advance,
>>Julian
>>
>>--
>>
>>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.
>>
>>
>>
>>
>>
>>--
>>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.
>>
>>
>>
>>
>>
>>
>> --
>> James A Barrows
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>
>


-- 
James A Barrows
-- 

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com.

For more options, visit this group at http:/

Re: [Lift] Mapper question / autogenerate some number

[Jim Barrows]

You can use mapper by itself.  There's a dependency on lift webkit I
believe.  There might be some other issues, as i don't if anyone is using it
that way.
As for the number, are you talking about a userId?  Why would you think you
can't set an arbitrary field in Mapper?


On Wed, Jan 6, 2010 at 11:11 AM, Julian Backes
wrote:

> Does really nobody know something about my problem? Something like "this is
> not possible at the moment" is also ok... :-)
>
> Am 03.01.10 22:46, schrieb Julian Backes:
>
>> Hi,
>>
>> I have the following problem:
>> For simplicity, assume I want to store users in the database. Before
>> storing a user the first time in the database (using someNewUser.save),
>> I want to create a special unique number for this user (which we need in
>> our company) and store this number together with the new user. This
>> number is based on several values and some of them need to be read from
>> the database.
>> My first idea was to add something to beforeCreate in the meta object
>> but I'm not sure how to do the computation of the number together with
>> the save operation in one transaction (which is absolutely necessary)?
>> And are there better places to do this?
>> I read something about putting the whole request in one transaction but
>> this is not what I want. I'm currently only using the Mapper stuff
>> (because I want a pure scala ORM) and not the whole Lift framework.
>>
>> Thanks in advance,
>> Julian
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>
>


-- 
James A Barrows
-- 

You received this message because you are subscribed to the Google Groups "Lift" group.

To post to this group, send email to lift...@googlegroups.com.

To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Lift is awesome (with reservations)

[Jim Barrows]

Note: I just realized this was gonig to the list, and individual emails as
well.  edited the to and cc fields.

On Wed, Dec 30, 2009 at 2:22 PM, Naftoli Gugenheim wrote:

> I'm confused by your reply.
> Firstly, I think I was clear that I'm not going to do anything that you or
> David disapprove of. So if my idea is not a good one just scratch it!
> In any case I'm confused by what you said. What is "hidden" about a Google
> Docs document? Whoever wants to participate in the discussion can write in
> the document.
>

The first problem is that anyone who might wish to comment hase to know
about it.  How often people either not check, not check thoroughly enough
the existing mailing list as it is?So now you want them to read the
mailing list or the wiki to find out about a discussion happening someplace
else?  That's going to complicate matters a whole lot.

The second problem is that you won't be able to get away from the
implication that things are being done behind the communities back.   Pretty
much no matter what you do.  Again the problem is human beings.  Everybody
is not going to search, and some people are going to feel like that without
a personal invitation to "join the elite working way over here", they have
no opportunity to participate.

The spreadsheet I created is just a data tracker.  I fully expect, and
encourage the discussions to happen on the lists.  The limited number of
people who can write to it is to prevent discussions happening away from the
list, not to limit the discussion itself.  That's why it has columns to put
links to discussion on it.

And if three people, or ten, discuss it there and then run it by everyone on
> the list, those people will certainly not ignore what others on the list
> have to say.
> Was I unclear in the previous message? Or is my ignorance of Google Docs at
> play? Or did I misunderstand something?
>


There's a huge difference between people working together, coming to the
list and going what's the best way to solve 'X', or we think 'Y' would
better the 'X' because of blah blah, and people working together and coming
to the list and going "Change this!".There's an even bigger difference
when the latter are some sort of "Refactor and Reorganize Lift Committee".


Thanks.
>
> -
> Jim Barrows wrote:
>
> On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim  >wrote:
>
> > 100%.
> > But that need could be reconciled with my idea in either of two ways:
> > 1. There is discussion taking place, just in the Google Docs file as
> > opposed to the maling list. Anyone who wants can participate. The point
> is
> > that I suspect much of the reason everyone wants better naming but no one
> is
> > doing anything, is because there's a lot of overhead besides the actual
> act
> > of discussion. I think we need an approach that lets people 'just
> discuss'
> > the names in context, without any extra work like copy pasting into
> > spreadsheets etc.
> >
>
>
> So, you're trying to drive disucssion to some place hidden from the rest of
> the list (and by list I mean, users and creators of Lift).
>
>
>
> > 2. If that's not satisfactory, then we can summarize the discussion on
> the
> > list or just run the "conclusion" by everyone on the list. This way the
> > discussion itself will remain lighweight and overhead-less, but it will
> > still have to go through public scrutiny on the list before any ticket is
> > filed.
> >
>
>
> To present the users and creators of Lift with, essentially, a fait
> accompli?
>
> Leave me out of that one.
>
>
>
> > Of course if you still object we're all ears!
> > Thanks.
> >
> >
> > -
> > David Pollak wrote:
> >
> > On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim  > >wrote:
> >
> > > Does anyone object to this approach?
> > > Any source file that's being reviewed (hopefully one or very few at a
> > time)
> > > should be uploaded to Google Docs as a text document. Discussion can
> > consist
> > > of the built in google chat functionality but mainly by inserting a (((
> > ...
> > > ))) section in scaladoc comments and writing your name and thoughts
> > there.
> > > The advantage to this "poor man's code review" is that there's no
> > overhead
> > > for someone to join the effort - no arranging things in a spreadsheet
> or
> > > linking threads. I suspect that may have been an impediment until now.
> > &g

Re: [Lift] Re: Lift is awesome (with reservations)

[Jim Barrows]

On Wed, Dec 30, 2009 at 11:29 AM, Naftoli Gugenheim wrote:

> 100%.
> But that need could be reconciled with my idea in either of two ways:
> 1. There is discussion taking place, just in the Google Docs file as
> opposed to the maling list. Anyone who wants can participate. The point is
> that I suspect much of the reason everyone wants better naming but no one is
> doing anything, is because there's a lot of overhead besides the actual act
> of discussion. I think we need an approach that lets people 'just discuss'
> the names in context, without any extra work like copy pasting into
> spreadsheets etc.
>


So, you're trying to drive disucssion to some place hidden from the rest of
the list (and by list I mean, users and creators of Lift).



> 2. If that's not satisfactory, then we can summarize the discussion on the
> list or just run the "conclusion" by everyone on the list. This way the
> discussion itself will remain lighweight and overhead-less, but it will
> still have to go through public scrutiny on the list before any ticket is
> filed.
>


To present the users and creators of Lift with, essentially, a fait
accompli?

Leave me out of that one.



> Of course if you still object we're all ears!
> Thanks.
>
>
> -
> David Pollak wrote:
>
> On Tue, Dec 29, 2009 at 7:16 PM, Naftoli Gugenheim  >wrote:
>
> > Does anyone object to this approach?
> > Any source file that's being reviewed (hopefully one or very few at a
> time)
> > should be uploaded to Google Docs as a text document. Discussion can
> consist
> > of the built in google chat functionality but mainly by inserting a (((
> ...
> > ))) section in scaladoc comments and writing your name and thoughts
> there.
> > The advantage to this "poor man's code review" is that there's no
> overhead
> > for someone to join the effort - no arranging things in a spreadsheet or
> > linking threads. I suspect that may have been an impediment until now.
> > Of course nothing will be merged back from there; it's just a context for
> > discussion that may lead to tickets.
> >
>
> In general, folks shouldn't open tickets without a discussion on this list
> and at least a nod from me, Marius, Derek or Tim.  There are some
> exceptions
> to this general rule.  For example, if there's an actual defect (e.g., NPE
> de-serializing JSON data structures and you include a reproduceable case)
> or
> if you are me, Marius, Derek or Tim and you're queuing up work for
> yourself.
>
> Why?  (1) the current ticketing system does not allow for good discussion
> of
> things and the whole community is not involved (2) one person's "defect" is
> another person's feature so having a discussion to keep things oriented
> towards where Lift is going is a lot better on list and (3) some tickets
> like "write more documentation" serve no purpose because there's no person
> attached to the work and those kinds of tickets just clutter the ticketing
> system which doesn't have good filtering or prioritization tools as it is.
>
>
> >
> >
> > -
> > Erkki Lindpere wrote:
> >
> > I just noticed that GitHub also lets you comment on *commits*, but not
> > files :(
> >
> > But Google Docs or whatever you end up deciding on works for me.
> >
> > On Dec 29, 11:42 pm, Ross Mellgren  wrote:
> > > We have a code review board (reviewboard.liftweb.net), but it's pretty
> > > geared towards changes. I don't know if it can be configured or used
> > > or what-have-you for reviewing the current state of code.
> > >
> > > -Ross
> > >
> > > On Dec 29, 2009, at 4:39 PM, Erkki Lindpere wrote:
> > >
> > > > Another option would be to use a specialized code review tool, though
> > > > someone would have to host it. There's one thing that may not fit
> > > > about these, though: usually they are for reviewing *changes* and not
> > > > existing code. I don't know what the good ones are, but some
> otherwise
> > > > commercial products are free for Open Source projects (all of these
> > > > list Git support as well):
> > >
> > > > SmartBear CodeCollaborator / CodeReviewer
> > > >http://smartbear.com/codecollab.php
> > > >http://smartbear.com/codecollab-buy.php<-- about open source
> > > > licensing
> > >
> > > > Atlassian Crucible
> > > >http://www.atlassian.com/software/crucible/
> > > >
> > http://www.atlassian.com/software/crucible/licensing-faq.jsp#open-source
> > > > <-- about open source licensing
> > >
> > > > I know there are some open source ones as well, personally I've only
> > > > used Crucible once and an open source tool a long time ago (don't
> > > > remember which one).
> > >
> > > > Or how about writing a simple code review app in lift as an example
> > > > project :)
> > >
> > > > Erkki L
> > >
> > > > On Dec 29, 9:31 pm, Naftoli Gugenheim  wrote:
> > > >> Neat, thanks!
> > > >> Where to post it is a very, very good question. I would suggest not
> > > >> to invest much in a particular medium before you help us
> > > >> crystalli

Re: [Lift] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices

[Jim Barrows]

I snipped some stuff.

On Mon, Dec 14, 2009 at 12:34 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

>
>
> On Sun, Dec 13, 2009 at 10:39 PM, Heiko Seeberger <
> heiko.seeber...@googlemail.com> wrote:
>
>> 2009/12/13 Kris Nuttycombe 
>> 5) Avoid using abbreviations
>>
>
> I disagree.  When coding with a non-IDE, abbreviations make life much
> easier.
>

I agree with David, abbreviations are better.  When I'm trying to get
something out of my head and into code, I don't want things getting in my
way.  2 things in this scenario get in my way.  1) autocomplete is slow 2)
typing is slow.

Here's something else to think about on this issue.  A good typist, familiar
with their material can type faster then most code completions can operate.
In studying data entry folks at UofP, I noticed something about the
auto-complete functionality that wasn't obvious to me before.  It's not how
fast the code complete pops up that slow you down.  It's the mental shift
from typing to reading that takes the most time.  You always have to verify
that what the auto-complete is going to use is correct.  This almost always
takes more time then typing it yourself (assuming an expert typist).



>
>>
>>
>>> In general, the principle goal of this effort must be improving the
>>> clarity of the Lift API for both new adopters and for maintainers.
>>
>>
>> 100% agreed!
>>
>> In order to make Lift even more popular it is essential to ease adoption.
>> Often folks require better documentation and we all know that the code (the
>> API) is the first and best source of documentation.
>>
>> Heiko
>>
>> My job: weiglewilczek.com
>> My blog: heikoseeberger.name
>> Follow me: twitter.com/hseeberger
>> OSGi on Scala: scalamodules.org
>> Lift, the simply functional web framework: liftweb.net
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
>
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

--

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

[Lift] How to handle a redirect to your site with info for a user that still has to sign up/login?

[Jim Barrows]

I'm working on a plugin for a website.  Essentially a user of the external
website (we'll call it Shopify), can click on a link to add my service to
their webstore.  So Shopify uses a URL like:
http://localhost:8080/shopify/addStore?timestamp=1260635800&shop=kemmer-hahn-and-kunde1221.myshopify.com&signature=e68e54623fd662db8262ccae5a4255c9&t=d1c685b222bada796438214e79516fc1
This provides me with everything I need to get access to the Shopify (and
now, my) customer.  However, they have not yet registered with my site yet.
So I have code that handles the case where they are already logged in, and
where they just need to login.  When I try to register them, the code
doesn't work.  The User.loginRedirect seems to get lost somewhere.  This
tells me that I don't understand something.  Like is there an easier way?
:)  And more importantly what am I missing?

Here's the Boot:
 LiftRules.dispatch.append {
  case Req("shopify" :: "install" :: "addStore" :: Nil, _,_ ) =>
ShopifyUI.addStore _
}

And then this is the addStore implementation:
object ShopifyUI {
  def addStore(): Box[net.liftweb.http.LiftResponse] = {

object shopInfoVar extends SessionVar[Box[ShopInfo]](Empty)

var shopInfo: ShopInfo = ShopInfo.createInstance

param("timestamp") match {
  case Full(x) => shopInfo.timestamp.set(new Date(x.toLong))
  case _ => error("timestamp", "Shopify did not send a timestamp.")
}

param("shop") match {
  case Full(x) => shopInfo.shopName.set(List.fromString(x, '.').first)
  case _ => error("shop", "Shopify did not send a shop url.")
}

param("signature") match {
  case Full(x) => shopInfo.signature.set(x)
  case _ => error("signature", "Shopify did not send a signature.")
}

param("t") match {
  case Full(x) => {
shopInfo.authenticationToken.set(x)
shopInfo.shopPassword.set(ShopifyService.createPasswordForStore(x))
  }
  case _ => error("t", "Shopify did not send an authentication token
(the 't' param)")
}
if( ! errors.isEmpty && !shopInfoVar.is.isEmpty) {
  clearCurrentNotices
  shopInfo = shopInfoVar.is.open_!
}
if (User.loggedIn_?) {
  shopInfo.owner.set(User.currentUser.open_!.id)
  shopInfo.save
} else {
  shopInfoVar(Full(shopInfo))
  User.loginRedirect(Full("/shopify/install/addStore"))
}
Full(RedirectResponse("/shopinfo/list"))
  }


}


-- 
James A Barrows

--

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

[Lift] The thread for discussing names that need to change.

[Jim Barrows]

And we can start with Kris's list!  Which hopefully will start things off
nicely.
If any particular discussion starts getting long, I, or the discussers
should move it to it's own thread.

module: lift-util
file: src/main/scala/net/liftweb/util/JsonCmd.scala
ResponseInfoHolder => ResponseMetadata

module: lift-webkit
file: src/main/scala/net/liftweb/http/S.scala
RewriteHolder => NamedRewrite
DispatchHolder => NamedDispatch
CookieHolder => Cookies
(\w+)HighLevelSessionDispatcher => \1SessionDispatcher (No LowLevel???)
? => % or $ (printf, jsp - what's the inspiration for ? as
localization/formatting?)
(\w+)_? => is\1 (underscore is used for enough things in Scala, let's not
make method names harder to read)
getHeader => getResponseHeader
getDocType => docType (change return type from tuple to case class with
sematically significant names?)
setDocType => docType_=
addCleanupFunc => onCleanup
functionLifespan_= parameter type Boolean => Lifespan (sealed trait
Lifespan; case object Session extends Lifespan; case object Request extends
Lifespan)
functionLifespan_? => functionLifespan
attrs => snippetAttrs; return type should be something more informative than
List[(Either[String, (String, String)], String)]
prefixedAttrsToMap => snippetAttrMap
prefixedAttrsToMetadata => snippetAttrMetadata
mapToAttrs: Move to one of the util classes? No state dependencies in this
one...

getSessionAttribute(s: String) => containerSessionAttribute (to avoid
confusion with LiftSession) where containerSessionAttribute is a local
object as defined below
setSessionAttribute(s: String, v: String) => containerSessionAttribute(s:
String) = v; see below
object containerSessionAttribute {
  def apply(name: String) = containerSession.flatMap(_.attribute(name) match
{case s: String => Full(s) case _ => Empty})
  def update(name: String, value: String) =
containerSession.foreach(_.setAttribute(name, value))
  def unset(name: String) =
containerSession.foreach(_.removeAttribute(name))
}

fmapFunc => something else this is confusing for those familiar with fmap
from Haskell
clearCurrentNotices =>
Disambiguate S.loc / Loc; maybe use S.l instead (taking inspiration from
rails's h)
Disambiguate getNotices/getAllNotices/notices. Since there's a Notice type
of notice, maybe getNotices => messages ?
the current methods messages/noIdMessages/idMessages are all pure functions
that don't interact with state, maybe move them elsewhere?

NoticeType, maybe make a sealed trait w/case objects instead of Enumeration?

Why does S._statefulSnip not override nameSalt?

Needs better documentation, potential renames, or both:

currentAttrs*
locateMappedSnippet
booster (private, unused, candidate for removal?)
formFuncName
formGroup
*FuncHolder - these are widely used, but neither the names, types, or
documentation tell the novice what they're for

General suggestions:
Disambiguate/eliminate generic names: Field, Param,

-- 
James A Barrows

--

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

Re: [Lift] Open discussion on Lift Name Calling practices

[Jim Barrows]

Dates have changed below.  I slipped everything a week.

On Wed, Dec 9, 2009 at 11:59 PM, Kris Nuttycombe
wrote:

> On Tue, Dec 1, 2009 at 1:43 PM, Jim Barrows  wrote:
> > Lift is getting very large.  We've got singular names as lists, and
> plural
> > names that aren't lists.  We've got people calling roses red flowers,
> spades
> > diamonds and other mass chaos.  Well, it's not that bad, but you get the
> > idea.  This is an attempt to come up with a series of standard names to
> make
> > working in lift easier, not only for the committers, but also (and more
> > importantly) for you folks using it on a day to day basis.
> >
> > Achieving this means that there must be two things, a set of rules for
> > naming conventions, and a process to make sure everyone is following
> those
> > rules, and changing things when we mess it up.
> >
> > This thread is for discussing the process.  I'll be starting another
> thread
> > to discuss the rules, as well as another thread to discuss current names
> > that we want to change.
> > As always, if you don't speak up, you're not dissenting, and we welcome
> your
> > views and ideas on how to do this!
> >
> > 1) Goal discussion (closes 15 Dec 09)
> > 2) Identify changes, and put the list on the wiki (closes 22 Jan 10)
> > 3) Convert the list to github tickets.  This includes discussing setting
> > priorities etc, assessing impacts etc etc to go into the ticket. (closes
> 5
> > Jan 10)
> > 4) Committers can then work the tickets into their own workflows, and
> > everything would then follow the normal commit workflow from there.
> > (committers work according to priority and impact etc)
> > 5) Naming becomes a part of the normal review board process.  However, if
> a
> > committer thinks that the Name Caller needs to look at it earlier, or is
> > having a hard time with naming something, by all means send an email.  (
> > date we add this to the process 5 Feb 10)
> > 6) As we find things we missed, or better names, we work them through the
> > github ticket and review system. ( date we add this to the process 5 Feb
> > 10)
> >
> > --
> > James A Barrows
>
> The timeline looks good to me, with the exception of the fact that
> we've already passed the first milestone!
>

> With respect to goals, I have a few general suggestions.
>
> 1) Remove ambiguity wherever possible! There are a number of places
> where very similar names are used to refer to utterly different
> things.
> 2) As an aide removing ambiguity, consider outlawing or eliminating
> extremely generic names, or else establish a single way in which a
> given name will be used across Lift. Examples are Field, Info, Holder,
> etc.
> 3) Avoid making the name of the return type part of the name of the
> method. The types should tell the story as much as possible, except in
> the case where multiple methods varying only in return type would
> exist (illegal overloads)
> 4) Prefer Scala-style accessors and mutators.
>
> I also am attaching a start at some names I see as suboptimal from
> S.scala, but since this thread isn't really for discussion of
> individual naming issues (and such a thread doesn't yet exist) I
> thought I'd go ahead and present my suggestions as a strawman for
> format and what type of changes might be considered.
>
> Kris
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>


-- 
James A Barrows

--

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

Re: [Lift] Re: Having trouble figuring out how to get a form to submit without submitting the page, using ajaxForm

[Jim Barrows]

On Sat, Dec 5, 2009 at 12:43 PM, Marius  wrote:

> Jon is correct. There is another approach though  that was recently
> introduced: using SHtml.submitAjaxForm(formId) ... this is useful if
> you want to submit an ajax form from outside of it say when clicking a
> link etc. But probably the most common way is to use what Jon
> described.
>


Yep, Jon's suggestion worked!!



>
> Br's,
> Marius
>
> On Dec 5, 7:58 pm, Jonathan Hoffman  wrote:
> > Hi,
> >
> > This is a tricky bit.  It turns out that the javascript that's used to
> serialize (jQuery.serialize) the form does not include the submit button.
>  The best way to get the functionality you want is to add a hidden field:
> >
> > SHtml.ajaxForm(bind(...) ++ SHtml.hidden(saveContactMechanismToParty))
> >
> > If saveContactMechanismToParty returns a JsCmd that code will get
> executed on the client.
> >
> > - Jon
> >
> > On Dec 5, 2009, at 10:55 AM, Jim Barrows wrote:
> >
> > > This is the basic definition of the form that works, but submits the
> page:
> > > xhtml:
> > > 
> > > 
> > >  
> > >  
> >
> > > And the binding looks like:
> > > bind("contactMechanism", xhtml,
> > >   "comment" -> text(comment, comment = _),
> > >   "fromDate" -> text(fromDate, fromDate = _) % ("id" -> "fromDate")
> % ("maxlength" -> "15") % ("size" -> "15"),
> > >   "thruDate" -> text(thruDate, thruDate = _) % ("id" -> "thruDate")
> % ("maxlength" -> "15") % ("size" -> "15"),
> > >   "submit" -> submit("Add", saveContactMechanismToParty ))
> >
> > > So, after reading the ajaxForm methods description I thought I could do
> this:
> > > xhtml:
> > > 
> > > 
> > >  
> > >  
> >
> > > And the binding would look like:
> > > ajaxForm(  bind("contactMechanism", xhtml,
> > >   "comment" -> text(comment, comment = _),
> > >   "fromDate" -> text(fromDate, fromDate = _) % ("id" -> "fromDate")
> % ("maxlength" -> "15") % ("size" -> "15"),
> > >   "thruDate" -> text(thruDate, thruDate = _) % ("id" -> "thruDate")
> % ("maxlength" -> "15") % ("size" -> "15"),
> > >   //"mechanism" -> text(dateFormat.format(new Date()), thruDate =
> _) % ("id" -> "thruDate") % ("maxlength" -> "10") % ("size" -> "10"),
> > >   "submit" -> submit("Add", saveContactMechanismToParty )))
> >
> > > However, when the submit button is clicked the
> saveContactMechanismToParty never gets called.
> > > What am I missing?
> >
> > > --
> > > James A Barrows
> >
> > > --
> >
> > > You received this message because you are subscribed to the Google
> Groups "Lift" group.
> > > To post to this group, send email to lift...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> > > For more options, visit this group athttp://
> groups.google.com/group/liftweb?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>


-- 
James A Barrows

--

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

[Lift] Having trouble figuring out how to get a form to submit without submitting the page, using ajaxForm

[Jim Barrows]

This is the basic definition of the form that works, but submits the page:
xhtml:


 
 

And the binding looks like:
bind("contactMechanism", xhtml,
  "comment" -> text(comment, comment = _),
  "fromDate" -> text(fromDate, fromDate = _) % ("id" -> "fromDate") %
("maxlength" -> "15") % ("size" -> "15"),
  "thruDate" -> text(thruDate, thruDate = _) % ("id" -> "thruDate") %
("maxlength" -> "15") % ("size" -> "15"),
  "submit" -> submit("Add", saveContactMechanismToParty ))

So, after reading the ajaxForm methods description I thought I could do
this:
xhtml:


 
 

And the binding would look like:
ajaxForm(  bind("contactMechanism", xhtml,
  "comment" -> text(comment, comment = _),
  "fromDate" -> text(fromDate, fromDate = _) % ("id" -> "fromDate") %
("maxlength" -> "15") % ("size" -> "15"),
  "thruDate" -> text(thruDate, thruDate = _) % ("id" -> "thruDate") %
("maxlength" -> "15") % ("size" -> "15"),
  //"mechanism" -> text(dateFormat.format(new Date()), thruDate = _) %
("id" -> "thruDate") % ("maxlength" -> "10") % ("size" -> "10"),
  "submit" -> submit("Add", saveContactMechanismToParty )))

However, when the submit button is clicked the saveContactMechanismToParty
never gets called.
What am I missing?

-- 
James A Barrows

--

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

[Lift] Open discussion on Lift Name Calling practices

[Jim Barrows]

Lift is getting very large.  We've got singular names as lists, and plural
names that aren't lists.  We've got people calling roses red flowers, spades
diamonds and other mass chaos.  Well, it's not that bad, but you get the
idea.  This is an attempt to come up with a series of standard names to make
working in lift easier, not only for the committers, but also (and more
importantly) for you folks using it on a day to day basis.

Achieving this means that there must be two things, a set of rules for
naming conventions, and a process to make sure everyone is following those
rules, and changing things when we mess it up.

This thread is for discussing the process.  I'll be starting another thread
to discuss the rules, as well as another thread to discuss current names
that we want to change.
As always, if you don't speak up, you're not dissenting, and we welcome your
views and ideas on how to do this!

1) Goal discussion (closes 8 Dec 09)
2) Identify changes, and put the list on the wiki (closes 15 Jan 10)
3) Convert the list to github tickets.  This includes discussing setting
priorities etc, assessing impacts etc etc to go into the ticket. (closes 29
Jan 10)
4) Committers can then work the tickets into their own workflows, and
everything would then follow the normal commit workflow from there.
(committers work according to priority and impact etc)
5) Naming becomes a part of the normal review board process.  However, if a
committer thinks that the Name Caller needs to look at it earlier, or is
having a hard time with naming something, by all means send an email.  (
date we add this to the process 29 Jan 10)
6) As we find things we missed, or better names, we work them through the
github ticket and review system. ( date we add this to the process 29 Jan
10)

-- 
James A Barrows

--

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

Re: [Lift] Re: how does lift work with redis?

[Jim Barrows]

2009/11/26 surfman 

> So, if I want to use nosql database with LIFT, what I have to use is
> JDBC driver, am I right?
> Any experienced suggestion? Google has very little searching result on
> it.
> I'd appreciate any idea on this topic. Thanks.
>

No, you can use whatever Java driver the nosql database comes with.  If the
nosql database has a JDBC driver, then  you might find it easier to use one
of the Java ORM systems that support it.  However, JDBC is pretty much a SQL
thing, so that might be difficult.

Using a nosql database means that you don't have access to some of the built
in features that Mapper and Record give you for data mapping, and form
generation, but you should still be able to use Lift quite easily.



>
> Regards,
>
> Surfman
>
> On 11月25日, 下午4时06分, Timothy Perrett  wrote:
> > Correct - Redis is a nosql database, mapper is only for RDBMS
> >
> > Cheers, Tim
> >
> > On 25 Nov 2009, at 20:13, surfman wrote:
> >
> >
> >
> > > Thanks. Does it mean I may not use lift mapper and I have to write
> > > everything for database manipulation?
> >
> > > regards,
> >
> > > surfman
> >
> > > On 11月24日, 下午5时12分, Timothy Perrett  wrote:
> > >> There is no out of the box implementation. You could write a record
> > >> back end though - it depends on the features you want I guess.
> >
> > >> Cheers, Tim
> >
> > >> Sent from my iPhone
> >
> > >> On 24 Nov 2009, at 22:00, surfman  wrote:
> >
> > >>> Is there anything I could learn on how lift works with redis
> database?
> > >>> Thanks.
> >
> > >>> --
> >
> > >>> You received this message because you are subscribed to the Google
> > >>> Groups "Lift" group.
> > >>> To post to this group, send email to lift...@googlegroups.com.
> > >>> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> > >>> .
> > >>> For more options, visit this group athttp://
> groups.google.com/group/liftweb?hl=en
> > >>> .- 隐藏被引用文字 -
> >
> > >> - 显示引用的文字 -
> >
> > > --
> >
> > > You received this message because you are subscribed to the Google
> Groups "Lift" group.
> > > To post to this group, send email to lift...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> > > For more options, visit this group athttp://
> groups.google.com/group/liftweb?hl=en.- 隐藏被引用文字 -
> >
> > - 显示引用的文字 -
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>


-- 
James A Barrows

--

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

Re: [Lift] Looking for an example of how to do master detail, on the view side

[Jim Barrows]

I'd love to see it incorporated as well.

On Thu, Nov 26, 2009 at 8:57 AM, Timothy Perrett wrote:

> Agreed - Kirs' idea is a nice one. It would be good to incorporate such a
> pattern in the lift examples.
>
> Cheers, Tim
>
> On 26 Nov 2009, at 15:42, Jim Barrows wrote:
>
> > Excellent.  He's already where I was headed :)
> >
> > On Wed, Nov 25, 2009 at 8:51 PM, David Pollak <
> feeder.of.the.be...@gmail.com> wrote:
> > Kris blogged about a really nice pattern: http://logji.blogspot.com/
> >
> > On Wed, Nov 25, 2009 at 3:16 PM, Jim Barrows 
> wrote:
> > I'm using JPA, and need to do a One->Many, or master detail view.  So I
> tried the obvious:
> > 
> > 
> >  
> > 
> > 
> >
> > However, the HTML that gets generated is the same form for both.
> > Is there an example somewhere I've missed about how to do this?
> > --
> > James A Barrows
> >
> >
> > --
> >
> > You received this message because you are subscribed to the Google Groups
> "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
> >
> >
> >
> > --
> > Lift, the simply functional web framework http://liftweb.net
> > Beginning Scala http://www.apress.com/book/view/1430219890
> > Follow me: http://twitter.com/dpp
> > Surf the harmonics
> >
> >
> > --
> >
> > You received this message because you are subscribed to the Google Groups
> "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
> >
> >
> >
> > --
> > James A Barrows
> >
> >
> > --
> >
> > You received this message because you are subscribed to the Google Groups
> "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>


-- 
James A Barrows

--

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

Re: [Lift] Looking for an example of how to do master detail, on the view side

[Jim Barrows]

Excellent.  He's already where I was headed :)

On Wed, Nov 25, 2009 at 8:51 PM, David Pollak  wrote:

> Kris blogged about a really nice pattern: http://logji.blogspot.com/
>
> On Wed, Nov 25, 2009 at 3:16 PM, Jim Barrows wrote:
>
>> I'm using JPA, and need to do a One->Many, or master detail view.  So I
>> tried the obvious:
>> 
>> 
>>  
>> 
>> 
>>
>> However, the HTML that gets generated is the same form for both.
>> Is there an example somewhere I've missed about how to do this?
>> --
>> James A Barrows
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

--

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

Re: [Lift] Looking for an example of how to do master detail, on the view side

[Jim Barrows]

ARGGG

It's contactMechanism:comment not contactMechanism.comment

It's colons not dots in xhtml
It's colons not dots in xhtml
It's colons not dots in xhtml
It's colons not dots in xhtml
It's colons not dots in xhtml
it's colons not dots in xhtml
It's colons not dots in xhtml
It's colons not dots in xhtml


On Wed, Nov 25, 2009 at 5:03 PM, Jim Barrows  wrote:

> Here's the complete xhtml file:
> 
> 
> 
> Edit Person
> 
> 
> You are editing: 
>
> 
> 
> 
> 
>
> 
> First Name
> 
> 
> 
> 
> 
> 
>
> 
> Middle Name
> 
> 
> 
> 
> 
> 
>
> 
> Last Name
> 
> 
> 
> 
> 
> 
> 
>
> 
> Contact Mechanisms
>
> 
> 
> Comment
> 
>  value="Email"/>Email
> Postal Address
> Phone Number
>  value="Facebook"/>Facebook
>  value="Twitter"/>Twitter
> 
> Save
> 
> 
> 
> Comment
> From
> Thru
> Mechanism
> 
> 
> 
> 
>
> 
>
> 
>
>
> On Wed, Nov 25, 2009 at 4:35 PM, Derek Chen-Becker 
> wrote:
>
>> That markup should be in a template file somewhere, which would then call
>> the snippets appropriately. I don't see markup for a second form, but I
>> might just be missing it.
>>
>> A couple of other notes:
>>
>>
>>- Generally, on links, omit the suffix and Lift will then do I18N
>>lookup for you as needed. That means use "/contact/person/edit" instead of
>>"/contact/person/edit.html"
>>- When you're deleting in JPA, there's no need to do a merge first.
>>Just obtain a reference instead and delete that. It's more efficient. Your
>>code would look like:
>>
>>   def doDelete() = {
>> try {
>>   Model.removeAndFlush(Model.getReference(classOf[Person],
>> person.getId());
>>
>>   notice("Deleted " + person.getFirstName() + " " +
>> person.getLastName())
>>   redirectTo("/contact/list")
>>
>> } catch {
>>   case pe: PersistenceException => error("Error removing person");
>> Log.error("Error removing person", pe);
>> }
>>   }
>>
>>
>> On Wed, Nov 25, 2009 at 4:26 PM, Timothy Perrett > > wrote:
>>
>>> Lift does not use markup like that - there is no magic mapping between
>>> persistence and view.
>>>
>>> You would most likly have to construct the appropriate master -> detail
>>> code in your snippets and work like that.
>>>
>>> Cheers, Tim
>>>
>>> On 25 Nov 2009, at 23:16, Jim Barrows wrote:
>>>
>>> > I'm using JPA, and need to do a One->Many, or master detail view.  So I
>>> tried the obvious:
>>> > 
>>> > 
>>> >  
>>> > 
>>> > 
>>> >
>>> > However, the HTML that gets generated is the same form for both.
>>> > Is there an example somewhere I've missed about how to do this?
>>> > --
>>> > James A Barrows
>>> >
>>> >
>>> > --
>>> >
>>> > You received this message because you are subscribed to the Google
>>> Groups "Lift" group.
>>> > To post to this group, send email to lift...@googlegroups.com.
>>> > To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com
>>> .
>>> > For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=en.
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=en.
>>>
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>
>
>
> --
> James A Barrows
>
>


-- 
James A Barrows

--

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

Re: [Lift] Looking for an example of how to do master detail, on the view side

[Jim Barrows]

Here's the complete xhtml file:



Edit Person


You are editing: 





First Name







Middle Name







Last Name









Contact Mechanisms


Comment

Email
Postal Address
Phone Number
Facebook
Twitter

Save



Comment
From
Thru
Mechanism









On Wed, Nov 25, 2009 at 4:35 PM, Derek Chen-Becker wrote:

> That markup should be in a template file somewhere, which would then call
> the snippets appropriately. I don't see markup for a second form, but I
> might just be missing it.
>
> A couple of other notes:
>
>
>- Generally, on links, omit the suffix and Lift will then do I18N
>lookup for you as needed. That means use "/contact/person/edit" instead of
>"/contact/person/edit.html"
>- When you're deleting in JPA, there's no need to do a merge first.
>Just obtain a reference instead and delete that. It's more efficient. Your
>code would look like:
>
>   def doDelete() = {
> try {
>   Model.removeAndFlush(Model.getReference(classOf[Person],
> person.getId());
>
>   notice("Deleted " + person.getFirstName() + " " +
> person.getLastName())
>   redirectTo("/contact/list")
>
> } catch {
>   case pe: PersistenceException => error("Error removing person");
> Log.error("Error removing person", pe);
> }
>   }
>
>
> On Wed, Nov 25, 2009 at 4:26 PM, Timothy Perrett 
> wrote:
>
>> Lift does not use markup like that - there is no magic mapping between
>> persistence and view.
>>
>> You would most likly have to construct the appropriate master -> detail
>> code in your snippets and work like that.
>>
>> Cheers, Tim
>>
>> On 25 Nov 2009, at 23:16, Jim Barrows wrote:
>>
>> > I'm using JPA, and need to do a One->Many, or master detail view.  So I
>> tried the obvious:
>> > 
>> > 
>> >  
>> > 
>> > 
>> >
>> > However, the HTML that gets generated is the same form for both.
>> > Is there an example somewhere I've missed about how to do this?
>> > --
>> > James A Barrows
>> >
>> >
>> > --
>> >
>> > You received this message because you are subscribed to the Google
>> Groups "Lift" group.
>> > To post to this group, send email to lift...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> > For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>> --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=en.
>>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>



-- 
James A Barrows

--

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

Re: [Lift] Looking for an example of how to do master detail, on the view side

[Jim Barrows]

On Wed, Nov 25, 2009 at 4:26 PM, Timothy Perrett wrote:

> Lift does not use markup like that - there is no magic mapping between
> persistence and view.
>
> You would most likly have to construct the appropriate master -> detail
> code in your snippets and work like that.
>


That's what I was trying to do.  There's a list of contact mechanisms
attached to each person.  I was going to use the second form to add the
contact mechanism to the person.



>
> Cheers, Tim
>
> On 25 Nov 2009, at 23:16, Jim Barrows wrote:
>
> > I'm using JPA, and need to do a One->Many, or master detail view.  So I
> tried the obvious:
> > 
> > 
> >  
> > 
> > 
> >
> > However, the HTML that gets generated is the same form for both.
> > Is there an example somewhere I've missed about how to do this?
> > --
> > James A Barrows
> >
> >
> > --
> >
> > You received this message because you are subscribed to the Google Groups
> "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>


-- 
James A Barrows

--

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

Re: [Lift] Looking for an example of how to do master detail, on the view side

[Jim Barrows]

package com.nsfw.snippet

import _root_.net.liftweb._
import common.{Empty, Full, Box}
import sitemap.{Loc}
import http._
import js.{JsCmd, JsCmds}
 import JsCmds._
import S._
import SHtml._
import util._
import Helpers._

import _root_.javax.persistence.{EntityExistsException,
PersistenceException}

import com.nsfw.model.Model
import xml.{Group, NodeSeq, Text}
import com.nsfw.bmp.partymodel.party.{PartyContactMechanism, Person}

class PersonSnippets {

  object personVar extends RequestVar(new Person())
  def person = personVar.is

  object partyContactMechanismVar extends RequestVar( new
PartyContactMechanism())
  def partyContactMechanism = partyContactMechanismVar.is

  def addContactMechanism (html: Group) : NodeSeq = {
var comment : String = ""
bind("contactMechanism", html,
  "comment" -> Text(partyContactMechanism.getComment()))
  }

  def list(xhtml: NodeSeq): NodeSeq = {

val people =
Model.createNamedQuery[Person]("findAllPeople").getResultList()

people.flatMap(person =>
bind("person", xhtml,
  "firstName" -> Text(person.getFirstName()),
  "middleName" -> Text(person.getMiddleName()),
  "lastName" -> Text(person.getLastName()),
  "edit" -> SHtml.link("/contact/person/edit.html", () =>
personVar(person), Text(?("Edit"))),
  "delete" -> SHtml.link("/contact/person/delete.html", () =>
personVar(person), Text(?("Delete")))
  ))
  }

  def form = {



  

  First Name

  
  
  
  
  

  Middle Name

  
  
  
  
  

  Last Name

  
  
  
  
  
  
  

  }

  def save(xhtml: NodeSeq): NodeSeq = {

bindPerson(xhtml, doSave, "Save", false)
  }

  def delete(xhtml: NodeSeq): NodeSeq = {

bindPerson(xhtml, doDelete, "Delete", true)

  }

  def doSave() = {

try {
  val name = person.getFirstName() + " " + person.getLastName()
  Model.mergeAndFlush(person)
  notice("Saved " + name)
  redirectTo("/contact/list.html")
} catch {
  case ee: EntityExistsException => error("Person already exists")
  case pe: PersistenceException => error("Error adding person");
Log.error("Error adding person", pe)
}

  }

  def doDelete() = {
try {
  var mergedPerson = Model.mergeAndFlush(person);
  val name = mergedPerson.getFirstName() + " " +
mergedPerson.getLastName()
  Model.removeAndFlush(mergedPerson);

  notice("Deleted " + name)
  redirectTo("/contact/list.html")
} catch {
  case pe: PersistenceException => error("Error removing person");
Log.error("Error removing person", pe);
}
  }


  def bindPerson(xhtml: NodeSeq, action: () => Unit, submitButtonName:
String, disableAll: boolean): NodeSeq = {
// Hold a val here so that the "id" closure holds it when we re-enter
this method
val currentId = person.getId()
val currentVersion = person.getVersion()

val disableAttr: Box[String] = if (disableAll) Full("disabled") else
Empty

bind("person", xhtml,
  "id" -> SHtml.hidden(() => person.setId(currentId)),
  "version" -> SHtml.hidden(() => person.setVersion(currentVersion)),
  "firstName" -> (SHtml.text(person.getFirstName(),
person.setFirstName(_)) % ("id" -> "firstName") % ("readonly" ->
disableAttr)),
  "middleName" -> (SHtml.text(person.getMiddleName(),
person.setMiddleName(_)) % ("id" -> "middleName") % ("readonly" ->
disableAttr)),
  "lastName" -> (SHtml.text(person.getLastName(), person.setLastName(_))
% ("id" -> "lastName") % ("readonly" -> disableAttr)),
  "submit" -> SHtml.submit(?(submitButtonName), action))
  }

}

On Wed, Nov 25, 2009 at 4:21 PM, Derek Chen-Becker wrote:

> I don't think that that should be happening, but I would need to see the
> code for PersonSnippets to really see what's going on.
>
> Derek
>
> On Wed, Nov 25, 2009 at 4:16 PM, Jim Barrows wrote:
>
>> I'm using JPA, and need to do a One->Many, or master detail view.  So I
>> tried the obvious:
>> 
>> 
>>  
>> 
>> 
>>
>> However, the HTML that gets generated is the same form for both.
>> Is there an example somewhere I've missed about how to do this?
>> --
>> James A Barrows
>>
>>  --
>> Y

[Lift] Looking for an example of how to do master detail, on the view side

[Jim Barrows]

I'm using JPA, and need to do a One->Many, or master detail view.  So I
tried the obvious:


 



However, the HTML that gets generated is the same form for both.
Is there an example somewhere I've missed about how to do this?
-- 
James A Barrows

--

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

Re: [Lift] Working with legacy databases

[Jim Barrows]

On Sat, Nov 21, 2009 at 8:16 PM, Donald McLean  wrote:

> We are considering porting an existing Java desktop app to a
> Scala/lift web app. The application works with a Sybase DB. I'm still
> pretty new to Scala and Lift so I'm probably overlooking something
> obvious but could someone recommend a technology that is know to work
> for this environment? I have used Hibernate in the past and will use
> it again if necessary but I would be interested to know if there are
> other options.
>

You have Record and Mapper, which are a part of lift.  You have Scala QL.
Since Lift is written in Scala you have a plethora of Java based ORM's and
DB acccess libraries as well.

It's your choice, really.


>
> Thank you,
>
> Donald
>
> --
> Family photographs are a critical legacy for
> ourselves and our descendants. Protect that
> legacy with a digital backup and recovery plan.
>
> Join the photo preservation advocacy Facebook group:
> http://www.facebook.com/home.php?ref=logo#/group.php?gid=148274709288
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>


-- 
James A Barrows

--

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

Re: [Lift] Issue 201 - checkbox not returning all checked

[Jim Barrows]

On Sat, Nov 21, 2009 at 10:48 AM, Ross Mellgren  wrote:

> yejun on github opened up an issue:
>
> def checkbox[T](possible : Seq[T], actual : Seq[T], func : (Seq[T]) => Any,
> attrs : (String, String)*)
>
>
Checkbox is returning a list of checkboxes?  Could we at least make checkbox
return and either checkboxList or checkboxes for many?


>
> Func will only return first element in possible when it is checked or
> List().
>
>
> It is easily reproducible.
>
> Based on the type of func, I agree it looks like it should give all checked
> boxes, not just either the first checked box or an empty list. If it's
> supposed to be for a single checkbox only, then I think the type should be
> changed to Box[T] => Any, or at the very least a doc comment indicating that
> it only supports a single check box.
>
> This behavior was introduced 
> with
> http://github.com/dpp/liftweb/commit/8b2a92a58ded608a0d3a7b6ead29cd2af6302c5e
> .
>
> Since there is no doc comment on the function I wanted to check what is the
> intended behavior before making and posting a patch to either do multiple
> checkbox or make the doc comment / type more clear and add another function
> to do the multi behavior.
>
> Thoughts?
> -Ross
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>



-- 
James A Barrows

--

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

Re: [Lift] Another List "XYZ" Menu Entry

[Jim Barrows]

On Fri, Nov 20, 2009 at 8:18 AM, Hannes  wrote:

>  I read some stuff of chapter five before, but this was the extra hint,
> that I needed...
>

A lot of Scala and, by extension, Lift requires some deep contemplation of
what it means.  a path implemented as a List makes little sense... until
you play with Scala's list a lot... then it's a beautiful thing


>
>
> thanks!
>
>
>
> On Fri, Nov 20, 2009 at 7:07 AM, Hannes  wrote:
>
>> Maybe you could give a one liner, showing how to write the menu item in
>> Boot.scala.
>>
>
> A menu entry looks something like:
> Menu( Loc("helpHome", ("help" :: "" ::Nil) -> true, "Help"))
>
> The list ( "help" :: "" :: Nil) is the path to the the page.   In this case
> the -> True says that everything underneath help is ok.
>
> So you could do "path" :: "to" :: "my" :: "page" :: Nil and -> false
>
> There's a great description in section 5 of the Exploring lift PDF if you
> need more help.
>
>
>> thanks.
>>
>>  On Fri, Nov 20, 2009 at 6:26 AM, Hannes  wrote:
>>
>>> I meant, that I had general problems to find a way how to do it, not
>>> talking about the "Lift" way to do it.
>>>
>>> So I think I need a new XHTML page where I call a snippet method, that
>>> displays the table. Then, from the menu item, I just link to that new page?
>>> Would that be the right way?
>>>
>>
>> I'm not sure what you're asking.  You could do it with an xhtml page, you
>> could also build the table in code, like the CRUDify stuff does.  Either way
>> works, if I understand you correctly.
>>
>>
>>
>>>
>>> thanks.
>>>
>>>
>>>
>>> On Mon, Nov 16, 2009 at 8:51 AM, Hannes  wrote:
>>>

 Hi Lifters,

 I need a new menu entry that displays a table similar to the one, that
 is shown by the CRUDify List "XYZ" link. But I need to display different
 fields without the chance to edit or delete the "items". So basically,
 just a simple table. Later on, some Comet stuff would be nice, to see
 changes on the table immediately.

 I've tried to add a new menu entry in Boot.scala, but I don't really
 know how/where the XML should come from

>>>
>>> What XML goes into a menu item?
>>>
>>>

 thanks.

 --~--~-~--~~~---~--~~
 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, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Surf the harmonics
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=.
>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google Groups
>>> "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> liftweb+unsubscr...@googlegroups.com
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/liftweb?hl=.
>>>
>>
>>
>>
>> --
>> James A Barrows
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=.
>>
>>
>>--
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=.
>>
>
>
>
> --
> James A Barrows
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit thi

Re: [Lift] Another List "XYZ" Menu Entry

[Jim Barrows]

On Fri, Nov 20, 2009 at 7:07 AM, Hannes  wrote:

>  Maybe you could give a one liner, showing how to write the menu item in
> Boot.scala.
>

A menu entry looks something like:
Menu( Loc("helpHome", ("help" :: "" ::Nil) -> true, "Help"))

The list ( "help" :: "" :: Nil) is the path to the the page.   In this case
the -> True says that everything underneath help is ok.

So you could do "path" :: "to" :: "my" :: "page" :: Nil and -> false

There's a great description in section 5 of the Exploring lift PDF if you
need more help.


> thanks.
>
>  On Fri, Nov 20, 2009 at 6:26 AM, Hannes  wrote:
>
>> I meant, that I had general problems to find a way how to do it, not
>> talking about the "Lift" way to do it.
>>
>> So I think I need a new XHTML page where I call a snippet method, that
>> displays the table. Then, from the menu item, I just link to that new page?
>> Would that be the right way?
>>
>
> I'm not sure what you're asking.  You could do it with an xhtml page, you
> could also build the table in code, like the CRUDify stuff does.  Either way
> works, if I understand you correctly.
>
>
>
>>
>> thanks.
>>
>>
>>
>> On Mon, Nov 16, 2009 at 8:51 AM, Hannes  wrote:
>>
>>>
>>> Hi Lifters,
>>>
>>> I need a new menu entry that displays a table similar to the one, that
>>> is shown by the CRUDify List "XYZ" link. But I need to display different
>>> fields without the chance to edit or delete the "items". So basically,
>>> just a simple table. Later on, some Comet stuff would be nice, to see
>>> changes on the table immediately.
>>>
>>> I've tried to add a new menu entry in Boot.scala, but I don't really
>>> know how/where the XML should come from
>>>
>>
>> What XML goes into a menu item?
>>
>>
>>>
>>> thanks.
>>>
>>> --~--~-~--~~~---~--~~
>>> 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, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=.
>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=.
>>
>
>
>
> --
> James A Barrows
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>



-- 
James A Barrows

--

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

Re: [Lift] Another List "XYZ" Menu Entry

[Jim Barrows]

On Fri, Nov 20, 2009 at 6:26 AM, Hannes  wrote:

>  I meant, that I had general problems to find a way how to do it, not
> talking about the "Lift" way to do it.
>
> So I think I need a new XHTML page where I call a snippet method, that
> displays the table. Then, from the menu item, I just link to that new page?
> Would that be the right way?
>

I'm not sure what you're asking.  You could do it with an xhtml page, you
could also build the table in code, like the CRUDify stuff does.  Either way
works, if I understand you correctly.



>
> thanks.
>
>
>
> On Mon, Nov 16, 2009 at 8:51 AM, Hannes  wrote:
>
>>
>> Hi Lifters,
>>
>> I need a new menu entry that displays a table similar to the one, that
>> is shown by the CRUDify List "XYZ" link. But I need to display different
>> fields without the chance to edit or delete the "items". So basically,
>> just a simple table. Later on, some Comet stuff would be nice, to see
>> changes on the table immediately.
>>
>> I've tried to add a new menu entry in Boot.scala, but I don't really
>> know how/where the XML should come from
>>
>
> What XML goes into a menu item?
>
>
>>
>> thanks.
>>
>> --~--~-~--~~~---~--~~
>> 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, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>



-- 
James A Barrows

--

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

Re: [Lift] JPA and eager fetch

[Jim Barrows]

Model isn't doing much other then setting up the manager to work, so I don't
think that's the issue.
I don't have time to look at it this morning, but if no one has an answer
for you, I'll try to help this evening.

On Thu, Nov 19, 2009 at 5:40 PM, wstrange  wrote:

>
>
> Newbie Lift / JPA alert!
>
> I am sure I am doing something dumb here, but I can't quite figure it
> out. I have a JPA project (modelled after the lift JPA demo app).
>
> I have an object with a one-to-many association, and I want to eager
> fetch the collection.  It is declared like :
>
>  @OneToMany(){ val targetEntity = classOf[OpenIdUser], val cascade =
> Array(CascadeType.ALL), val fetch=FetchType.EAGER}
>  var openIds : _root_.java.util.Set[OpenIdUser] = new
> _root_.java.util.HashSet[OpenIdUser]()
>
>
> In my spa persistence unit, eager fetching works fine from the unit
> test. The unit test uses plain old emf factory instances.
>
> However, from my web application (run with jetty:run) and  using
> Model.createNamedQuery, or Model.find, only the parent object is
> fetched. The collection is not.
>
>
> I gather this has something to do with the way that Model works? Or
> are my annotations being ignored when they are packed in a .jar file?
>
> Clues would be appreciated.
>
> Thanks
>
> Warren
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>


-- 
James A Barrows

--

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

Re: [Lift] Looking for the single person who owns naming in Lift

[Jim Barrows]

I'm still new to learning Lift, and Scala for that matter, but if you can't
find anyone better, I'll do it.

On Thu, Nov 19, 2009 at 12:37 PM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

> Folks,
>
> There has been a lot of talk about method/class naming in Lift lately.
> It's a good thing(tm) to normalize method and class naming in Lift.
>
> But it's also important that after the initial cleanup is done, the
> consistency is kept going forward.  It's also important that there's a pair
> of eyes looking at code as it's evolving and getting the names right early.
> For example, the common Actor stuff was floating around for 6 weeks (and
> very publicly so) before we rolled it into Lift.  Jonas and I were the only
> ones that commented on the code.  We got it to where we liked it and pushed
> it into master... then people made suggestions about the names.  This is the
> wrong time.  As important APIs are evolving, it's important to get the names
> right before people start using the code.
>
> So, I'm asking for someone in the community to step forward and own naming
> in Lift.  You may choose to have commit rights to the Lift code or not, but
> you will be responsible for:
>
>- Understanding most (all?) of the Lift modules such that the person
>has a broad understanding of the pieces of Lift
>- Organizing a set of change recommendations for name changes and
>deprecations
>- Soliciting community involvement and feedback on the recommendations
>- Finalizing the recommendations for the next release of Lift (whether
>that's called 1.1 or 2.0)
>- Doing ongoing review of material additions to Lift to make sure
>things are consistent
>
> So, if you're interested in that role (and it's a non-trivial time
> commitment over the next 6 weeks), please contact me off-list and let's
> chat.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>



-- 
James A Barrows

--

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

Re: [Lift] Re: Call it Lift 2.0

[Jim Barrows]

Only if Phx is in town :)

On Wed, Nov 18, 2009 at 10:48 AM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> Jim,
>
> Let's stop this discussion (I won't convince you and you wont't convince
> me) and start doing something more valuable: Are you in town for a couple of
> beers?
>
> Heiko
>
> 2009/11/18 Jim Barrows 
>
>>
>>
>> On Wed, Nov 18, 2009 at 10:25 AM, Heiko Seeberger <
>> heiko.seeber...@googlemail.com> wrote:
>>
>>> Jim,
>>>
>>> 2009/11/17 Jim Barrows 
>>>
>>>>
>>>> The behavior of a method, it's implementation is part of the contract I
>>>> have with the library.
>>>>
>>>
>>> Behavior yes, as long as agreed part of the contract. Implementation no.
>>>
>>
>> Implementation is not behavior?
>>
>>
>>>
>>>
>>>> So, just because you, or some committee ...
>>>>
>>>
>>> Not a committe, but the developer of the library.
>>>
>>
>> I don't care who.  Somebody, who isn't me, is deciding whether the impact
>> to me is is minor (ie 0.0.1), major (ie 0.1.0), or catastrophic (ie 1.0.0).
>>
>>
>>>
>>>> ... think that the change is "minor", I still have to thoroughly test
>>>> everything that uses your library.
>>>>
>>>
>>> Did you hear me saying "Don't test your app when a required library
>>> changes its version"?
>>>
>>
>> Yes, actually your attempting to use a scheme to tell me what I need to
>> test.  If you agree that with every change, I need to test those changes,
>> then why complicate everybody's lives with number schemes?  Because whether
>> a someone uses the OSGI complex scheme of numbers, or Ubuntus year.month
>> scheme, it still means I have to read the change list, and test the things
>> that changed.
>>
>>
>>>
>>>
>>>> As to your "As Lift also is to support OSGi (already some support in
>>>> place) it would be beneficial to stick to this version policy" comment.  I
>>>> counter with "Lift works on Ubuntu it would be beneficial to stick to this
>>>> version policy" and of course "Lift runs on scala  it would be beneficial 
>>>> to
>>>> stick to this version policy", or better yet "Lift runs  on the Java VM it
>>>> would be beneficial to stick to this version policy."  All three of my
>>>> arguments have far more to do with Lift running then OSGI does.
>>>>
>>>
>>> If you are not interested in OSGi or Lift's OSGi support, then just
>>> ignore it. As far as I know neither Ubuntu, nor Scala, nor the JVM care
>>> about Lift's version number or version strategy. But OSGi does!
>>>
>>
>> You miss my point.  My point was that the argument you make is useless.
>>
>>
>>>
>>>
>>>> That's what I really need to know,
>>>>
>>>
>>> Please accept that other folks might have different needs.
>>>
>>
>> You cut the context.  However Everyone needs to know that things
>> changed.  And they need to know what changed.  The OSGI scheme attempts to
>> tell the developer how severe the change is, without knowing how the
>> developer is using the library.  That's useless.
>> --
>> James A Barrows
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> liftweb+unsubscr...@googlegroups.com
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/liftweb?hl=.
>>
>
>
>
> --
> Heiko Seeberger
>
> My job: weiglewilczek.com
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>



-- 
James A Barrows

--

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

Re: [Lift] Re: Call it Lift 2.0

[Jim Barrows]

On Wed, Nov 18, 2009 at 10:25 AM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> Jim,
>
> 2009/11/17 Jim Barrows 
>
>>
>> The behavior of a method, it's implementation is part of the contract I
>> have with the library.
>>
>
> Behavior yes, as long as agreed part of the contract. Implementation no.
>

Implementation is not behavior?


>
>
>> So, just because you, or some committee ...
>>
>
> Not a committe, but the developer of the library.
>

I don't care who.  Somebody, who isn't me, is deciding whether the impact to
me is is minor (ie 0.0.1), major (ie 0.1.0), or catastrophic (ie 1.0.0).


>
>> ... think that the change is "minor", I still have to thoroughly test
>> everything that uses your library.
>>
>
> Did you hear me saying "Don't test your app when a required library changes
> its version"?
>

Yes, actually your attempting to use a scheme to tell me what I need to
test.  If you agree that with every change, I need to test those changes,
then why complicate everybody's lives with number schemes?  Because whether
a someone uses the OSGI complex scheme of numbers, or Ubuntus year.month
scheme, it still means I have to read the change list, and test the things
that changed.


>
>
>> As to your "As Lift also is to support OSGi (already some support in
>> place) it would be beneficial to stick to this version policy" comment.  I
>> counter with "Lift works on Ubuntu it would be beneficial to stick to this
>> version policy" and of course "Lift runs on scala  it would be beneficial to
>> stick to this version policy", or better yet "Lift runs  on the Java VM it
>> would be beneficial to stick to this version policy."  All three of my
>> arguments have far more to do with Lift running then OSGI does.
>>
>
> If you are not interested in OSGi or Lift's OSGi support, then just ignore
> it. As far as I know neither Ubuntu, nor Scala, nor the JVM care about
> Lift's version number or version strategy. But OSGi does!
>

You miss my point.  My point was that the argument you make is useless.


>
>
>> That's what I really need to know,
>>
>
> Please accept that other folks might have different needs.
>

You cut the context.  However Everyone needs to know that things
changed.  And they need to know what changed.  The OSGI scheme attempts to
tell the developer how severe the change is, without knowing how the
developer is using the library.  That's useless.
-- 
James A Barrows

--

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

Re: [Lift] Re: Call it Lift 2.0

[Jim Barrows]

On Mon, Nov 16, 2009 at 11:13 PM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> I think version numbers are idiotic, and created by the marketing
>> department, and not engineers.
>>
>
> I strongly disagree: An appropriate version strategy is not at all about
> marketing but expresses valuable information. In OSGi increasing the major
> version means breaking changes in the API, increasing the minor version
> means nonbreaking changes in the API and increasing the micro version means
> no changes to the API but only changes of the implementation. Further these
> versions are used to declare dependencies between modules (OSGi bundles)
> which results in a high degree of trust that different modules work
> seamlessly together. As Lift also is to support OSGi (already some support
> in place) it would be beneficial to stick to this version policy.
>


Version numbers only guarantee that the number is different.  What you call
"no changes to the API, but changes to the implementation', I call
"completely destroy my expectations of how this works, and therefore creates
a show stopper bug for me."  Which, by your logic should have been a more
major number.  And this entire argument proves my point.  I can counter
every argument you have for your scheme with real world epic fails that
happened because one person version of minor, is another persons version of
major.

The behavior of a method, it's implementation is part of the contract I have
with the library.  If you change the behavior I depend on, then that's
major.  No matter how minor  you might think the change.  Moving from a
hashmap to a list is a huge change, for a sufficiently large set of data for
instance.  I can think of several hundred other "minor" implementation
changes you can make, that can have drastic consequences to the calling
code.  So, just because you, or some committee think that the change is
"minor", I still have to thoroughly test everything that uses your library.
So calling it minor doesn't do me any good.

As to your "As Lift also is to support OSGi (already some support in place)
it would be beneficial to stick to this version policy" comment.  I counter
with "Lift works on Ubuntu it would be beneficial to stick to this version
policy" and of course "Lift runs on scala  it would be beneficial to stick
to this version policy", or better yet "Lift runs  on the Java VM it would
be beneficial to stick to this version policy."  All three of my arguments
have far more to do with Lift running then OSGI does.

Most important it's not KISS.  At least Ubuntu's year.month is simple.  Most
importantly it tells you that you need to test your stuff to make sure it
works because stuff has changed.  That's what I really need to know, that
and how old is my library.  How old is version 2.3.1?  A year?  two years?
6 months?  How do I know when to go looking for an updated version of the
library?



> I think a 2.0 needs more time with a 2.0 mindset.
>
> Once 2.0 is on the table there may be more redesign involved.
>
>
> I disagree: Versions should not express a mindset but information about
> (non)breaking API changes. That's all, no magic, no marketing, no mindset.
>
> Heiko Seeberger
>
> My job: weiglewilczek.com
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>



-- 
James A Barrows

--

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

Re: [Lift] Hosting problem, could PHP hosting front end the Liftweb? or is there cheap Liftweb hosting?

[Jim Barrows]

I use rackspace cloud servers (rackspacecloud.com) for my hosting.  runs me
about 55/month for a medium sized server.  They have an API etc for
autostarting servers, and shutting them down.
Then you have the spring source
stuffthat runs on
Amazon, but gives you pushbutton deployment and autoscaling
etc.

On Mon, Nov 16, 2009 at 9:45 PM, philip  wrote:

> Hi,
>
> I will explain my problem, generally it is easy and cheap to get a PHP
> hosting account, often my new customers for websites have a PHP
> hosting as they are on the cheaper end of websites.
> My real server is using dyndns and is located "at home".
>
> Although I have one server, I cannot host many domains on it. So my
> thought is that if I could write a PHP script I could use that to
> "mirror" my real server, also conbined with a .htaccess. So a request
> going to the PHP server hosting the domain would be re-directed to my
> real server and the content sent back to the client.
> I guess a iframe would work, but thats ugly. There's a few ways to do
> this.
>
> What about the Javascript and Ajax, could that work cross-domain? For
> example, going directly to server rather than proxy by the PHP
> hosting?
>
> Well I'll try it out some time soon and put some followup info on
> here.
>
> This is all because its not so easy to get cheap Liftweb hosting! ...
> or does anyone have a solution for that?
>
> Thanks, Philip
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
>
>


-- 
James A Barrows

--

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

[Lift] Re: Call it Lift 2.0

[Jim Barrows]

On Mon, Nov 16, 2009 at 4:01 PM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> Hi,
>
> There has been a large amount of new stuff and also some breaking changes
> since Lift 1.0. As an OSGi guy I suggest we call the next version Lift 2.0,
> because increasing the major version number will show the world that there
> are breaking changes and/or cool new features. At least, this is how
> versions are used in OSGi land. OK, I know that Sun follows another version
> strategy (keeping the major version fixed to 1 forever) and the Scala folks
> also seem to be stick to 2.x (quite a lot people would like 2.8 to be 3.0),
> but IMHO this is no reason for Lift to follow the same mislead strategy. So
> what do you think?
>

I think version numbers are idiotic, and created by the marketing
department, and not engineers.  You just need a build number so you can tell
if you're on the right version, and that's about it.  As you point out, one
mans 1.3 is another mans 2.0.

The version number should be something like 20091231 to indicate just how
old your version is.  Anything else is just madness :)


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


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Problems downloading dependencies, can't get started

[Jim Barrows]

Nate there is a directory in your home directory called ".m2".  Delete that and 
retry.
If that doesn't work, and nobody else jumps in, its an issue with maven.  I'm 
mobile abd be more helpful I'm afraid.
Sent on the Now Network™ from my Sprint® BlackBerry

-Original Message-
From: Nate Martin 
Date: Sat, 14 Nov 2009 16:32:19 
To: Lift
Subject: [Lift] Problems downloading dependencies, can't get started


Hi-

I was very intrigued with Lift, so I tried to work my way through the
Hello World tutorial. Unfortunately, I can't seem to get that to work.

I'm running on Snow Leopard. I installed Lift with the installer
downloaded from the Lift web site (version 1.0.1). When I first ran
"mvn jetty:run" it tried to download a bunch of dependencies.
Unfortunately, I was in china on a business trip when this happened,
and because of my spotty internet connection, I don't think all the
dependencies downloaded, and I couldn't launch the hello world
tutorial.

Now, I'm back in the states, but I can't figure out how to get Maven
to retry downloading the dependencies. All that happens when I type
"mvn jetty:run" is:

[INFO] Copying 0 resource
[WARNING] POM for 'backport-util-concurrent:backport-util-
concurrent:pom:3.0:runtime' is invalid.

Its dependencies (if any) will NOT be available to the current build.
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error configuring: net.sf.alchim:yuicompressor-maven-plugin.
Reason: A required class was missing during mojo configuration: org/
mozilla/javascript/ErrorReporter
[INFO]

[INFO] For more information, run Maven with the -e switch


Can anyone give me some advice on fixing this?

Thanks,
Nate



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

[Lift] Re: How do you set disabled/readonly attributes from a snippet?

[Jim Barrows]

I'm importing HttpHelpers, and the implicit is not there.
Did this change for M7?

On Mon, Nov 9, 2009 at 6:41 PM, Ross Mellgren  wrote:

>
> Use None (Option) or Empty (Box) as the value of the attribute -- this
> will cause the pairToUnprefixed implicit that is being used inside
> SHtml to not generate an attribute.
>
> e.g.:
>
> val disableAttr: Box[String] = if (disableAll) Full("disabled") else
> Empty
>
> bind("person", xhtml,
>  ...
>   "firstName" -> SHtml.text(person.firstName, person.firstName =
> _, "id" -> "firstName", "disabled" -> disableAttr),
>  ...)
>
> -Ross
>
>
> On Nov 9, 2009, at 6:51 PM, Jim Barrows wrote:
>
> > I found this answer on nabble but it's regarding setting the values
> > client side.  I want to set them in the snippet, depending on data.
> > This doesn't work, but will give you a better idea of what I'm
> > trying to do:
> >  def bindPerson(xhtml: NodeSeq, action: () => Unit,
> > submitButtonName: String, disableAll: boolean): NodeSeq = {
> > // Hold a val here so that the "id" closure holds it when we re-
> > enter this method
> > val currentId = person.id
> > val disableString :String = disableAll match {
> >   case true => "disabled"
> >   case false => ""
> > }
> > bind("person", xhtml,
> >   "id" -> SHtml.hidden(() => person.id = currentId),
> >   //  "version" -> SHtml.hidden(() => person.version),
> >   "firstName" -> SHtml.text(person.firstName, person.firstName =
> > _, "id" -> "firstName", "disabled" -> disableString),
> >   "middleName" -> SHtml.text(person.middleName,
> > person.middleName = _, "id" -> "middleName", "disabled" ->
> > disableString),
> >   "lastName" -> SHtml.text(person.lastName, person.lastName = _,
> > "id" -> "lastName", "disabled" -> disableString),
> >   "submit" -> SHtml.submit(?(submitButtonName), action))
> >   }
> >
> > --
> > James A Barrows
> >
> >
> > >
>
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Template help

[Jim Barrows]

On Wed, Nov 11, 2009 at 11:21 AM, aw  wrote:

>
> OK, your suggestion definitely makes the snippet code more readable,
> but I fear I didn't make my point clear because the snippet code still
> is highly coupled with the view layout.
>

If this was a MVC type framework, I think you're point would be valid.  But
it isn't a MVC framework.  The snippet is tightly coupled to the xhtml,
because it's the dynamic part of the xhtml.

The best way to mitigate these kinds of changes is to design the UI first,
then build the snippets.   That way, you're not rearranging as often.
See this article for a better understanding:
http://wiki.liftweb.net/index.php?title=Lift_View_First


> Imagine that I want to change my view from this:
>
> 
>name
>description
>
> 
>
> to this:
>
> name
> description
> 
> 
> 
>
> This would mean that I need to change my template from:
>
> 
>
>
>
> 
>
> to this:
>
> 
> 
> 
>
> 
>
> And then I need to update my code from:
>
> bind("b1", xhtml",
>   "link" -> kids => SHtml.link("next", () => clicked(b),
>bind("b2", kids, "name" -> b.name.is, "description" ->
> b.description.is
> )))
>
> to something like this:
>
> bind("b", xhtml",
>   "name" -> b.name.is,
>   "description" -> b.description.is,
>   "link" -> kids => SHtml.link("next", () => clicked(b))
> )))
>
>
> My complaint is that reorganizing the view is tending to require code
> changes at the snippet level.  And that just doesn't seem right to me.
>
> At first, I thought that I could leverage the recursive nature of
> snippets.  In other words, I thought I could avoid the b1 and b2
> binding keys and simply use b, then when the first round contained
> more b variables to bind, it would recurse.  Alas, this didn't work
> (I'm sorry, but I don't recall the error message).  But this was what
> I was thinking:
>
> 
>
>
>
> 
>
> or this:
>
> 
> 
> 
>
> 
>
> and the code would remain this:
>
> bind("b", xhtml",
>   "name" -> b.name.is,
>   "description" -> b.description.is,
>   "link" -> kids => SHtml.link("next", () => clicked(b))
> )))
>
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: ManyToMany decision

[Jim Barrows]

On Tue, Nov 10, 2009 at 2:16 PM, Naftoli Gugenheim wrote:

> Hello.
> When I wrote ManyToMany a couple of months ago, I designed it to internally
> hold a collection of join table records, and to act as a collection of
> elements of the child table.
> For example, given Volunteer and VolunteerGroup where volunteers can be in
> multiple groups, Volunteer.volunteerGroups implements a collection of
> VolunteerGroups, but internally it's actually managing a collection of
> VolunteerVolunteerGroups (the join table).
>

I don't think you really need to maintain the pivot table list
(VolunteerVolunteerGroups) at all.  If you maintain the Many-to-Many as part
of the object, and use a standard naming convention then you don't really
need this extra list running around.  You can still build the SQL correctly
knowing only the objects involved.


> The current implementation throws an error (Predef.error) when it tries to
> get the child element via the join record and it doesn't exist. Thus any
> page accessing corrupted data will not display if the error is not caught. I
> plan, G-d willing, to change the implementation to silently skip such
> records.
> But the occurrence that reminded me of the defect also brought another
> point to my attention. To my knowledge Lift's schemifier does not correctly
> generate foreign key constraints for all databases (at least not at the
> point in time it schemified my H2 database... :) ) so we need a way for
> ManyToMany to keep things in sync. ManyToMany helps, to an extent, because
> when its MappedManyToMany members are initialized, it puts them in a list,
> and it propagates saves and deletes. So if you have a ManyToMany Mapper
> instance that contains a MappedManyToMany that has been initialized, and you
> call delete_! on the Mapper, it will delete all the associated join table
> entries. But it's not enough.
>
>1. That can only happen if both sides of the relationship use
>MappedManyToMany. Is there some way to enforce this? I was thinking of 
> using
>a combination of (a) requiring the foreign MetaMapper to extends 
> ManyToMany,
>and (b) when a MappedManyToMany is initialized, it should check that the
>foreign MetaMapper/ManyToMany actually contains a MappedManyToMany 
> referring
>to the current MappedManyToMany. (a) is not sufficient without (b), and (b)
>has the same problem as #2 below, that objects are lazy.
>
>
I think you're right here.  Both sides have to have the mapping.. however I
don't think there is a good clean way to detect this without a compiler
plugin of some kind.



>
>1. There is a basic problem, which is that since objects are lazy, if
>you haven't referenced the MappedManyToMany field, delete_! will not be 
> able
>to propagate to the join entries.
>
>
As you traverse the deleteing side, doesn't the other side get initialized
as well?


> #2 and #1.b can be solved by using reflection to initialize the
> MappedManyToMany members eagerly, just as MetaMapper does for all
> MappedFields. (MappedManyToMany is not a MappedField.) Now the advantage to
> having them lazy is that if you don't reference them they don't query the
> database. This advantage can be retained though by implementing the
> collection internally to populate lazily, much as MappedOneToMany already
> is.
>
> Thoughts?
>

I think your maintaining to much information that can be deduced from the
context.


>
> Thanks,
>   Naftoli Gugenheim
>
>
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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] Where did Mapper's MappedManyToMany go?

[Jim Barrows]

I can see it 
herein
the 1.1M7 code base, but can't find it in the jar that Maven
downloaded.
The trait is there, but the Mapped version is missing.
The same for MappedOneToMany as well.

-- 
James A Barrows

--~--~-~--~~~---~--~~
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] How do you set disabled/readonly attributes from a snippet?

[Jim Barrows]

I found this answer on
nabblebut
it's regarding setting the values client side.  I want to set them in
the snippet, depending on data.
This doesn't work, but will give you a better idea of what I'm trying to do:
 def bindPerson(xhtml: NodeSeq, action: () => Unit, submitButtonName:
String, disableAll: boolean): NodeSeq = {
// Hold a val here so that the "id" closure holds it when we re-enter
this method
val currentId = person.id
val disableString :String = disableAll match {
  case true => "disabled"
  case false => ""
}
bind("person", xhtml,
  "id" -> SHtml.hidden(() => person.id = currentId),
  //  "version" -> SHtml.hidden(() => person.version),
  "firstName" -> SHtml.text(person.firstName, person.firstName = _, "id"
-> "firstName", "disabled" -> disableString),
  "middleName" -> SHtml.text(person.middleName, person.middleName = _,
"id" -> "middleName", "disabled" -> disableString),
  "lastName" -> SHtml.text(person.lastName, person.lastName = _, "id" ->
"lastName", "disabled" -> disableString),
  "submit" -> SHtml.submit(?(submitButtonName), action))
  }

-- 
James A Barrows

--~--~-~--~~~---~--~~
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: beginner's question about surround/bind/bind-at/with-param

[Jim Barrows]

On Thu, Nov 5, 2009 at 3:04 PM, jhonig  wrote:

>
> Thank you James,
>
> What I tried first was taken from
> http://wiki.github.com/dpp/liftweb/about-lift-tags.
> I don't have the code anymore.  It was a surround without "at"
> attribute, and with
> multiple "bind-at"-s inside.   Nothing got bound, as far as I could
> see.  When I
> replaced the bind-at's with with-params, they *did* bind as expected.
> However,
> head-merging didn't work.   No errors either, just didn't work.
>

 That would be because those are examples of tags, not copy-and-paste-code
necessarily.

I can think of about million definitions of "just didn't work".  Which one
do you mean here?



> When I used a surround with an "at" attribute as in the old wiki, but
> without bind-at's
> or with-params, head-merging *did* work!   That's why I assumed that
> that description
> was the newer version!  So now it seems I'm on the wrong track,
> because that's
> the code I started using.
>

Again.  No code, can't really tell you what's wrong, or right.


>
> Another problem I didn't resolve sofar is that I had a few
> conventional 
> elements in my page.  But jetty can't resolve them so clearly I have
> to do more
> than that.  Should be trivial, of course.  Guess it has something to
> do with the
> sitemap, but I don't have a clear picture as to how that works.  The
> examples
> I found are much more involved than what I was looking for.
>


Yes, sitemap is a place to start looking.
The problem is that you're not providing enough detail to help you out.
"Doesn't work" is not enough to help out.  Did you get a 404 error?  blank
page?  Anything at all?

Which examples are you talking about?  Most of the ones I've seen are fairly
trivial.



> Any help appreciated!
>
> Job Honig
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Making use of case classes and varargs in Link

[Jim Barrows]

On Mon, Nov 2, 2009 at 1:34 PM, Vesa  wrote:

>
> You're right about that. You probably wouldn't get very far without
> understanding that. I'm still concerned that I have to type
> unnecessary stuff to express myself without getting any gains in (new
>


A comma separated list of values inside a method call (ie, anything inside
parens) are arguments to the method, and not a list of names, in a
particular sequence that belong together.
This also means that you can have things like (I didn't run this through a
compiler, so syntax is off):
val someStandardDir = "dir1" :: "dir2" :: "dir3" :: Nil
Link( someStandardDir :: "file" :: Nil)

or

Link( fnThatCanCreateTheFirstBit() :: "finalBit" ::Nil)


All of which would harder to read, your way :)


Link("a" :: "b" :: nil) vs Link("a", "b")) :D
>
> - Vesa
>
> On 2 marras, 22:27, Jim Barrows  wrote:
> > On Mon, Nov 2, 2009 at 1:15 PM, Vesa  wrote:
> >
> > > Hi,
> >
> > > I was wondering few thing while reading lift examples. Could the Link
> > > class be turned into a case class so reading would improve? new Link
> > > ("a" :: "b" :: nil, false) could be RecursiveLink("a", "b") and new
> > > Link("a" :: "b" :: Nil) could be something like AbsoluteLink("a",
> > > "b"). This would at least eliminate the need to explain scala's list
> >
> > Shouldn't the reader already be aware of Scala's list construction, since
> > that is in fact the language we're using?
> > If you think Scala's list construction is difficult to for a new reader,
> I
> > think explaining a case class would be even more confusing.
> >
> > You might want to look at how case classes differ from a normal
> > class<http://www.scala-lang.org/node/258>as well.
> >
> >  construction syntax to the reader. I found out extremely unintuitive
> >
> > > the syntax to create Links with dsl like ("help" :: "" :: Nil) ->
> > > true. This syntax is usually associated with generation of key-value
> > > pairs even in lift APIs and creates confusion (at least on my case). I
> > > guess varargs might be out of question if scala backward compatibility
> > > is considered, but I don't see a reason not to use case classes here.
> >
> > > - Vesa
> >
> > --
> > James A Barrows
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Why menu generation and page access control is combined?

[Jim Barrows]

On Mon, Nov 2, 2009 at 1:25 PM, Vesa  wrote:

>
> Hi,
>
> I have a feeling that SiteMap is a common cause of frustration among
> newbies and was wondering why is it so? Having visible menu entries
> generated by default on controlled pages made me feel that the
> framework is making too many assumptions. I would personally prefer
> having to explicitly make pages as menu items or make some kind of
> distinction between access control and menus. Is it so common case
> that this is the best thing to do and I just don't realize yet how
> much easier my life is with SiteMap?
>

Pretty much.  Yes.

You can control visibility of the entries however you want, so all
assumptions can be overridden.


>
> - Vesa
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Making use of case classes and varargs in Link

[Jim Barrows]

On Mon, Nov 2, 2009 at 1:15 PM, Vesa  wrote:

>
> Hi,
>
> I was wondering few thing while reading lift examples. Could the Link
> class be turned into a case class so reading would improve? new Link
> ("a" :: "b" :: nil, false) could be RecursiveLink("a", "b") and new
> Link("a" :: "b" :: Nil) could be something like AbsoluteLink("a",
> "b"). This would at least eliminate the need to explain scala's list
>

Shouldn't the reader already be aware of Scala's list construction, since
that is in fact the language we're using?
If you think Scala's list construction is difficult to for a new reader, I
think explaining a case class would be even more confusing.

You might want to look at how case classes differ from a normal
classas well.

 construction syntax to the reader. I found out extremely unintuitive
> the syntax to create Links with dsl like ("help" :: "" :: Nil) ->
> true. This syntax is usually associated with generation of key-value
> pairs even in lift APIs and creates confusion (at least on my case). I
> guess varargs might be out of question if scala backward compatibility
> is considered, but I don't see a reason not to use case classes here.
>
> - Vesa
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Why no default with getSingleton?

[Jim Barrows]

On Mon, Nov 2, 2009 at 1:16 PM, Vesa  wrote:

>
> By the way, why orm classes need to be aware of the companion object?
> Could this dependency be eliminated somehow?
>

The Mapper/Record companion object is where the code to do all the DB stuff
lives.  These are all static methods, they don't really change per instance
of the class itself.  The companion object is one way Scala allows you to do
this.  It's probably also the most convenient.
An answer to the question: What is the rationale behind having companion
objects in 
scala.


>
> - Vesa
>
> On 2 marras, 22:02, Vesa  wrote:
> > I doubt I can find one, but it still feels awkward having to type the
> > name of the class so many times. Another option could be to use some
> > shared object to do this stuff, but I guess it wouldn't be as neat to
> > use it then.
> >
> > - Vesa
> >
> > On 2 marras, 18:33, David Pollak 
> > wrote:
> >
> >
> >
> > > On Mon, Nov 2, 2009 at 8:14 AM, Vesa  wrote:
> >
> > > > It seems like boilerplate that every mapped class needs to define a
> > > > getSingleton method returning companion object. Can't there be any
> > > > default with this and is there any way to get rid of the manually
> > > > defined companion object if user isn't going to define any new
> methods
> > > > on it, while still having the default meta functionality?
> >
> > > I know of no mechanism in Scala to discover companion objects.  If you
> find
> > > one (that's not simply Java Reflection), please let me know.
> >
> > > > - Vesa
> >
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Surf the harmonics
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Anything similar as Rack::Test and rspec for lift applications?

[Jim Barrows]

Scala has 2 test frameworks (Specs , scala
test ) that I'm aware of, and can make use
of the selenium test framework .

You could also, I suppose use JUnit or TestNG java frameworks if you wanted,
again with selenium.

On Mon, Nov 2, 2009 at 6:41 AM, Vesa  wrote:

>
> Hi,
>
> Ruby web apps can be tested easily with Rack::Test like on the example
> below. Is there anything similar tfor org.specs and lift? I see the
> lack of tutorials/documentation on testing the greatest obstacle of
> taking lift into use.
>
> require 'hello_world'
> require 'test/unit'
> require 'rack/test'
>
> set :environment, :test
>
> class HelloWorldTest < Test::Unit::TestCase
>  include Rack::Test::Methods
>
>  def app
>Sinatra::Application
>  end
>
>  def test_it_says_hello_world
>get '/'
>assert last_response.ok?
>assert_equal 'Hello World', last_response.body
>  end
>
>  def test_it_says_hello_to_a_person
>get '/', :name => 'Simon'
>assert last_response.body.include?('Simon')
>  end
> end
>
> -Vesa
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: I am not able to save a many-to-many relationship from an API

[Jim Barrows]

On Mon, Oct 26, 2009 at 3:42 PM, Naftoli Gugenheim wrote:

>
> Do you mean foreign keys? Why does that preclude linking them before
> they're saved? OneToMany also uses a foregn key / primary key relationship,
> and you can use LongMapperMapper.
>


Yes, the pivot table has 2 foreign keys as it's primary keys.  The pivots
tables primay key is typically a compound key of Table1 & Table2's PK's.
You can't save the pivot table before Table1 & 2 because the primary keys
for Table 1&2 don't exist yet in the database.  You can update in any order
(provided the PK's aren't changing of course).



> -
> Jim Barrows wrote:
>
> On Mon, Oct 26, 2009 at 2:36 PM, Naftoli Gugenheim  >wrote:
>
> >
> > What do you mean by that? Every primary key is unique.
> >
>
> The pivot table is typically only 2 columns, which are the PK's for each
> side of the MTM.
> ----  ---
> |Table1|->|Pivot|<|Table2|
> ---  ---
> PK1PK1    PK2
>  PK2
>
>
> Sorry, should have drawn that out earlier :)
>
>
> > -
> > Jim Barrows wrote:
> >
> > On Mon, Oct 26, 2009 at 12:05 PM, Naftoli Gugenheim <
> naftoli...@gmail.com
> > >wrote:
> >
> > >
> > > It would be feasible to refactor ManyToMany to remove this restriction.
> > > OneToMany does not require either side to be saved first.
> > > Can you describe a use case where it would be desirable?
> > >
> >
> > I don't think there is.
> > OneToMany it makes sense that there is no requirement for either side to
> be
> > saved first.  However, the pivot table involved in a ManyToMany always
> > needs
> > both PK's to be unique.
> >
> >
> > > -
> > > Jim Barrows wrote:
> > >
> > > On Mon, Oct 26, 2009 at 11:43 AM, GA  wrote:
> > >
> > > > I have made a test that worked. I have modified my code like this:
> > > >
> > > > newUser.save
> > > > newUser.devices += newDevice
> > > > newUser.save
> > > >
> > > > The newDevice was already saved. It looks like both parents must be
> > saved
> > > > before I save the relationship. Am I right? or I am doing something
> > > wrong?
> > > >
> > >
> > > No, you always have to save the parents before the relationship.
>  Well..
> > as
> > > long as the relationship table has the parents PK as it's PK's anyway.
> > > If you remove that restriction, then nah.. it doesn't matter.  Of
> course
> > > that way lies madness
> > >
> > >
> > > > Thanks,
> > > >
> > > > GA
> > > >
> > > >
> > > >
> > > >
> > > > On Oct 26, 2009, at 6:55 PM, GA wrote:
> > > >
> > > > Hello guys,
> > > >
> > > > I have a many-to-many relationship between two mappers called, Users
> > and
> > > > Devices.
> > > >
> > > > There is also an API that receives and XML message that contains one
> > user
> > > > and one device.
> > > >
> > > > The API could create the Device and User with the relationship or it
> > > could
> > > > create only the relationship in case the users and/or device already
> > > exists.
> > > >
> > > > The problem I have is that the API creates the User and the Device,
> but
> > > the
> > > > not the relationship. This is the code that saves the records (just a
> > > test
> > > > for a now):
> > > >
> > > > def addUser(req: Req): LiftResponse = {
> > > >
> > > > var tempUserName = ""
> > > > var tempDeviceName = ""
> > > > var deviceAlreadyExists = false
> > > >
> > > > val newUser = new User
> > > > val newDevice = new Device
> > > > req.xml match {
> > > > case Full({parameters @_*}) => {
> > > > for(parameter <- parameters){ parameter match {
> > > >   

[Lift] Re: I am not able to save a many-to-many relationship from an API

[Jim Barrows]

On Mon, Oct 26, 2009 at 2:36 PM, Naftoli Gugenheim wrote:

>
> What do you mean by that? Every primary key is unique.
>

The pivot table is typically only 2 columns, which are the PK's for each
side of the MTM.
----  ---
|Table1|->|Pivot|<|Table2|
---  ---
PK1PK1PK2
  PK2


Sorry, should have drawn that out earlier :)


> ---------
> Jim Barrows wrote:
>
> On Mon, Oct 26, 2009 at 12:05 PM, Naftoli Gugenheim  >wrote:
>
> >
> > It would be feasible to refactor ManyToMany to remove this restriction.
> > OneToMany does not require either side to be saved first.
> > Can you describe a use case where it would be desirable?
> >
>
> I don't think there is.
> OneToMany it makes sense that there is no requirement for either side to be
> saved first.  However, the pivot table involved in a ManyToMany always
> needs
> both PK's to be unique.
>
>
> > -
> > Jim Barrows wrote:
> >
> > On Mon, Oct 26, 2009 at 11:43 AM, GA  wrote:
> >
> > > I have made a test that worked. I have modified my code like this:
> > >
> > > newUser.save
> > > newUser.devices += newDevice
> > > newUser.save
> > >
> > > The newDevice was already saved. It looks like both parents must be
> saved
> > > before I save the relationship. Am I right? or I am doing something
> > wrong?
> > >
> >
> > No, you always have to save the parents before the relationship.  Well..
> as
> > long as the relationship table has the parents PK as it's PK's anyway.
> > If you remove that restriction, then nah.. it doesn't matter.  Of course
> > that way lies madness
> >
> >
> > > Thanks,
> > >
> > > GA
> > >
> > >
> > >
> > >
> > > On Oct 26, 2009, at 6:55 PM, GA wrote:
> > >
> > > Hello guys,
> > >
> > > I have a many-to-many relationship between two mappers called, Users
> and
> > > Devices.
> > >
> > > There is also an API that receives and XML message that contains one
> user
> > > and one device.
> > >
> > > The API could create the Device and User with the relationship or it
> > could
> > > create only the relationship in case the users and/or device already
> > exists.
> > >
> > > The problem I have is that the API creates the User and the Device, but
> > the
> > > not the relationship. This is the code that saves the records (just a
> > test
> > > for a now):
> > >
> > > def addUser(req: Req): LiftResponse = {
> > >
> > > var tempUserName = ""
> > > var tempDeviceName = ""
> > > var deviceAlreadyExists = false
> > >
> > > val newUser = new User
> > > val newDevice = new Device
> > > req.xml match {
> > > case Full({parameters @_*}) => {
> > > for(parameter <- parameters){ parameter match {
> > > case {userName} =>
> > > tempUserName = userName.text
> > > case {firstName} =>
> > > newUser.firstName(firstName.text)
> > > case {lastName} =>
> > > newUser.lastName(lastName.text)
> > > case {password} =>
> > > newUser.password(password.text)
> > > case {email} =>
> > > newUser.email(email.text)
> > > case {createdOn} =>
> > > newUser.createdOn(new java.util.Date(createdOn.text))
> > > case {updatedOn} =>
> > > newUser.updatedOn(new java.util.Date(updatedOn.text))
> > > case {deviceName} =>
> > > tempDeviceName = deviceName.text
> > > case _ =>
> > > }
> > > }
> > > try {
> > >
> Device.find(By(Device.deviceName,tempDeviceName))
> > > match {
> > > case Full(deviceRequested) =>
> > >   

[Lift] Re: I am not able to save a many-to-many relationship from an API

[Jim Barrows]

On Mon, Oct 26, 2009 at 12:05 PM, Naftoli Gugenheim wrote:

>
> It would be feasible to refactor ManyToMany to remove this restriction.
> OneToMany does not require either side to be saved first.
> Can you describe a use case where it would be desirable?
>

I don't think there is.
OneToMany it makes sense that there is no requirement for either side to be
saved first.  However, the pivot table involved in a ManyToMany always needs
both PK's to be unique.


> ---------
> Jim Barrows wrote:
>
> On Mon, Oct 26, 2009 at 11:43 AM, GA  wrote:
>
> > I have made a test that worked. I have modified my code like this:
> >
> > newUser.save
> > newUser.devices += newDevice
> > newUser.save
> >
> > The newDevice was already saved. It looks like both parents must be saved
> > before I save the relationship. Am I right? or I am doing something
> wrong?
> >
>
> No, you always have to save the parents before the relationship.  Well.. as
> long as the relationship table has the parents PK as it's PK's anyway.
> If you remove that restriction, then nah.. it doesn't matter.  Of course
> that way lies madness
>
>
> > Thanks,
> >
> > GA
> >
> >
> >
> >
> > On Oct 26, 2009, at 6:55 PM, GA wrote:
> >
> > Hello guys,
> >
> > I have a many-to-many relationship between two mappers called, Users and
> > Devices.
> >
> > There is also an API that receives and XML message that contains one user
> > and one device.
> >
> > The API could create the Device and User with the relationship or it
> could
> > create only the relationship in case the users and/or device already
> exists.
> >
> > The problem I have is that the API creates the User and the Device, but
> the
> > not the relationship. This is the code that saves the records (just a
> test
> > for a now):
> >
> > def addUser(req: Req): LiftResponse = {
> >
> > var tempUserName = ""
> > var tempDeviceName = ""
> > var deviceAlreadyExists = false
> >
> > val newUser = new User
> > val newDevice = new Device
> > req.xml match {
> > case Full({parameters @_*}) => {
> > for(parameter <- parameters){ parameter match {
> > case {userName} =>
> > tempUserName = userName.text
> > case {firstName} =>
> > newUser.firstName(firstName.text)
> > case {lastName} =>
> > newUser.lastName(lastName.text)
> > case {password} =>
> > newUser.password(password.text)
> > case {email} =>
> > newUser.email(email.text)
> > case {createdOn} =>
> > newUser.createdOn(new java.util.Date(createdOn.text))
> > case {updatedOn} =>
> > newUser.updatedOn(new java.util.Date(updatedOn.text))
> > case {deviceName} =>
> > tempDeviceName = deviceName.text
> > case _ =>
> > }
> > }
> > try {
> > Device.find(By(Device.deviceName,tempDeviceName))
> > match {
> > case Full(deviceRequested) =>
> > deviceAlreadyExists = true
> > case _ => {
> > newDevice.deviceName(tempDeviceName)
> > newDevice.createdBy(tempUserName)
> >
> newDevice.createdOn(newUser.createdOn)
> > newDevice.updatedBy(tempUserName)
> >
> newDevice.updatedOn(newUser.updatedOn)
> > newDevice.save
> > }
> > }
> > User.find(By(User.userName, tempUserName)) match
> {
> > case Full(userRequested) =>
> > CreatedResponse(wrapXmlBody( > id="addPerson" success="1">), "text/xml")
> > case _ => {
> > newUser.userName(tempUserName)
> > newUser.createdBy(tempUserName)

[Lift] Re: I am not able to save a many-to-many relationship from an API

[Jim Barrows]

On Mon, Oct 26, 2009 at 11:43 AM, GA  wrote:

> I have made a test that worked. I have modified my code like this:
>
> newUser.save
> newUser.devices += newDevice
> newUser.save
>
> The newDevice was already saved. It looks like both parents must be saved
> before I save the relationship. Am I right? or I am doing something wrong?
>

No, you always have to save the parents before the relationship.  Well.. as
long as the relationship table has the parents PK as it's PK's anyway.
If you remove that restriction, then nah.. it doesn't matter.  Of course
that way lies madness


> Thanks,
>
> GA
>
>
>
>
> On Oct 26, 2009, at 6:55 PM, GA wrote:
>
> Hello guys,
>
> I have a many-to-many relationship between two mappers called, Users and
> Devices.
>
> There is also an API that receives and XML message that contains one user
> and one device.
>
> The API could create the Device and User with the relationship or it could
> create only the relationship in case the users and/or device already exists.
>
> The problem I have is that the API creates the User and the Device, but the
> not the relationship. This is the code that saves the records (just a test
> for a now):
>
> def addUser(req: Req): LiftResponse = {
>
> var tempUserName = ""
> var tempDeviceName = ""
> var deviceAlreadyExists = false
>
> val newUser = new User
> val newDevice = new Device
> req.xml match {
> case Full({parameters @_*}) => {
> for(parameter <- parameters){ parameter match {
> case {userName} =>
> tempUserName = userName.text
> case {firstName} =>
> newUser.firstName(firstName.text)
> case {lastName} =>
> newUser.lastName(lastName.text)
> case {password} =>
> newUser.password(password.text)
> case {email} =>
> newUser.email(email.text)
> case {createdOn} =>
> newUser.createdOn(new java.util.Date(createdOn.text))
> case {updatedOn} =>
> newUser.updatedOn(new java.util.Date(updatedOn.text))
> case {deviceName} =>
> tempDeviceName = deviceName.text
> case _ =>
> }
> }
> try {
> Device.find(By(Device.deviceName,tempDeviceName))
> match {
> case Full(deviceRequested) =>
> deviceAlreadyExists = true
> case _ => {
> newDevice.deviceName(tempDeviceName)
> newDevice.createdBy(tempUserName)
> newDevice.createdOn(newUser.createdOn)
> newDevice.updatedBy(tempUserName)
> newDevice.updatedOn(newUser.updatedOn)
> newDevice.save
> }
> }
> User.find(By(User.userName, tempUserName)) match {
> case Full(userRequested) =>
> CreatedResponse(wrapXmlBody( id="addPerson" success="1">), "text/xml")
> case _ => {
> newUser.userName(tempUserName)
> newUser.createdBy(tempUserName)
> newUser.updatedBy(tempUserName)
> newUser.devices.clear
> newUser.validated(true)
> *newUser.devices += newDevice*
> newUser.save
> CreatedResponse(wrapXmlBody( id="addPerson" success="0">), "text/xml")
> }
> }
> }
> catch {
> case e => Log.error("Could not add person/device",
> e); BadResponse()
> }
> }
> case _ => Log.error("Request was malformed "+req.view);
> BadResponse()
> }
> }
>
> The field "devices" is the MappedManyToMany field within the User mapper.
>
> What am I doing wrong?
>
> Thanks in advance,
>
> GA
>
>
>
>
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Proposal : Lift ticketing system

[Jim Barrows]

ERP systen or parts, which is what I'm working over on sourceforge.  Ill post a 
link when I get home.  The models are built and just need apps in front of them.

Sent on the Now Network™ from my Sprint® BlackBerry

-Original Message-
From: jlist9 
Date: Sat, 24 Oct 2009 11:20:43 
To: 
Subject: [Lift] Re: Proposal : Lift ticketing system


CMS, wiki, blog, forum also sound more interesting than bug tracking
system to me :-)

On Sat, Oct 24, 2009 at 11:13 AM, aw  wrote:
>
> I don't mean to be negative, but are other options being considered
> besides a ticketing system?  I kind of wonder if the effort is worth
> it when excellent alternatives exist (like JIRA -- their Git
> integration may interest you:  
> https://plugins.atlassian.com/plugin/details/4984
> -- I have used their Subversion integration and was very pleased).
>
> I would be far more interested in seeing something done for the
> benefit of the Lift Web Site.  (Is it written with Lift?)  I don't see
> a Lift CMS -- and that is something that could evolve well over time.
> I think it is important for a web framework to use their own stuff,
> and it should be indicative of the cool things that it can do,
> stability, scale, and performance...  (I am amazed that I have seen
> rather poor demonstrations of this, specifically by Adobe and JBoss --
> but again, I'm not trying to be negative...)
>
> I see the Lift site integrating Google Analytics...  Is that something
> that could be "out of the box" with Lift?  That could be a selling
> point to people making external web sites.
>
> Another area that would be neat to develop is instrumentation.  Sort
> of the JMX-Console equivalent for Lift.  For scalability and sizing
> analysis, this would be really useful.
>
>
> Having said that, one major feature that I feel is missing from github
> is the lack of attachments for an issue.  How do you attach test cases
> or patches for an issue?
>
> >
>



--~--~-~--~~~---~--~~
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] In the spirit of Friday, anyone want to see this ruby rack ported to lift?

[Jim Barrows]

http://coderack.org/users/MetaSkills/entries/15-zombie-shotgun

and yes, I'm volunteering. :)

-- 
James A Barrows

--~--~-~--~~~---~--~~
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: A Critique On Lift

[Jim Barrows]

On Fri, Oct 23, 2009 at 3:28 PM, Viktor Klang wrote:

> On Sat, Oct 24, 2009 at 12:23 AM, Jim Barrows wrote:
>
>> On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang wrote:
>>
>>> But if you name your method: "ashiuahsdyasdasd" what does it do?
>>>
>>
>> Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read
>> it
>>
>
> Chtuluh ftagn! ;D
>

Huh.  Now he's 6 inches tall and has a red nose interesting.

Also I think we've made our point about cryptic method names whether there
alphanumeric or not, whether you call them operators or not... are
problematic.

Now excuse me... cthulu appears to be mucking with my code

James A Barrows

--~--~-~--~~~---~--~~
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: A Critique On Lift

[Jim Barrows]

On Fri, Oct 23, 2009 at 3:17 PM, Viktor Klang wrote:

> But if you name your method: "ashiuahsdyasdasd" what does it do?
>

Oh Bloddy Ell... that caused Cthulu to appear on my keyboard when I read
it


>
> On Fri, Oct 23, 2009 at 9:47 PM, bob  wrote:
>
>>
>> >I'll repeat: there are no operators in scala
>>
>> s/operators/methods-with-operator-like-names/
>>
>> anywhere, here's a typical case:
>>
>> import some.library.package.foo._
>>
>> val a = bar 42
>> val b = a ~!~ 3.14159
>>
>> you can't easily tell that bar is being imported via foo._ .
>> what is bar's return type?
>> what does ~!~ do?
>>
>> i'm not saying its not possible to track all this down, but you can't
>> just print out a listing of a class and take it on the subway. you
>> have to have access to the scaladocs and possibly even the sources.
>>
>> --b
>>
>>
>>
>>
>>
>
>
> --
> Viktor Klang
> | "A complex system that works is invariably
> | found to have evolved from a simple system
> | that worked." - John Gall
>
> Blog: klangism.blogspot.com
> Twttr: viktorklang
> Code: github.com/viktorklang
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: A Critique On Lift

[Jim Barrows]

On Fri, Oct 23, 2009 at 9:15 AM, Chris Lewis wrote:

>
> My head just exploded. Twice.
>

That explains the wet face this morning when I woke up... thought it was the
dog licking it... :)


>
> ngocdaothanh wrote:
> > Because Lift's ad is so good.
>
> *boom*
>

It was good.  My first thought was "Yeah
rIGHT!"  Let's see what they mean.
And voila... here I am.. so it was good, if only because it was right :)


>
>  For example:
> >
> > "Lift is the only new framework in the last four years to offer fresh
> > and innovative approaches to web development. It's not just some
> > incremental improvements over the status quo, it redefines the state
> > of the art. If you are a web developer, you should learn Lift. Even if
> > you don't wind up using it everyday, it will change the way you
> > approach web applications."
> >
> > Lift can't be used without Scala. Is there a plan to implement Lift in
> > Clojure, for example? :D
>
> *BOOM*
>

Ummm.. ok.. This one I understand.


>
> >
> >
> > On Oct 22, 3:47 pm, TylerWeir  wrote:
> >> On Oct 22, 2:02 am, ngocdaothanh  wrote:
> >>
> >>> jlist9,
> >>> This is a Lift group, but I have to say I feel the same about Scala.
> >>> I had to ask for advice here:
> http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a...
> >>> Scala may help me to get my work done for the day. But I don't feel
> >>> happy with Scala. Scala makes me feel I'm a slave all the day to
> >>> machines (or Scala itself!).
> >> If it makes you feel like a slave, why are you using Scala at all
> >> then?
> >>
> >>
> >>
> >>> On Oct 22, 2:13 pm, jlist9  wrote:
>  override def validations = validPriority _ :: super.validations
>  This is a more of a comment about Scala than one about Lift - this
> does
>  look cryptic to me. And this is just one of the simpler syntax that
> confuses
>  people, who are new to the language. And I'm one of them.
>  I understand that you don't have to learn all the tricks/syntax to
> start
>  coding in Scala but you do have to understand it when you read
>  source code of libraries written by someone with much more advanced
>  language skills.
>  In David's book he says "After more than two years of coding Scala,
> ...
>  My brain has finally stopped hurting." This sounds like a very high
>  barrier to entry.
>  I'm just wondering why Scala has to be so complicated. I'm sure a lot
>  of things in Scala have their reasons but at the mean time I also
>  suspect that many of the odd things are there to reduce
>  typing, which is advertised as one of the advantages of this language
> -
>  conciseness. (I could be very wrong due to my lack of understanding.)
>  If the latter is true, I feel that I'd rather type a little more to
> make the
>  code easier to read.
>  Just feeling a little frustrated learning Scala. I think it's much
>  easier learning
>  Java. Not much surprise. Not sure if anyone shares my experience
>  (and opinion, if there is one.)
>  On Wed, Oct 21, 2009 at 3:56 PM, Randinn  wrote:
> > http://localhost3000.de/2009/10/a-quick-glance-at-lift/
> > The site above is a blog post from a Rails developer, he had some
> good
> > and bad things to say about Lift and since I do not know enough to
> > debate with him I thought I'd post it here.
> >
> > >
> >
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: **Breaking Changes** **README** **Important**

[Jim Barrows]

RrttrRrrrtrtrtrrrtrtrtrrttÞ
Sent on the Now Network™ from my Sprint® BlackBerry

-Original Message-
From: ssid 
Date: Thu, 22 Oct 2009 18:03:25 
To: Lift
Subject: [Lift] Re: **Breaking Changes** **README** **Important**


Hi all,
I'm using XMPP in my little LiftApp and tried to migrate my code to
the new Lift Actors.
Somehow it seems that net.liftweb.xmpp still uses Scala Actors.
Is this intentional or about to change?
If not is it possible that Scala Actors communicate with Lift Actors?
At the moment I don't get my project to compile due to some type
mismatch errors but that might also be my lack of understanding
of the different Actor implementations.

Thanks,
ssid

On 22 Okt., 05:37, David Pollak  wrote:
> Folks,
> As the title of this email indicates, there are breaking changes in Lift
> that just got pushed to master.
>
> We've migrated from Scala Actors to Lift Actors and included a series of
> traits that allow Lift to use its own Actors or Akka Actors (or anything
> else that implements that interface.)
>
> The two big changes that you'll have to work with are:
>
>    - Box/Full/Empty/Failure was moved from the lift-util/net.liftweb.util
>    package to the lift-common/net.liftweb.common package.  The reason for this
>    change is that we're going to make the lift-common package a more generic,
>    non-web related package.  It currently contains Box and Actor, but in the
>    future may contain other interfaces that will have concrete implementations
>    outside of Lift.  We moved Box there because Box is richer than Scala's
>    Option class and being able to carry Exceptions around in a Box while still
>    being able to map/flatMap/foreach over a Box (these are unavailable for
>    Scala's Either).  Some we're going to actively promote using Box as a
>    replacement for Option in all Scala apps.  What this means for you is you
>    have to import net.liftweb.common._ in any file that you also import
>    net.liftweb.util.?
>    - Lift no longer support Scala Actors for Comet Actors.  The GenericActor
>    API offers pretty much the same client interface to Lift's Actors, so ! and
>    !? work the same way.  However, there's no link, self, start or exit
>    methods.
>
> Please do an "mvn -U clean install" on your code and run it against the new
> code.  If you have any Comet-related weirdness, please report it
> immediately.  We're planning M7 in 2 weeks, so we've got lots of time to
> iron any kinks out of this code.
>
> Thanks,
>
> David
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics



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

[Jim Barrows]

On Thu, Oct 22, 2009 at 2:27 PM, jlist9  wrote:

>
> > Perl's motto is "There is more then one way to do it."
>
> I remember reading somewhere that part of the the design goal
> of Perl 6 was to make the language "more sane". That says
> it all. For scripting language, I'd stick to Python, whose syntax
> feels natural to me, and to stay sane as much as I can. :-)
>

Eh.  Sanity is overrated :)


>
> > Each brings it's own strengths and weaknesses to the table.
>
> True. But the same could be said if you had 10 ways to start a program.
> You have to balance the downside and the benefit. I personally think
> The confusion of 2 or 3 ways already out-weights the benefit in this
> particular case :-)
>

See my points about noob vs experienced programmer.  Also see:
http://scala-blogs.org/2008/07/application-trait-considered-harmful.html

Also, Application is a trait, so any Object can be an application.  See
multiple reasons :)


> > And Java only needs a main isn't true in web development there is no
> > main.  There is no main if you write an eclipse plugin, and there is no
> main
> > if you use a Swing based framework.  (note if it's just swing, you do.)
>
> In those cases you are not starting a program/process. You are
> only loading a library - your code being the library, the framework being
> the entry point of the process.
>

Ayup.  The application trait is just an entry point in the process...


>
> > Wish I could articulate this better.  Using the for comprehension as an
> > example... it's the way it gets compiled into code.  There is no for loop
> in
> > Scala.  A for comprehension gets boiled down to method calls.  The curly
> > braces get converted into an anonymous function.
> > See
> >
> http://creativekarma.com/ee.php/weblog/comments/the_scala_for_comprehension_from_a_java_perspective/
>
> Thanks for the explanation. I'll try to understand it.
>

Good luck.  I have it bookmarked so I can re-read it regularly :)  Hopefully
you're smarter then I am... :)


>
> > And too few operators leads to a whole lot of words, which leads to a
> whole
> > lot of typing, or a whole lot of ctrl-space completions.  It's a toss up.
> > The wordy way is definitely noob friendly, while the operator way is more
> > expert friendly.
>
> If you are talking about Java, that's true. Python is very concise, though.
> People say if you are not able to do the same thing in 1/10 LoC in Python
> as in Java, you are not coding Python right. I think it's exaggerating a
> little
> bit but it's close. This is probably partially due to the dynamic nature of
> Python..
>

Python's lack of operators vs GREP might have been better :)  GREP is a far
better example of operator conciseness. :)

Java has way too much boiler plate code, and way to many code slingers who
think the JEE Blueprint Patterns are to be followed dogmatically rather then
by need... *SIGH*


>
> > Or, if I may wax metaphorical (and deep into my own opinion)once more...
> who
> > do you think is the better driver, a NASCAR driver or a Prius driver?
> Which
> > is more expensive to learn to do?   Which is more fun? :)
>
> I guess it depends on the goal of driving. NASCAR  is definitely more fun
> but If the goal is to go from point A to B in time, safely and in a
> environment
> friendly way, maybe the Prius driver :-) And I think these are Java
> developers
> that Scala is also trying to appeal to.
>

You answered which is more fun, and analyzed the goals of each.  How about
the which driver is more skilled (ie better)? :)
 We can even add, who has more understanding of what happens to make the car
go? (which of course leads to the question, whose more fuel efficient, the
NASCAR driver who knows the shortest way around a turn, and how to draft? or
the prius driver? ) :)


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: A Critique On Lift

[Jim Barrows]

On Thu, Oct 22, 2009 at 1:29 PM, jlist9  wrote:

>
> Hi David,
>
> Appreciate your reply. It's definitely helpful in clearing some of my
> thoughts,
> as well as in my process of learning Scala down the road. I also think your
> book is very well paced and organization of the content is well thought
> out.
> Great job!
>
> I'd like to explain a little bit where my frustration is coming from
> (and I don't
> want to waste people's time reading further for those who aren't
> interested.)
>
> I come from Java and Python background. When learning these two languages
> I didn't have a problem with the syntax. I think Java's syntax is well
> defined
> although verbose, and Python's is clear and concise. There is a small
> number
> of operators and data types and it's pretty clear which is for what
> purpose.
> "Zen of Python" says it well:
>
> "There should be one-- and preferably only one --obvious way to do it."
>

Except that sometimes, there isn't.  In fact for any non-trivial case, there
can be multiple ways to do anything.
Sorting is an excellent example.  There isn't just one way to sort.  Which
way you do it depends on the data, and your
expectations.


> and I think this reflects well in the language design of Python.
>
> It's also generally discouraged to use too much "black magic" when coding
> in Python so that the code is easier to understand and maintain, although
> Python, being a powerful dynamic language, is very capable of black magics.
>
> These two things helped a lot in my learning of Python. It's a much smaller
> set of syntax to learn and it can be learned in a very short time, maybe
> through
> one or two online tutorials. The rest of it is just libraries, which
> are very rich
> in functionality, but the source code is easy to understand, because of the
> small set of clearly defined elements in the language - syntax and
> data types, etc..
>
> However, I don't feel the same about Scala. In Scala, I often see multiple
> ways
> of doing the same thing, or very similar things, and this is confusing.
>

Tell me about it If you find Scala confusing, never go look at Perl or
Lisp

Perl's motto is "There is more then one way to do it."


>
> For example, there are multiple ways of running a program. You can have a
> script, or an application. To run an application, you can write an "object"
> and
> implement the main method, or you can extend Application class and write
> the code right in the body of the class. It took me a while to figure out
> how
> it works. What's wrong with having only one of them? Python only start as a
> script and Java only need a main method but either way works.
>

Each brings it's own strengths and weaknesses to the table.
And Java only needs a main isn't true in web development there is no
main.  There is no main if you write an eclipse plugin, and there is no main
if you use a Swing based framework.  (note if it's just swing, you do.)


>
> Another example is that in some scenarios ( ) and { } are
> interchangable in Scala
> code, although I haven't figured out in what occasions they are, and
> in what occasions
>
they are not. This puzzles me more because ( ) and { } are the basic
> elements
> in a language and the language allows such flexible usage of them. Although
> I
> think there should be a good reason for this but it still struck me as odd.
>

Wish I could articulate this better.  Using the for comprehension as an
example... it's the way it gets compiled into code.  There is no for loop in
Scala.  A for comprehension gets boiled down to method calls.  The curly
braces get converted into an anonymous function.
See
http://creativekarma.com/ee.php/weblog/comments/the_scala_for_comprehension_from_a_java_perspective/


>
> In contrast to Python's short list of operators, because operators are
> actually functions
> in Scala, it's easy for Scala to have a new operator, or have
> functions that works
> like operators. This is a powerful feature and it is good news for
> people who want to
> create DSLs. However I think a plethora of operators make code much harder
> to
> read before people can make it a habit to convert operators as
> functions in their mind.
>

And too few operators leads to a whole lot of words, which leads to a whole
lot of typing, or a whole lot of ctrl-space completions.  It's a toss up.
The wordy way is definitely noob friendly, while the operator way is more
expert friendly.
Which do you design a language for?  Let me know when that particular
religious war dies down please.
As someone who slings code for a living the less I type the happier I
am. YMMV


>
> To summarize, the more I learn Scala the more I realize how powerful
> it is. Meanwhile,
> I think Scala imposes this mind tweaking that people have to go
> through in learning
> this language, the difficulty that I didn't feel when I learned
> Python, or Java, C or C++.
> I like many of the features provided by Scala but I hope some of the
> things can be
> simpl

[Lift] Re: A Critique On Lift

[Jim Barrows]

On Thu, Oct 22, 2009 at 9:22 AM, David Pollak  wrote:

>
>
> On Thu, Oct 22, 2009 at 9:18 AM, Timothy Perrett 
> wrote:
>
>> David,
>>
>> I think your response was well measured and appropriate. The analogy of
>> linguistics is a good one :-)
>>
>> Without wanting to diverge this thread, can I ask why it is your unhappy
>> with Record? Its been fairly fun to use so far and appears to work well.
>>
>
> I don't like mutable fields.  I don't like manual saving.  Dunno... it's
> hard to articulate... it just feels wrong in my tummy.  Also, I want to be
> clear that I think Marius did a great job of cleaning up some of the
> problems with Mapper when he did Record... my comments are not a negative to
> him... there's just something unsatisfying about the whole approach.
>
> Bet that was less than helpful.
>

I've worked with an OODBMs systems before, and of course ORM.  OODBMs takes
care of the manual saving, and could probably take care of the mutable
fields too.
The problem with OODBMs is that every object has "strings" attached to it to
make the persistence mechanism work.  Even the systems that don't require
you to inherit a special class have these "strings".  The problem is that in
a web based framework, the tags don't have this string.  So you deliver an
unattached field to the browser, then have to reattach it later.  This is
actually uglier then it sounds (or was when I was doing it).  It's the
de-tached vs attached issues that make things entertaining.
However, AJAX/Comet and the other dynamic stuff wasn't around in 2001, and
so we may be able to solve some of those issues.  Whether we can do that and
persist to a RDMS is the real question, and I don't think that will ever be
anything but ugly.  I hope I'm proven wrong.
I think Hibernate and JPA are steps in the right direction.  JPA being a
half-step back from Hibernate.  I think if you could convert the XML to a
real DSL, it would be another step.  Annotations are a step there.  Another
step would be to create an object sans-setters and getters of any kind.
Just magically deal with the internal object state.


>
>>
>> Cheers, Tim
>>
>> On 22 Oct 2009, at 17:04, David Pollak wrote:
>>
>> I've drafted a couple of different versions of a response to this message
>> and they all seem somewhat mean and/or condescending... that is not at all
>> my intent... here's another draft and please read it as acknowledging the
>> challenges you are articulating, but suggesting a different perspective on
>> the issue.
>> Lisp/Scheme/Clojure is syntactically the simplest language around.  Yet,
>> when I look at Clojure code, it to a great degree seems complex to me, even
>> though I know it's not.  I believe this is because the patterns are
>> different than those I've rehearsed through my journey of asm, Basic, C,
>> ObjC, C++, Java, Ruby, and Scala.  Rehearsing a different paradigm is part
>> of making that paradigm part of you.
>>
>> When I studied French in grade school and high school, I was flummoxed and
>> quite angered by gendered nouns.  As a native English speaker, a table is an
>> it, not a she (or he.)  But fluent French speakers make gendered nouns a
>> normal part of the language, and once skilled can use these subtleties with
>> great skill.
>>
>> My 2 year learning curve for Scala can be summed up in the first 4 (or
>> maybe 5) chapters of Beginning Scala.  I sought to present my painful
>> learning curve in < 150 pages that could be reasonably consumed by a Java or
>> Ruby or Python coder in a week or two.  Yeah, it still takes a fair amount
>> of practice, rehearsal, to be proficient, but if someone had led me down the
>> path that I led my readers down, I think my pain-curve would have been 3-4
>> months, not two years.
>>
>> Put a different way, the Programming in Scala folks passed a couple of
>> drafts of the first chapters of their book by me early on.  I think PinS is
>> a tredmendously awesome work, but I objected strongly to the "show
>> imperative first and gently migrate to functional" approach they took.  I
>> thought it did a significant disservice to their readers.  I took the
>> opposite approach in BegSca... the second substantive example covers a broad
>> spectrum of functional programming.
>>
>> So, getting to some of the substance of your post, as Tim pointed out, the
>> "_" is a running joke in Scala-land.  Yep, it's way overloaded.  Every time
>> (and this happened at both Scala Lift Offs) Martin tries to justify the
>> "_"'s use, people roll their eyes.
>>
>> On the other hand, the example that you gave is one of my proudest moments
>> in Lift.  Specifically, I think Mapper is a steaming pile of something.  I
>> am really dissatisfied with it (although we followed the same paradigm with
>> Record and I'm unhappy with that as well... mostly from the mutability
>> standpoint).  On the other hand, the graceful way that Mapper deals with
>> validators (they are functions and they are declared as a List that can be
>> dynamically gen

[Lift] Re: Calling a method from other snippet

[Jim Barrows]

Doesn't emacs already do all three?

Sent on the Now Network™ from my Sprint® BlackBerry

-Original Message-
From: Ross Mellgren 
Date: Wed, 21 Oct 2009 22:18:29 
To: 
Subject: [Lift] Re: Calling a method from other snippet


Screw it, I'll just do all three in emacs. GUIs are for wimps anyway,  
right?

-Ross

On Oct 21, 2009, at 10:03 PM, Naftoli Gugenheim wrote:

>
> How about building an email client into your REPL? ;)
>
> -
> Ross Mellgren wrote:
>
>
> So true. I need a REPL built in to my email client ;-)
>
> -Ross
>
> On Oct 21, 2009, at 9:50 PM, Naftoli Gugenheim wrote:
>
>>
>> That needs to be new SecondSnippet().render or (new
>> SecondSnippet).render
>>
>> -
>> Ross Mellgren wrote:
>>
>>
>> Just call it:
>>
>> class FirstSnippet {
>>def render(ns: NodeSeq): NodeSeq = {
>>bind("foobar", ns,
>> "otherSnippet" -> new SecondSnippet.render _)
>>}
>> }
>>
>> class SecondSnippet {
>>def render(ns: NodeSeq): NodeSeq = hello!
>> }
>>
>> -Ross
>>
>> On Oct 21, 2009, at 7:06 PM, sunanda wrote:
>>
>>>
>>> Hi,
>>> I have a method updateColumn() in ColumnInfo.scala snippet.
>>> I need to call this method form another snippet GridInfo.scala
>>>
>>> How can I do this.
>>>
>>> Sunanda

>>
>>
>>
>>
>>>
>
>
>
>
> >




--~--~-~--~~~---~--~~
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: Menu generated from database?

[Jim Barrows]

On Wed, Oct 21, 2009 at 6:26 AM, philip  wrote:

>
> Hi,
>
> How can I get a Liftweb menu to be generated from database content?
>

The meditative answer is: functions are first class citizens in Scala. :)


>
> Alternatively, can the menu come from a XML datasource? could I load/
> serialize from that?
> Could it change dynamically at any time?
>

//From Bootstrap
 // Build SiteMap
val entries =
  Menu(Loc("Home",   List("index"),"Home")) ::
  Menu(Loc("Create", List("createBusiness"), "Create Business", Hidden))
::
  Nil

LiftRules.setSiteMap(SiteMap(entries:_*))

so you could replace any menu entry in the above with a function call that
returns a single, or list of Menu's.


>
> Thanks, Philip
>
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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 is the default.props in the lift1.1-M6 and the Full method ?

[Jim Barrows]

On Wed, Oct 21, 2009 at 1:48 AM, GA  wrote:

>
> Hello Neil,
>
> the file must be located in src/main/resources/props/default.props
>
> Here you have an example that it is working for us:
>
> db.driver=org.postgresql.Driver
> db.url=jdbc:postgresql://localhost/dbname
> db.user=userName
> db.password=Password
>
> You should create the props directory and the file.
>
> I do not know about the Full method. I also should ask the silly
> question. :-)
>

Look at the Box class.  This works like Scala's Option class, only more
specialized for web development.


>
> I hope this helps.
>
> Cheers,
>
> GA
>
>
>
> On Oct 21, 2009, at 10:24 AM, Neil.Lv wrote:
>
> >
> > Hi all,
> >
> >   Where is the default.props in the lift1.1-M6 whether the file name
> > is defualt.props ?
> >
> >   I see this code in the Boot.scala
> >
> >   ###
> >Props.get("db.driver")
> >  ###
> >
> >   If it uses the default Props, and where is it ?
> >
> >   And i have a silly question about the helper method Full(). What
> > can it do for us?
> >
> >   ###
> > Full(user), Full(pwd)) => DriverManager.getConnection(dbUrl,
> > user, pwd)
> >   ###
> >
> >   Thanks for any information!
> >
> > Cheers,
> >  Neil
> >
> > >
>
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

[Jim Barrows]

On Mon, Oct 19, 2009 at 10:53 AM, Derek Chen-Becker
wrote:

> That's pretty much my take. The whole Java Calendar/Date/Timezone impl is
> poorly designed, hence Joda Time.
>
>  Now I've run into another wall, this time with the TimeSpanBuilder. I
> can't mask the implicits from long/int to TimeSpanBuilder, so I can't define
> the same DSL for things like "3 seconds", etc. I tried to provide an
> implicit conversion from TimeSpan to JodaSpan but that won't cover all of
> the cases and this is feeling increasingly ugly as I add more and more
> layers and implicit defs to work around the old API.
>
> At this point, the only way that this may work is if I create and entirely
> new JodaHelpers object that extends all of the Helpers traits, replacing
> TimeHelpers with my new JodaTimeHelpers trait. This may be the path of least
> pain, but it means two cycles of deprecation: one to deprecate the current
> TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate
> JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this sound
> like a reasonable approach, or is this getting too crazy?
>
>  The other option I thought of is to make a new branch just for this and
> just track master with the branch. The big downside is that this doubles the
> release work to have a Joda Lift and non-Joda Lift.
>
> Thoughts?
>


I'm always on the side of less work, and less clutter.  What about keeping
the old stuff deprecated (and unmaintained) till 1.5 or 2.0, and encouraging
the use of the JodaTimeHelpers in the mean time.  That gives existing code
time to be transitioned to the new stuff..



> Derek
>
>
> On Mon, Oct 19, 2009 at 11:17 AM, rstradling wrote:
>
>>
>> Take my input or vote of confidence with a grain of salt...
>>  I had to use java.util.Calendar recently and noticed some of the
>> issues with it that you mention.  For my case, I created a light
>> wrapper for my use of java.util.Calendar that redefined the relevant
>> statics (Monday, Tuesday, etc) as Scala "enumerations" and then
>> provided some implicit conversions to go from DayOfWeek.Monday to
>> java.util.Calendar.Monday.  My hope is that client code never knows
>> that they are using java.util.Calendar and that they will also get
>> some level of type-safety by using my wrapper.
>>
>>
>> In summary, I do not like the design of java.util.Calendar because of
>> its inconsistencies and think that creating a more consistent way of
>> doing things is a "good thing."
>>
>>
>>
>>
>>
>> On Oct 18, 10:58 am, Derek Chen-Becker  wrote:
>> > OK, I've run into an issue that makes me really uncomfortable.
>> > java.util.Calender is generally 1-based for fields, except for month of
>> > year, which is zero-based. This inconsistency has bled through to the
>> > TimeHelpers API. I can't just change this, because that would break a
>> lot of
>> > code, possibly at runtime. What I would like to do is make a
>> corresponding
>> > set of field accessor methods (day, month, year) in the JodaTimeHelpers
>> > trait that behave just like TimeHelpers, and then I'm building an
>> "extender"
>> > class that will wrap a DateTime to provide functionality very similar to
>> > what Scala Time does (it's mostly pretty simple). The other
>> inconsistency in
>> > the API is that some fields are UTC relative (day, month, year), but
>> others
>> > aren't (currentYear). To address this, I would like to make all of my
>> > extender class methods use the local timezone, and provide a utc method
>> that
>> > will return an extender relative to UTC. That way you could do things
>> like:
>> >
>> > now.days // day of month relative to local timezone
>> > now.utc.days // day of month relative to UTC
>> >
>> > Thoughts?
>> >
>> > Derek
>> >
>> > On Thu, Oct 15, 2009 at 5:18 PM, David Pollak <
>> feeder.of.the.be...@gmail.com
>> >
>> > > wrote:
>> > > I'd prefer not the break the apis without deprecating them first
>> >
>> > > On Thu, Oct 15, 2009 at 4:09 PM, Derek Chen-Becker <
>> dchenbec...@gmail.com>wrote:
>> >
>> > >> Just asking, since I'm looking at bolting a lot of java.util.Date
>> methods
>> > >> onto the innards of TimeHelpers so that the specs pass.
>> >
>> > >> Derek
>> >
>> > > --
>> > > Lift, the simply functional web frameworkhttp://liftweb.net
>> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > > Follow me:http://twitter.com/dpp
>> > > Surf the harmonics
>>
>>
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Are we willing to make a breaking change for Joda Time?

[Jim Barrows]

I've been thinking a lot about the issue of backwards compatibility, and the
trade off with good architecture.
I've come to the conclusion that the only real answer is that you have to
take each instance on a case by case basis and ask yourself this question:
"Do you want to write a thunking layer between the better architecture and
worse architecture for the next 20 years, and what is that going to cost the
sanity of everyone who comes after?"
I think in this case, given the mind numbingly idiotic date and calendar
handling in java, I would answer "Dear God, I'd rather dive into a pool
filled with double edged razor blades then ever have to deal java.util.Date
or Calendar again".
I say this because Date and Calendar have been broken since 1.0.1, when I
started working with Java.  Sun/Oracle obviously has no intention of giving
us anything better, so it's up to us to do it.  Doing it now, while the
existing code base of lift is small, is much better then doing it on down
the line.  Ideally I'd like to see this abomination fixed at the Scala
level, rather then the Lift level, but I'll take my sanity savers where I
can.

On Mon, Oct 19, 2009 at 10:17 AM, rstradling wrote:

>
> Take my input or vote of confidence with a grain of salt...
>  I had to use java.util.Calendar recently and noticed some of the
> issues with it that you mention.  For my case, I created a light
> wrapper for my use of java.util.Calendar that redefined the relevant
> statics (Monday, Tuesday, etc) as Scala "enumerations" and then
> provided some implicit conversions to go from DayOfWeek.Monday to
> java.util.Calendar.Monday.  My hope is that client code never knows
> that they are using java.util.Calendar and that they will also get
> some level of type-safety by using my wrapper.
>
>
> In summary, I do not like the design of java.util.Calendar because of
> its inconsistencies and think that creating a more consistent way of
> doing things is a "good thing."
>
>
>
>
>
> On Oct 18, 10:58 am, Derek Chen-Becker  wrote:
> > OK, I've run into an issue that makes me really uncomfortable.
> > java.util.Calender is generally 1-based for fields, except for month of
> > year, which is zero-based. This inconsistency has bled through to the
> > TimeHelpers API. I can't just change this, because that would break a lot
> of
> > code, possibly at runtime. What I would like to do is make a
> corresponding
> > set of field accessor methods (day, month, year) in the JodaTimeHelpers
> > trait that behave just like TimeHelpers, and then I'm building an
> "extender"
> > class that will wrap a DateTime to provide functionality very similar to
> > what Scala Time does (it's mostly pretty simple). The other inconsistency
> in
> > the API is that some fields are UTC relative (day, month, year), but
> others
> > aren't (currentYear). To address this, I would like to make all of my
> > extender class methods use the local timezone, and provide a utc method
> that
> > will return an extender relative to UTC. That way you could do things
> like:
> >
> > now.days // day of month relative to local timezone
> > now.utc.days // day of month relative to UTC
> >
> > Thoughts?
> >
> > Derek
> >
> > On Thu, Oct 15, 2009 at 5:18 PM, David Pollak <
> feeder.of.the.be...@gmail.com
> >
> > > wrote:
> > > I'd prefer not the break the apis without deprecating them first
> >
> > > On Thu, Oct 15, 2009 at 4:09 PM, Derek Chen-Becker <
> dchenbec...@gmail.com>wrote:
> >
> > >> Just asking, since I'm looking at bolting a lot of java.util.Date
> methods
> > >> onto the innards of TimeHelpers so that the specs pass.
> >
> > >> Derek
> >
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Surf the harmonics
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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] Having trouble understanding SessionVar[Box[MyClass]] and how to use it.

[Jim Barrows]

Here's a snippet:

object parentOrganization extends SessionVar[Box[Organization]](Empty)

  def create(xhtml: NodeSeq): NodeSeq = {
var name: String = ""
def processAdd() = {
  if (name.isEmpty)
S.error("Please provide a name")
  else {
val organization = new Organization()
organization.setName(name)
organization.addPartyRole(new ParentOrganization());
organization.addPartyRole(new InternalOrganization());
Model.em.getTransaction().begin();
Model.em.persist(organization)
Model.em.getTransaction().commit();

//Now that I've got the parent organization, and it's going to be heavily
used and modified, I'd like easy access to it. So how do I set it?
parentOrganization(organization)

Then once I've set it I should be able to do something like:
org match {
  case Empty=>S.redirectTo("/eeek")
  case Full => full.is.getName() //To access the underlying organizatino
object I think
}

I think but it's not working like I thought.  If someone could give the
right code, and an explanation of what's going on, I'd appreciate it!


-- 
James A Barrows

--~--~-~--~~~---~--~~
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] [Sorta Not Related] Ummm.. at the risk of crashing my browser........

[Jim Barrows]

Who wants a wave invite?
Not sure how long Google will take to process them.. but I have some!

I just added the lifehack list to my wave account, and I think firefox
nearly died.  Quite amusing.. in many ways

-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Cannot get YUI text editor to work from Liftweb in Firefox or Google Chrome, works in IE

[Jim Barrows]

Both of the links work just fine on my firefox 3.0.14 on Ubuntu.

On Tue, Oct 13, 2009 at 11:44 PM, philip  wrote:

>
> Hi,
>
> I know this is not specific to liftweb, but I cannot get the YUI rich
> text editor to work in Firefox or Google Chrome from my Liftweb.
>
> This example:
> http://developer.yahoo.com/yui/examples/editor/editor_adv_editor_clean.html
> http://developer.yahoo.com/yui/examples/editor/editor_adv_editor.html
>
> It does not make any sense, it runs fine in Internet explorer 8, but
> does not work in Firefox or Google Chrome.
> Is it some javascript from Liftweb interfering with YUI?
>
> Has anyone had any success or failure with this case?
>
> Thanks, Philip
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Don't shoot the non-XML messenger ...

[Jim Barrows]

To which I say everybody hamster dance for
joy!

On Tue, Oct 13, 2009 at 7:21 PM, David Pollak  wrote:

> You are banned from this group.
>
> On Tue, Oct 13, 2009 at 6:24 PM, Aule  wrote:
>
>>
>> Bryan
>>
>> Been there, tried that.
>> Oh - the mime type is "text/vnd.curl"
>>
>> Btw, actually a threat has been conveyed to me at mail.google.com and
>> I have protested to Google
>>
>> I can't imagine Dave Hansen or MArtin Odersky or Bill Venners or Lex
>> Spoon sending me a threat, but so it goes ...
>>
>> At least I will not get 4 years in an Egyptian prison for insulting
>> Randy's Alma Mater (Madison).
>>
>> Oh Randy.  I read my Paul Valéry in the original.  www.hsinfosystems.com
>> is missing the accent on his surname.
>>
>> Lift is not Scala; I will continue to recommend Scala.
>>
>> For me, the jury on Lift is not yet in.  When some sycophants of
>> Seaside got, nasty, I did not walk away from Seaside, warts and all.
>>
>> R
>>
>> On Oct 13, 8:10 pm, Bryan  wrote:
>> > Hi Aule,
>> >
>> > > I am still looking to see if I over-looked somewhere on the web where
>> > > there is a 1.0.2 Boot.scala
>> >
>> > >   1) showing unambiguously how to flip the default Content-Type
>> > >   2) and having, in fact, the intended effect
>> >
>> > >  as I now know from a few trials over a few hours that this is not as
>> > > simple as some web posts present.
>> >
>> > I have not had a need for this, so I had to search some "web posts" to
>> > find the answer.  Quckly, I found the following snippet:
>> >
>> > LiftRules.determineContentType = {
>> >   case _ => "text/curl"
>> >
>> > }
>> >
>> > I have not verified this, so please let us know if it does not help.
>> >
>> > > Were it trivial, I had not mocked a framework, and you, Mr. Pollock,
>> > > had not raged.
>> >
>> > From my readings, Mr. Pollak has yet to show any rage.
>> >
>> > --Bryan
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >
>


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Don't shoot the non-XML messenger ...

[Jim Barrows]

On Tue, Oct 13, 2009 at 4:37 PM, David Pollak  wrote:
*snip*

>
> If you want some help, ask and please be polite (at this point, you'll need
> an extra dose of polite to get any more response from me).  If you want to
> tell us how stupid or clueless or whatever we are, you can go somewhere
> else.  Or, as one member of the Lift community communicated to me "I think
> you should find a happy lift user wherever it is that Aule lives and ask
> them to go to his house and give him a nice, sanctimonious, punch to the
> face."
>
>
Yes, I'm sure that David and the community member cited know that violence
is not the answer... I'm also sure they got it wrong on purpose.


-- 
James A Barrows

--~--~-~--~~~---~--~~
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: Question about the TreeViewDemo in the lift widgets section of the Exploring LIft pdf

[Jim Barrows]

Tracked this down to a missing import statement:
import JE._

You can recreate this by removing this import in the
TreeViewDemo.scala (http://github.com/dpp/liftweb/blob/master/lift-
widgets/src/test/scala/webapptest/snippet/TreeViewDemo.scala) file,
and compile it.

On Oct 11, 9:34 pm, Jim Barrows  wrote:
> I've interpreted the demo as the code below.  However, I get this
> exception when I compile:
> /snippet/TreeViewDemo.scala:14: error: not found: value JsObj
>     TreeView("example", JsObj("animated"->90))
>
> I'm not sure what I'm doing wrong I'd appreciate any help.
>
> Here's the code:
> package com.nsfw.bmp.businesssetup.snippet
>
> import _root_.net.liftweb.http._
> import S._
> import _root_.net.liftweb.http.js.JsObj
> import _root_.net.liftweb.util._
> import Helpers._
> import _root_.net.liftweb.widgets.tree._
> import _root_.scala.xml._
>
> class TreeViewDemo {
>
>   def render(xhtml:Group):NodeSeq={
>     TreeView("example", JsObj(("animated"->90)))
>   }
>
>   def loadTree() = {
>     Tree("No Children")::
>       Tree("one static child", Tree("Lone child") :: Nil) ::
>      Tree("Dynamic node", "myDynamic", true) :: Nil
>   }
>
>   def loadNode(id:String) : List[Tree] = id match {
>     case "myDyanmic" =>
>       Tree("Child one") ::
>         Tree("Child two") ::Nil
>     case _ => Nil
>     }
>
> }

--~--~-~--~~~---~--~~
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] Question about the TreeViewDemo in the lift widgets section of the Exploring LIft pdf

[Jim Barrows]

I've interpreted the demo as the code below.  However, I get this
exception when I compile:
/snippet/TreeViewDemo.scala:14: error: not found: value JsObj
TreeView("example", JsObj("animated"->90))

I'm not sure what I'm doing wrong I'd appreciate any help.

Here's the code:
package com.nsfw.bmp.businesssetup.snippet

import _root_.net.liftweb.http._
import S._
import _root_.net.liftweb.http.js.JsObj
import _root_.net.liftweb.util._
import Helpers._
import _root_.net.liftweb.widgets.tree._
import _root_.scala.xml._

class TreeViewDemo {

  def render(xhtml:Group):NodeSeq={
TreeView("example", JsObj(("animated"->90)))
  }

  def loadTree() = {
Tree("No Children")::
  Tree("one static child", Tree("Lone child") :: Nil) ::
 Tree("Dynamic node", "myDynamic", true) :: Nil
  }

  def loadNode(id:String) : List[Tree] = id match {
case "myDyanmic" =>
  Tree("Child one") ::
Tree("Child two") ::Nil
case _ => Nil
}

}

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

[Lift] Re: lift nearly inaccessible for newby

[Jim Barrows]

On Oct 6, 12:52 am, Stefan Langer  wrote:
> Not ment as a offence but you are in way over your head!

While I agree. Linus Torvalds was in much the same place.  He has
to somewhere :)

> A couple of things:
> 1. You say you are a non-programmer but I assume you do understand Scala? Or
> else it is pointless to use Lift as it is based on the Scala language and
> relies heavily on its features. Knowledge of Java is also a plus cause some
> of the libs are not available in Scala but only in Java and it is better to
> know Java in order to understand the libraries.
> 2. You do have experience with websites? Complex web applications? If not
> then I suggest you start by doing a simple static page for your design to
> get to know the technics you are trying to use or you get yourself a
> programmer/webdesinger to do it for you. If you are not willing to learn
> about the technical details you will get in big trouble later on and I mean
> trouble that can actually cost you money.
> 3. If the above points do not seem valid for you then please get
> professional help
> 4. If you are not scared by the above points and you are willing to invest
> then I suggest getting some example code and starting to disect that.
> Take a look athttp://github.com/tjweir/pocketchangeappwhich is a complete
> demo app in lift
> and take a look athttp://github.com/tjweir/liftbookfor a liftbook that is
> available freely.
>
> Regards and good luck on your project
>
> Stefan
>
> 2009/10/5 koveen 
>
>
>
> > hi Naftoli,
>
> > thanks for your interest.
>
> > On Oct 5, 10:50 pm, Naftoli Gugenheim  wrote:
> > > Being a non-programmer, and additionally not having a Java background,
> > > which framework are you comparing Lift to when you say it's not easy?
> > > :)
>
> > First I read a book about rails, explaining things from the start, I
> > did watch quite a lot of nice video's on the web explaining some basic
> > tricks with Rails. I think it is a system that is easy to start with
> > but I became nervous about recurring issues about scaling, the
> > integration of Rails and Merb and had the idea, maybe wrong, that it
> > was a system too much in transition.
>
> > I read part of the tutorial of Lift, installed it on my computer using
> > Maven, but in a way I got lost.
>
> > Then I partially read a book about Wicket. I like the system very
> > much, especially one trick exited me: the Ajaxfallbacklink in which a
> > link worked in a simple way when javasript is disabled , but at the
> > same time has some Ajax functionality when Javascript is enabled on
> > the users system. I liked this feature very much, but the integration
> > with a database is not an integral part of the Wicket-system and can
> > be acquired via a Wicket-Spring-Hibernate combination. This seemed too
> > much for me to get into as a starter.
>
> > That's how I came back to Lift. I need a stable database-connection.
> > You need one when you hope that people will be paying some, even
> > small, amount of money for your service.
>
> > > Can you clarify: Is this going to be a site, or a back end to a mobile
> > > app that sits on the phone?
>
> > I just want to make a site
>
> > But I hope it is clear I am not here to criticise anybody, it is just
> > that often I feel this system is way over my head. Maybe that will
> > change.
>
> > thanks
>
> > Ko
>
> > > On Mon, Oct 5, 2009 at 2:32 PM, koveen  wrote:
>
> > > > Hi,
>
> > > > Being a no-programmer and having no Java-background
> > > > I'd like to have mentioned that Lift really isn't an easy framework.
> > > > Having said that, I will try to read my way into this system and try
> > > > to solve the problems I encounter.
>
> > > > I have one question.
>
> > > > I would like to establish a login method where a visitor of my site
> > > > (to be) could be accepted as a valid user, based on the info the
> > > > server receives when the visitor enters the site.
>
> > > > In my case it will be a site for mobile phones and some mobile phone
> > > > operators will provide me with the telephone-number of the user once
> > > > she enters. Once a user has paid for the service,  this number alone
> > > > should be enough to make the visitior into a valid user. Without
> > > > needing to log in.
>
> > > > I have read the following on:http://demo.liftweb.net/ws
>
> > > > t's easy to "dispatch" incoming HTTP requests.
> > > > In your "Boot" class create a PartialFunction
> > > > that matches a pattern related to the incoming request and
> > > > then create a short-lived controller to service the request.
>
> > > > This code matches all the requests to "/webservices/" and
> > > > assigns the stuff in '' to the variable c.  Then
> > > > the code attempts to find a public method with that name on
> > > > the controller.  If the method exists, it's invoked and Lift
> > > > processes the result.
>
> > > > I assume I will have to write my own  public method and place it
> > > > where??? in the direcory webservices.?
>
> > > > M

[Lift] Re: Need two classes to inherit from one model, database design and view issues

[Jim Barrows]

On Oct 2, 7:55 pm, Dave  wrote:
> Hi all-
>
> I posted this on stackoverflow but I figure its probably relevant here
> too.  I checked out the post with David and Steve Yen corresponding
> but I am still at a loss and am curious if any progress has been made
> in this direction.  So, here goes.  I am creating a website which will
> need two types of users: students and providers. In a traditional java
> setting I would create a user class (or interface) and then create two
> classes which inherited from the user. Is this the best course in
> scala too, using the "extends" and "with" modifiers? If that is indeed
> the best way (which I suspect it is), what the best way to map this in
> the DB? Would it be best to keep a "type" column and then have it set
> to one or the other?  Etc.

A student is not a kind of user, nor is a provider.  They are roles
that a user plays in your system.
While your business rules may state that this is not possible, it is
possible in the real world.  That's what's best to model, since
business rules can change quite easily.
I can even make an argument that Person has user as role, and that
there are two types of users.

>
> The second question is how to work with the view. The display will be
> very different depending on which type of user one is and so I figure
> there will be some serious routing logic involved or at least logic
> built into snippets in the view.

Why not use 3 directories, one for common stuff, one for the provider
and one for the student.
Reduces the number of if statements that way.

>
> I guess the overarching question is: Is there a "preferred" way to go
> about doing this (like a recipe in rails or some such), or am I kind
> of out on my own?
>
> Thanks

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