[Lift] Re: lift-tag discussion

[marius d.]

Ok I have a first draft implementation for #1 above and I'll check it
in soon in wip-marius-dom-optimizations branch. I need to run more
tests on it before putting it into master.

Br's,
Marius

On May 25, 1:31 pm, "marius d."  wrote:
> No performance implications especially since built-in snippets are
> objects and invoked non reflectively. It's just that the way these two
> artifacts are processed right now it is not by the means of snippets
> but buried deeply into surround snippet processing.
>
> Thanks guys for your thoughts. Hopefully are people would feel the
> same.
>
> Br's,
> Marius
>
> On May 25, 12:44 pm, Timothy Perrett  wrote:
>
> > +1 for option 1... seems to make the most sense given our current
> > infrastructure.
>
> > What would be the benifit of keeping lift tags around longer term? Are
> > there any performance implications using snippets rather than tags?
> > (shouldnt be, but just need to explore this)
>
> > Cheers, Tim
>
> > On May 25, 10:11 am, Heiko Seeberger 
> > wrote:
>
> > > From a user's perspective lift-tag feels odd => I prefer version 1
> > > Heiko
>
> > > 2009/5/25 Marius 
>
> > > > Dear all,
>
> > > > As you may have noticed recently lift:bind and lift:with-param has
> > > > been deprecated in favor of lift-tag:bind and lift-tag:with-param. The
> > > > rationale was that the syntax for these two constructs was similar
> > > > with a snippet invocation where in fact the two are not snippets. so
> > > > lift-tag distinguishes between snippets invocation and the tags
> > > > processing (which in this cases happens inside of surround
> > > > processing).
>
> > > > I did this deprecations (based on public list discussions) but I'm not
> > > > thrilled about it. I don't know what it is but something is just not
> > > > there (really weird ...).
>
> > > > Now what options do we really have?
>
> > > > 1. Make lift:bind and lift:with-param to be real snippets. That should
> > > > be feasible but requires a bit of changes (transparent to the
> > > > user) ... this would lead to un-deprecation of current deprecations :)
> > > > 2. Suggest some other naming convention or just live with lift-tag
> > > > prefix
> > > > 3. Other thoughts?
>
> > > > Br's,
> > > > Marius
>
> > > --
> > > My blog: heikoseeberger.name
> > > Follow me: twitter.com/hseeberger
> > > OSGi on Scala:www.scalamodules.org
> > > Lift, the simply functional web framework: liftweb.net
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Giving an Actor access to S

[marius d.]

Well and S object is initiated but in an asynchronous operation you
wont really have request information cause you are beyond a request
scope. Some things from S maybe available at that time.

Br's,
Marius

On May 26, 1:42 am, Timothy Perrett  wrote:
> My understanding was always that CometActor's "faked" S so its usage
> was fairly transparent of course, thats specific to CometActors
> and wont wash with a normal scala.actor.Actor etc
>
> Cheers, Tim
>
> On May 25, 10:01 pm, "marius d."  wrote:
>
> > CometActors are asynchronous components that live beyond the scope of
> > a given request. From a CometActor you can have access to LiftSession
> > or SessionVars meaning that you could potentially "store" the "last-
> > seen" from the last request host name in a SessionVar an then access
> > it anytime from your actor.
>
> > Not sure why you need the hostName from inside an actor but you know
> > best what application you are building.
>
> > Br's,
> > Marius
>
> > On May 25, 9:39 pm, Bryan  wrote:
>
> > > How can I give an Actor access to S?  I need this for adding results
> > > to a SessionVar of a HashMap.
>
> > > If I call show() directly, then I see "localhost" logged.  If I call
> > > show() from within an actor, then it logs "nowhere_123.com":
> > > listener ! 'show.
>
> > > val listener: Actor = actor {
> > >   loop {
> > >     react {
> > >       case 'show => show()
> > >     }
> > >   }
>
> > > }
>
> > > def show() {
> > >   Log.info("show's host name: " + S.hostName)
>
> > > }
--~--~-~--~~~---~--~~
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: help with JPA annotation?

[John D. Heintz]

Hello Greg,

What is the type of ListVariableExpr? Does Hibernate recognize that as
a java.util.collection?

My guess is that you need to change that type to a List
for Hibernate to do the "right thing".

That's probably not something you want to do, the alternative would be
to implement a UserType to customize the Hibernate mapping process. I
don't actually know how that would work with a collection type, but I
suspect some strange incantations would work.

Hope this helps,
John Heintz

On Mon, May 25, 2009 at 5:42 PM, Meredith Gregory
 wrote:
> All,
>
> Below are the contents of three classfiles. The first and second generated
> by BNFC from the grammar here. The second is a subclass generated from the
> first to provide persistence to the abstract syntax. My procedure is working
> for everything but those classes that contain collections. The call to
> hibernate via the maven-hibernate-plugin is generating the following error.
>
> [INFO]
> 
> [ERROR] FATAL ERROR
> [INFO]
> 
> [INFO] org.hibernate.AnnotationException: Illegal attempt to map a non
> collection as a @OneToMany, @ManyToMany or @CollectionOfElements:
> com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
> [INFO]
> 
> [INFO] Trace
> javax.persistence.PersistenceException: org.hibernate.AnnotationException:
> Illegal attempt to map a non collection as a @OneToMany, @ManyToMany or
> @CollectionOfElements:
> com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
>     at
> org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:247)
>     at
> org.codehaus.mojo.hibernate3.configuration.JPAComponentConfiguration.createConfiguration(JPAComponentConfiguration.java:26)
> ...
>
> However, as the contents of the second class indicate, the member is clearly
> a collection. Is it that hibernate can't deal with subclasses of
> collections?
>
> Best wishes,
>
> --greg
>
>
> // class generated for abstractions
> package com.biosimilarity.reflection.model.rlambda.Absyn; // Java Package
> generated by the BNF Converter.
>
> public class Abstraction extends Expression {
>   public final ListVariableExpr listvariableexpr_;
>   public final Expression expression_;
>
>   public Abstraction(ListVariableExpr p1, Expression p2) { listvariableexpr_
> = p1; expression_ = p2; }
>
>   public  R
> accept(com.biosimilarity.reflection.model.rlambda.Absyn.Expression.Visitor
> v, A arg) { return v.visit(this, arg); }
>
>   public boolean equals(Object o) {
>     if (this == o) return true;
>     if (o instanceof
> com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction) {
>   com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction x =
> (com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction)o;
>   return this.listvariableexpr_.equals(x.listvariableexpr_) &&
> this.expression_.equals(x.expression_);
>     }
>     return false;
>   }
>
>   public int hashCode() {
>     return
> 37*(this.listvariableexpr_.hashCode())+this.expression_.hashCode();
>   }
>
>
> }
>
> // container class generated to hold lists of variables
> package com.biosimilarity.reflection.model.rlambda.Absyn; // Java Package
> generated by the BNF Converter.
>
> public class ListVariableExpr extends java.util.LinkedList {
> }
>
>
> // Generated by stockholm to add persistence to abstraction class
>
> package com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql;
>
> import javax.persistence.CascadeType;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.FetchType;
> import javax.persistence.Id;
> import javax.persistence.OneToMany;
> import javax.persistence.Table;
> import javax.persistence.UniqueConstraint;
> import java.util.Date;
> import java.util.HashSet;
> import java.util.Set;
> import java.util.Iterator;
> import java.net.URI;
> import com.biosimilarity.reflection.model.rlambda.Absyn.*;
> import com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.*;
>
> @Entity
> @Table(name = "Abstraction_table", catalog = "rlambda_production",
> uniqueConstraints = { @UniqueConstraint(columnNames = "uuid") })
> public class AbstractionResource extends Abstraction {
>
>     private String uuid;
>
>     private String id;
>
>     public AbstractionResource(ListVariableExpr listvariableexpr_,
> Expression expression_) {
>     super(listvariableexpr_, expression_);
>     }
>
>     @Id
>     @Column(name = "uuid", unique = true, nullable = false, insertable =
> true, updatable = true)
>     public String getUuid() {
>     return this.uuid;
>     }
>
>     public void setUuid(String id) {
>     this.uuid = id;
>     }
>
>     @Id
>     @Column(name = "id", unique = true, nullable = false, inse

[Lift] Re: help with JPA annotation?

[Meredith Gregory]

All,

Based on some web documentation i found for the OneToMany annotation, i
modified my compiler's output to generate

@OneToMany(cascade = { CascadeType.ALL }, fetch = FetchType.LAZY, mappedBy =
"abstractionResource", targetEntity = VariableExpr.class)
public ListVariableExpr getListvariableexpr_() {
return this.listvariableexpr_;
}

instead of

@OneToMany(cascade = { CascadeType.ALL }, fetch = FetchType.LAZY, mappedBy =
"AbstractionResource")
public ListVariableExpr getListvariableexpr_() {
return this.listvariableexpr_;
}

and i still get the same error

16:44:08,780  INFO org.hibernate.cfg.annotations.EntityBinder - Bind entity
com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource
on table Abstraction_table
[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] org.hibernate.AnnotationException: Illegal attempt to map a non
collection as a @OneToMany, @ManyToMany or @CollectionOfElements:
com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
[INFO]

[INFO] Trace
javax.persistence.PersistenceException: org.hibernate.AnnotationException:
Illegal attempt to map a non collection as a @OneToMany, @ManyToMany or
@CollectionOfElements:
com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
at
org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:247)
at
org.codehaus.mojo.hibernate3.configuration.JPAComponentConfiguration.createConfiguration(JPAComponentConfiguration.java:26)

...

Best wishes,

--greg

On Mon, May 25, 2009 at 3:42 PM, Meredith Gregory
wrote:

> All,
>
> Below are the contents of three classfiles. The first and second generated
> by BNFC from the grammar 
> here.
> The second is a subclass generated from the first to provide persistence to
> the abstract syntax. My procedure is working for everything but those
> classes that contain collections. The call to hibernate via the
> maven-hibernate-plugin is generating the following error.
>
> [INFO]
> 
> [ERROR] FATAL ERROR
> [INFO]
> 
> [INFO] org.hibernate.AnnotationException: Illegal attempt to map a non
> collection as a @OneToMany, @ManyToMany or @CollectionOfElements:
> com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
> [INFO]
> 
> [INFO] Trace
> javax.persistence.PersistenceException: org.hibernate.AnnotationException:
> Illegal attempt to map a non collection as a @OneToMany, @ManyToMany or
> @CollectionOfElements:
> com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
> at
> org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:247)
> at
> org.codehaus.mojo.hibernate3.configuration.JPAComponentConfiguration.createConfiguration(JPAComponentConfiguration.java:26)
> ...
>
> However, as the contents of the second class indicate, the member is
> clearly a collection. Is it that hibernate can't deal with subclasses of
> collections?
>
> Best wishes,
>
> --greg
>
>
> // class generated for abstractions
> package com.biosimilarity.reflection.model.rlambda.Absyn; // Java Package
> generated by the BNF Converter.
>
> public class Abstraction extends Expression {
>   public final ListVariableExpr listvariableexpr_;
>   public final Expression expression_;
>
>   public Abstraction(ListVariableExpr p1, Expression p2) {
> listvariableexpr_ = p1; expression_ = p2; }
>
>   public  R
> accept(com.biosimilarity.reflection.model.rlambda.Absyn.Expression.Visitor
> v, A arg) { return v.visit(this, arg); }
>
>   public boolean equals(Object o) {
> if (this == o) return true;
> if (o instanceof
> com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction) {
>   com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction x =
> (com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction)o;
>   return this.listvariableexpr_.equals(x.listvariableexpr_) &&
> this.expression_.equals(x.expression_);
> }
> return false;
>   }
>
>   public int hashCode() {
> return
> 37*(this.listvariableexpr_.hashCode())+this.expression_.hashCode();
>   }
>
>
> }
>
> // container class generated to hold lists of variables
> package com.biosimilarity.reflection.model.rlambda.Absyn; // Java Package
> generated by the BNF Converter.
>
> public class ListVariableExpr extends java.util.LinkedList {
> }
>
>
> // Generated by stockholm 

[Lift] Re: The new LiftActor code is live

[Timothy Perrett]

One other thought about this code - the AMQP module uses a long lived
actor to manage its RabbitMQ connection, is this likely to suffer the
same memory leaks as other parts of Lift?

If so, should I consider moving it to the new lift specific actor
implementation?

Cheers, Tim

On May 24, 8:44 pm, "marius d."  wrote:
> From all your notes it seems that EPFL is reluctant to correct these
> problems (at least not soon enough)... which I can't seam to
> understand why since Scala Actors have always been a strong factor of
> attracting people to Scala even if actors are not part of the language
> per se, but a library.
>
> I'm not against at all of having LiftActor-s especially if we're
> getting:
>
> - Similar API constructs (to minimize impact on the existent code and
> after a brief look on the new code we're pretty much there)
> - The same scalability
> - Safer concurrency
>
> ... we'll just have to maintain it and potentially evolve it.
>
> P.S. This will probably raise some questions from folks that want to
> adopt Lift.
>
> Br's,
> Marius
>
> On May 24, 8:56 pm, David Pollak 
> wrote:
>
>
>
> > On Sun, May 24, 2009 at 1:46 AM, marius d.  wrote:
>
> > > I'm wondering maybe it would be good to abstract the actors in Lift
> > > such that when Scala Actors are in a better shape we could just switch
> > > the implementation back to Scala Actors with very little Lift code
> > > changes.
>
> > I originally put Lift on top of Scala's Actors because they were very well
> > written (along with mathematical proofs that there were no deadlocks.)
> > Sometime over the last year, the Scala Actor libraries have devolved
> > materially and there seems to be reluctance to address these devolutions
> > (see the discussion around defect 2009.)  While I don't want to be in the
> > business of maintaining code that's not Lift-specific, we have a lot of code
> > that's not Lift-specific (see lift-util).  In order to go back to Scala's
> > Actor library, I would have to see some significant change of attitude about
> > the seriousness of the Actor-related defects  (yes, this is a change from
> > yesterday's position, but the discussions around #2009 are extremely
> > disheartening to me... anything less than "this is a high priority defect
> > that we'll fix ASAP" is the wrong answer.)   And I've spent more time
> > writing English around this issue this week alone than writing code to
> > rectify this issue, and I've been writing English and Scala (workarounds)
> > related to this issue for 6 months.
>
> > When 200 lines of code solve the problem, I don't see the value of sitting
> > on someone else's library and cajoling them into fixing material defects
> > (e.g., concurrency guarantees and memory leaks.)
>
> > > Br's,
> > > Marius
>
> > > On May 24, 2:26 am, David Pollak 
> > > wrote:
> > > > Folks,
>
> > > > The new LiftActor-based Lift is live in the new_actor branch in the
> > > > repository.
>
> > > > I'm running the new code onhttp://demo.liftweb.netIfall goes well,
> > > I'll
> > > > cut the main Lift branch over to the new code on Wednesday.
>
> > > > Thanks,
>
> > > > David
>
> > > > --
> > > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > > Follow me:http://twitter.com/dpp
> > > > Git some:http://github.com/dpp
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Giving an Actor access to S

[Timothy Perrett]

My understanding was always that CometActor's "faked" S so its usage
was fairly transparent of course, thats specific to CometActors
and wont wash with a normal scala.actor.Actor etc

Cheers, Tim

On May 25, 10:01 pm, "marius d."  wrote:
> CometActors are asynchronous components that live beyond the scope of
> a given request. From a CometActor you can have access to LiftSession
> or SessionVars meaning that you could potentially "store" the "last-
> seen" from the last request host name in a SessionVar an then access
> it anytime from your actor.
>
> Not sure why you need the hostName from inside an actor but you know
> best what application you are building.
>
> Br's,
> Marius
>
> On May 25, 9:39 pm, Bryan  wrote:
>
>
>
> > How can I give an Actor access to S?  I need this for adding results
> > to a SessionVar of a HashMap.
>
> > If I call show() directly, then I see "localhost" logged.  If I call
> > show() from within an actor, then it logs "nowhere_123.com":
> > listener ! 'show.
>
> > val listener: Actor = actor {
> >   loop {
> >     react {
> >       case 'show => show()
> >     }
> >   }
>
> > }
>
> > def show() {
> >   Log.info("show's host name: " + S.hostName)
>
> > }
--~--~-~--~~~---~--~~
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] help with JPA annotation?

[Meredith Gregory]

All,

Below are the contents of three classfiles. The first and second generated
by BNFC from the grammar
here.
The second is a subclass generated from the first to provide persistence to
the abstract syntax. My procedure is working for everything but those
classes that contain collections. The call to hibernate via the
maven-hibernate-plugin is generating the following error.

[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] org.hibernate.AnnotationException: Illegal attempt to map a non
collection as a @OneToMany, @ManyToMany or @CollectionOfElements:
com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
[INFO]

[INFO] Trace
javax.persistence.PersistenceException: org.hibernate.AnnotationException:
Illegal attempt to map a non collection as a @OneToMany, @ManyToMany or
@CollectionOfElements:
com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.AbstractionResource.listvariableexpr_
at
org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:247)
at
org.codehaus.mojo.hibernate3.configuration.JPAComponentConfiguration.createConfiguration(JPAComponentConfiguration.java:26)
...

However, as the contents of the second class indicate, the member is clearly
a collection. Is it that hibernate can't deal with subclasses of
collections?

Best wishes,

--greg


// class generated for abstractions
package com.biosimilarity.reflection.model.rlambda.Absyn; // Java Package
generated by the BNF Converter.

public class Abstraction extends Expression {
  public final ListVariableExpr listvariableexpr_;
  public final Expression expression_;

  public Abstraction(ListVariableExpr p1, Expression p2) { listvariableexpr_
= p1; expression_ = p2; }

  public  R
accept(com.biosimilarity.reflection.model.rlambda.Absyn.Expression.Visitor
v, A arg) { return v.visit(this, arg); }

  public boolean equals(Object o) {
if (this == o) return true;
if (o instanceof
com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction) {
  com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction x =
(com.biosimilarity.reflection.model.rlambda.Absyn.Abstraction)o;
  return this.listvariableexpr_.equals(x.listvariableexpr_) &&
this.expression_.equals(x.expression_);
}
return false;
  }

  public int hashCode() {
return
37*(this.listvariableexpr_.hashCode())+this.expression_.hashCode();
  }


}

// container class generated to hold lists of variables
package com.biosimilarity.reflection.model.rlambda.Absyn; // Java Package
generated by the BNF Converter.

public class ListVariableExpr extends java.util.LinkedList {
}


// Generated by stockholm to add persistence to abstraction class

package com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql;

import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.FetchType;
import javax.persistence.Id;
import javax.persistence.OneToMany;
import javax.persistence.Table;
import javax.persistence.UniqueConstraint;
import java.util.Date;
import java.util.HashSet;
import java.util.Set;
import java.util.Iterator;
import java.net.URI;
import com.biosimilarity.reflection.model.rlambda.Absyn.*;
import com.biosimilarity.reflection.model.rlambda.Absyn.persistence.sql.*;

@Entity
@Table(name = "Abstraction_table", catalog = "rlambda_production",
uniqueConstraints = { @UniqueConstraint(columnNames = "uuid") })
public class AbstractionResource extends Abstraction {

private String uuid;

private String id;

public AbstractionResource(ListVariableExpr listvariableexpr_,
Expression expression_) {
super(listvariableexpr_, expression_);
}

@Id
@Column(name = "uuid", unique = true, nullable = false, insertable =
true, updatable = true)
public String getUuid() {
return this.uuid;
}

public void setUuid(String id) {
this.uuid = id;
}

@Id
@Column(name = "id", unique = true, nullable = false, insertable = true,
updatable = true)
public String getId() {
return this.uuid;
}

public void setId(String id) {
this.uuid = id;
}

@OneToMany(cascade = { CascadeType.ALL }, fetch = FetchType.LAZY,
mappedBy = "AbstractionResource")
public ListVariableExpr getListvariableexpr_() {
return this.listvariableexpr_;
}

@Column(name = "expression_", unique = false, nullable = true,
insertable = true, updatable = true)
public Expression getExpression_() {
return this.expression_;
}
}


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimila

[Lift] Re: Giving an Actor access to S

[marius d.]

CometActors are asynchronous components that live beyond the scope of
a given request. From a CometActor you can have access to LiftSession
or SessionVars meaning that you could potentially "store" the "last-
seen" from the last request host name in a SessionVar an then access
it anytime from your actor.

Not sure why you need the hostName from inside an actor but you know
best what application you are building.

Br's,
Marius

On May 25, 9:39 pm, Bryan  wrote:
> How can I give an Actor access to S?  I need this for adding results
> to a SessionVar of a HashMap.
>
> If I call show() directly, then I see "localhost" logged.  If I call
> show() from within an actor, then it logs "nowhere_123.com":
> listener ! 'show.
>
> val listener: Actor = actor {
>   loop {
>     react {
>       case 'show => show()
>     }
>   }
>
> }
>
> def show() {
>   Log.info("show's host name: " + S.hostName)
>
> }
--~--~-~--~~~---~--~~
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] Giving an Actor access to S

[Bryan]

How can I give an Actor access to S?  I need this for adding results
to a SessionVar of a HashMap.

If I call show() directly, then I see "localhost" logged.  If I call
show() from within an actor, then it logs "nowhere_123.com":
listener ! 'show.

val listener: Actor = actor {
  loop {
react {
  case 'show => show()
}
  }
}

def show() {
  Log.info("show's host name: " + S.hostName)
}
--~--~-~--~~~---~--~~
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-tag discussion

[marius d.]

No performance implications especially since built-in snippets are
objects and invoked non reflectively. It's just that the way these two
artifacts are processed right now it is not by the means of snippets
but buried deeply into surround snippet processing.

Thanks guys for your thoughts. Hopefully are people would feel the
same.

Br's,
Marius

On May 25, 12:44 pm, Timothy Perrett  wrote:
> +1 for option 1... seems to make the most sense given our current
> infrastructure.
>
> What would be the benifit of keeping lift tags around longer term? Are
> there any performance implications using snippets rather than tags?
> (shouldnt be, but just need to explore this)
>
> Cheers, Tim
>
> On May 25, 10:11 am, Heiko Seeberger 
> wrote:
>
> > From a user's perspective lift-tag feels odd => I prefer version 1
> > Heiko
>
> > 2009/5/25 Marius 
>
> > > Dear all,
>
> > > As you may have noticed recently lift:bind and lift:with-param has
> > > been deprecated in favor of lift-tag:bind and lift-tag:with-param. The
> > > rationale was that the syntax for these two constructs was similar
> > > with a snippet invocation where in fact the two are not snippets. so
> > > lift-tag distinguishes between snippets invocation and the tags
> > > processing (which in this cases happens inside of surround
> > > processing).
>
> > > I did this deprecations (based on public list discussions) but I'm not
> > > thrilled about it. I don't know what it is but something is just not
> > > there (really weird ...).
>
> > > Now what options do we really have?
>
> > > 1. Make lift:bind and lift:with-param to be real snippets. That should
> > > be feasible but requires a bit of changes (transparent to the
> > > user) ... this would lead to un-deprecation of current deprecations :)
> > > 2. Suggest some other naming convention or just live with lift-tag
> > > prefix
> > > 3. Other thoughts?
>
> > > Br's,
> > > Marius
>
> > --
> > My blog: heikoseeberger.name
> > Follow me: twitter.com/hseeberger
> > OSGi on Scala:www.scalamodules.org
> > Lift, the simply functional web framework: liftweb.net
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: lift-tag discussion

[Timothy Perrett]

+1 for option 1... seems to make the most sense given our current
infrastructure.

What would be the benifit of keeping lift tags around longer term? Are
there any performance implications using snippets rather than tags?
(shouldnt be, but just need to explore this)

Cheers, Tim

On May 25, 10:11 am, Heiko Seeberger 
wrote:
> From a user's perspective lift-tag feels odd => I prefer version 1
> Heiko
>
> 2009/5/25 Marius 
>
>
>
>
>
>
>
> > Dear all,
>
> > As you may have noticed recently lift:bind and lift:with-param has
> > been deprecated in favor of lift-tag:bind and lift-tag:with-param. The
> > rationale was that the syntax for these two constructs was similar
> > with a snippet invocation where in fact the two are not snippets. so
> > lift-tag distinguishes between snippets invocation and the tags
> > processing (which in this cases happens inside of surround
> > processing).
>
> > I did this deprecations (based on public list discussions) but I'm not
> > thrilled about it. I don't know what it is but something is just not
> > there (really weird ...).
>
> > Now what options do we really have?
>
> > 1. Make lift:bind and lift:with-param to be real snippets. That should
> > be feasible but requires a bit of changes (transparent to the
> > user) ... this would lead to un-deprecation of current deprecations :)
> > 2. Suggest some other naming convention or just live with lift-tag
> > prefix
> > 3. Other thoughts?
>
> > Br's,
> > Marius
>
> --
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala:www.scalamodules.org
> Lift, the simply functional web framework: liftweb.net
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: lift-tag discussion

[Heiko Seeberger]

>From a user's perspective lift-tag feels odd => I prefer version 1
Heiko

2009/5/25 Marius 

>
> Dear all,
>
> As you may have noticed recently lift:bind and lift:with-param has
> been deprecated in favor of lift-tag:bind and lift-tag:with-param. The
> rationale was that the syntax for these two constructs was similar
> with a snippet invocation where in fact the two are not snippets. so
> lift-tag distinguishes between snippets invocation and the tags
> processing (which in this cases happens inside of surround
> processing).
>
> I did this deprecations (based on public list discussions) but I'm not
> thrilled about it. I don't know what it is but something is just not
> there (really weird ...).
>
> Now what options do we really have?
>
> 1. Make lift:bind and lift:with-param to be real snippets. That should
> be feasible but requires a bit of changes (transparent to the
> user) ... this would lead to un-deprecation of current deprecations :)
> 2. Suggest some other naming convention or just live with lift-tag
> prefix
> 3. Other thoughts?
>
>
>
> Br's,
> Marius
> >
>


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

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

[Lift] lift-tag discussion

[Marius]

Dear all,

As you may have noticed recently lift:bind and lift:with-param has
been deprecated in favor of lift-tag:bind and lift-tag:with-param. The
rationale was that the syntax for these two constructs was similar
with a snippet invocation where in fact the two are not snippets. so
lift-tag distinguishes between snippets invocation and the tags
processing (which in this cases happens inside of surround
processing).

I did this deprecations (based on public list discussions) but I'm not
thrilled about it. I don't know what it is but something is just not
there (really weird ...).

Now what options do we really have?

1. Make lift:bind and lift:with-param to be real snippets. That should
be feasible but requires a bit of changes (transparent to the
user) ... this would lead to un-deprecation of current deprecations :)
2. Suggest some other naming convention or just live with lift-tag
prefix
3. Other thoughts?



Br's,
Marius
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to 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] "Fail" functions repeatedly evaluated in ?

[Willis Blackburn]

Following the example in Exploring Lift section 5.3.1, I set up some
of my site map pages to redirect to a login page if the user is not
already logged in.  My implementation of the "failMsg" function is
slightly different, though:  Before redirecting, I save the request
URI to a SessionVar so the login page can redirect to the originally-
requested page.

Unfortunately this strategy doesn't work very well.  The failMsg
function gets called even when the user isn't requesting a protected
page.  The problem is that the  tag invokes
Loc.testAccess on all the Loc instances in the site map in order to
determine whether to display them or not, and testAccess invokes the
failMsg function on all the ones that are not supposed to be
displayed.  So as soon as the login page is displayed, the SessionVar
holding the originally-requested page gets clobbered six or seven
times as the menu builder renders the menu.

Is this the way it's supposed to work?

W


--~--~-~--~~~---~--~~
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] using selectObj

[Tobias Daub]

Hi Lifters,

I attempted to modify a MappedLongForeignKey field in my class to 
display itself as a drop-down menu.

I wanna select objects from another database table, therefore I used 
SHtml.selectObj. Here's the code:

object tradeType extends 
MappedLongForeignKey(this.asInstanceOf[MapperType], TradeTypeMetaObj){
 
  override def _toForm = 
Full(selectObj(List((TradeTypeMetaObj.findAll(By(TradeTypeMetaObj.name, 
"BUY")), "BUY"),
 
(TradeTypeMetaObj.findAll(By(TradeTypeMetaObj.name, "SELL")), "SELL")),
 Full(is.toString),
 (f: TradeType) => 
set(f.toString)))
}


I have some problems with the three parameters for selectObj. I don't 
understand the two examples (one in the Lift book, p. 53, 4.1.10 
"selectObj", the other one in the getting started tutorial, p. 18, 2.10 
"Updating the priority and desc fields"). In both examples they use 
lists of some data, instead of Lists-Of-Tuples, which is the official 
way mentioned in the documentation of the selectObj method in the book.

I think the first parameter should be OK, at least the compiler doesn't 
complain about it. The second parameter is as far as I understood it, 
the entry that should be selected by default. But I don't really know, 
what the third one, the function object awaits from me.

As you can see, the list only contains two objects. I wanna display 
"BUY" for the first one and "SELL" for the second one. Depending on what 
the user selects, the corresponding object should be stored in the 
tradeType field. There are only two rows/instances in the TradeType 
table, one for BUY and one for SELL.


thanks in advance...


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