Re: [Lift] Js normalizations

[Heiko Seeberger]

On 7 March 2010 19:37, Marius  wrote:

>
> If you think that this makes sense I'll add a ticket and put it in my
> backlog.
>

Makes a lot of sense for me. Go for it!

Heiko

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net

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

Re: [Lift] Activity

[David Pollak]

On Sat, Mar 6, 2010 at 7:10 PM, Martin  wrote:

> Hey,
>
> First of all, let me take the complete opposite stance observed from
> one of the most reason posts from a "Rails Junkie". I'm very excited
> to see a framework that takes the good from so many different projects
> and houses it under a language that does the same. I find it
> refreshing to have the powerful tools developed around Java available
> for development in this new Scala language and the Lift framework. No
> matter how much one hates the design choices and the verbosity of the
> most popular platform in our lifetime, it is only a benefit that we
> have access to the years of effort devoted to it. The powerful
> compiler behind Scala is my sole reason for preferring it to ports
> like JRuby and Groovy.
>
> Now to the point of my query, what is the activity and excitement
> levels around lift at this point? I understand that money drives the
> world and to make a framework successful one must market like Rails
> and make some bank to promote future maintenance and improvements.
>

Please see http://www.ohloh.net/p/liftweb/

They do an analysis of commits to open source projects.  A couple of
take-aways is the increase in both team size and number of commits to Lift
over the last year.  33 different people contributed code.  That's
significant momentum.


>
> I notice the last production quality release was over a year ago;


Actually, it was last week.  Companies including FourSquare run their
service on Lift milestone releases.

We were hoping to have Lift 1.1 (now 2.0) out a long time ago, but we've
been tracking Scala 2.8 which was, well, supposed to be out a long time ago.
 So, every few months, it looks as if Scala 2.8 is just around the corner
and it seems that it makes sense to hold off on the Lift 2.0 final until
Scala 2.8.

But, I spent a week hanging with Martin Odersky a few weeks back (as well as
Paul Philips) and I think a mid to late Spring 2.8 release is a reality
which means that a Lift 2.0 release will happen 3-6 weeks after that
(depending on where in the month Scala lands and how stable the 2.8.0
release is).


> I do
> notice there have been much more frequent updates to say the wiki and
> the work on the 1.1 milestones. It just seems strange that a minor
> release on such a young project would taking such a long time.


This will change after our 2.0 release.   Perhaps we'll do monthly
milestones and quarterly dot releases (ports of the "best of" the milestones
that do not break API compatibility).


> This is
> a completely naive view of what is going on, and this is why i post
> this query because I want to be disproven so I can feel comfortable
> suggesting the use of this framework for the long term.
>

Take a look at ticket velocity and review board velocity.  As you watch the
increase in number of tickets, you'll get, I hope, a sense of vibrance in
the code and the community.  The other thing to look at is the mailing list
velocity and size.  http://groups.google.com/group/liftweb/about?hl=en
We've doubled the number of messages on the list over last year and
the
mailing list size is > 1,700 and growing steadily at an average of 5-7 new
people per day.


>
> Thanks for letting me take some of your time away from more important
> things :). I just figured seeing this was a question in my mind,
> others thinking about using the framework might have the same
> question.
>

I hope I've addressed your concerns.  If you are thinking about Lift for a
production site (profit or non-profit), please contact me off-list to tell
me about your project.  I may have people that could help you communicate
effectively with your team about the risks and benefits of going with Lift.

Thanks,

David

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


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

[Lift] Re: IdPK Model boiler-plate

[aw]

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.

Re: [Lift] Re: [lift] superficial first impressions from a rails junkie

[David Pollak]

On Sun, Mar 7, 2010 at 12:15 PM, Naftoli Gugenheim wrote:

> I think that Jonathan was impolite in expressing his frustration at being
> misunderstood.
>

First, don't you think that it's ironic that someone who was trying to teach
us about marketing was so incapable of expressing himself effectively?
 Would you take the marketing advice of someone who cannot communicate basic
concepts without resorting to belittling and screaming?  What you don't know
is that Jonathan made some posting that were more troll-like that I did not
approve (something that's very rare) because they were just rants about us
not understanding what he was saying (including quotes like "Lift is just
the flavor of the month").

Some other things you don't know is that Jonathan contacted me privately...
something I generally frown on (see
http://groups.google.com/group/liftweb/browse_thread/thread/c7a97cbf60780f0
 )

He suggested that I read some books by Geoffrey
Mooreand some books about not
letting MBAs fleece you.

He also offered to help with marketing by offering his email address and no
other information about who he was or why his help would be of value.
 Hmmm another example of not effective marketing. (and yes, I did search
for him via Google and LinkedIn to see if he was some hot shot who was used
to talking in short-hand... but he was no where to be found.)

I suggested that he check out who I run with and asked him to tell me why he
would help with marketing Lift.

His response was that he Googled me and was unable to find any information
about me on Google, that I was not nearly as good at communications as I
thought and that I should include information (a mini-CV in his words) on
the Lift site.

So, let's work through this.

First, there are a couple of links in my sig-line.  The first one is to
Apress's listing for my book: http://www.apress.com/book/view/1430219890  This
page includes information about the author:

David Pollak

David Pollak has been writing commercial software since 1977. He wrote the
award–winning Mesa spreadsheet, which in 1992 was the first real–time
spreadsheet. Wall Street companies traded billions of dollars a day through
Mesa. In 1996, David sold his company to CMP Media and became CTO of CMP
Media’s NetGuide Live and was one of the first large–scale users of Java and
WebLogic to power an Internet site. In 1998, David released Integer, the
world’s first browser–accessible, multiuser spreadsheet. Since 2000, David
has been consulting for companies including Hewlett–Packard, Pretzel
Logic/WebGain, BankServ, Twitter, and SAP. David has been using Scala since
2006 and is the lead developer of the Lift Web Framework.

There's also a link to my Twitter feed  which
contains a link to my blog .

Now, let's take a look at the Lift  web site.  On the
front page is a mini-bio:

David Pollak has been writing commercial software since 1977. He wrote the
first real-time spreadsheet and the worlds highest performance spreadsheet
engine. Since 1996, David has been using and devising web development tools.

So, even without searching, one can find a fair amount about me.  But, let's
click through to the Team page on the Lift site.  There's a slightly longer
bio:

David Pollak has been writing commercial software since 1977. He wrote the
first real-time spreadsheet and the worlds highest performance spreadsheet
engine. Since 1996, David has been using and devising web development tools.
As CTO of CMP Media, David oversaw the first large-scale deployment of
WebLogic. David was CTO and VPE at Cenzic, a web application security
company. David has also developed numerous commercial projects in Ruby on
Rails. In 2007, David founded the Lift Web Framework open source project.

If you spend a little time with some of the other team bios, one in
particular will seem out of place... a "suit".  Specifically, Debby
Meredith's bio reads:

I'm a currently an engineering management consultant and a venture partner
at JAFCO Ventures. I work hands-on with company founders, helping to
assemble world class teams, architect software products and roadmaps, and
establish operational processes to build success from the beginning.
Previously, I was a venture partner at Mohr Davidow Ventures, VP Eng at
Netscape, VP Eng at Collabra Software, VP Eng at Slate Software, and had key
technical positions at Metaphor Computer Systems, Logitech, and Bell
Laboratories.

So, we've got someone who is a venture partner at JAFCO (a VC firm) who used
to be with MDV (another VC firm) who is a Lift committer.  Now, let me
connect a couple of dots.  Geoffrey Moore is a venture partner at MDV where
Debby used to be a Venture partner.  MDV also funded Cenzic.  What do you
think the chances are that I've at least heard of Crossing the Chasm?  What
are the chances I've read Crossing the Chasm?  What are the chances that
I've spent more than 1 day

[Lift] Re: Response Optimizations too aggressive

[aw]

On Mar 4, 9:50 am, David Pollak  wrote:
> On Thu, Mar 4, 2010 at 9:27 AM, aw  wrote:
> > On Mar 4, 6:56 am, Naftoli Gugenheim  wrote:
> > > How about
> > > LiftRules.stripComments.default.set( () => !Req.isIE)
> > > etc.?
>
> This is where Lift's FactoryMaker shines.  You can modify the behavior of
> stripComments on a request-by-request basis.  You can have a snippet called
> from your default template that tests the request and does:
>
> LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)
>
> But, as you point out, that means that CometActors will not get the right
> settings... so you can set the rule on a session-by-session basis:
>
> LiftRules.stripComments.request.set(S.request.map(!_.isIE) openOr false)

I don't see the difference.  I presume that you meant to say:

LiftRules.stripComments.session.set(S.request.map(!_.isIE) openOr
false)

?  Alas, neither version works.  I get a syntax error:

[ERROR] ...\snippet\Hack.scala:31: error: value set is not a member of
net.liftweb.util.Maker[Boolean]
[INFO] LiftRules.stripComments.request.set(S.request.map(!_.isIE)
openOr false)
[INFO] ^
[ERROR] one error found

Seeing that request is really a RequestVar, I figure the mod is simple
(lose the .set), but:

[ERROR] ...\snippet\Hack.scala:31: error: value apply is not a member
of net.liftweb.util.Maker[Boolean]
[INFO] LiftRules.stripComments.request(S.request.map(!_.isIE)
openOr false)
[INFO] ^
[ERROR] one error found

Now I am puzzled because I actually do see a valid apply method for
Maker[Boolean] (see line 66 of Maker.scala).

So, what am I missing?  I think I really want:

LiftRules.stripComments.session(S.request.map(!_.isIE) openOr
false)

I feel close, but no compile...

-- 
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] Customizing meta fields

[Naftoli Gugenheim]

It's not necessary. Just put a head section in the template and it will be 
combined with the head section in default.html.

-
Martin Dale Lyness wrote:

Thank you Ross, for the very informative response!

Now, I consider SEO to be closer to a designer task than a developer task so
keeping the power in the design documents would be my best idea. Is there
anyway to allow individual pages to define blocks that are read into the
snippets and then injected into the template?

Here is the scenario i'm thinking of:
1. A single uniform website template: default.html
2. Several HTML files: index.html, product_list.html, product_overview.html
3. Each of these HTML files containing  tags referencing snippets.

What i would want is for index.html, product_list.html, and
product_overview.html to all use default.html and various Snippet classes.
Now for SEO i would want the meta tags in the header of default.html to be
customized to index.html, product_list.html, and product_overview.html;
furthermore, product_list and product_overview are dynamic pages so they
would need further customization based on what the snippets are returning.

Essentially, i would want tags something like:
This site is totally awesome, better than all our
competitors   in index.html
Look at all these products in
%%category_name%%in product_list.html
%product_name% - %product_description%
in product_overview.html

The conceptual road block for me is coming from the controller first pattern
used in frameworks like Rails. In lift snippets are not really the same
conceptually. If i use the second proposed method
(i.e.  wrapping the entire template) i would have a
battle between snippets used by each page. For example, perhaps i have a
product overview snippet that sets the meta one way and a login snippet that
sets it another way (intended for when show standalone in a login.html).

The first solution with using a  to inject a
snippet at a meta location fits better because it would allow me to create a
generic function that would attempt to create the keyword and description
data based on whatever global information is made available to snippets by
lift (i.e. Request Parameters?). My only problem with using this option is
it puts all of the text on the developer side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.

Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?

-- Martin

On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren  wrote:

> To be parsed by the bind, it must be enclosed by
> ...
>
> There is relatively little magic -- Lift goes through your template looking
> for lift: prefixed tags. For those tags, it will look up a snippet class by
> using the part before the period (HelloWorld, in the above example) and then
> look for a method on that snippet class mentioned after the period (hello in
> the example). If there is no period, the method is assumed to be called
> "render".
>
> Once that method is found, the method is called with the contents of the
> lift: tag, and the result of the method call is spliced into the XML to
> replace the lift: tag.
>
> bind is a function that does something kind of similar to overall template
> processing, except you supply some prefix other than lift: (b: in the
> example) and a limited set of things after the colon that are valid (time
> and meta_desc in the example)
>
> So, you might want something like this instead:
>
> 
>
> class HelloWorld {
>
>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>
> }
>
> Which will result in this XHTML:
>
> test desc
>
> Or, if you want to keep it in the hello method, you'd then have to move the
>  to the outside of the template:
>
> 
>   ...
>   
> 
> 
>...
>
> 
>
> Hope that helps,
> -Ross
>
>
> On Mar 7, 2010, at 4:38 AM, Martin wrote:
>
> > How would one go about having dynamic description and keyword meta
> > tags in a template? Here is what i've tried:
> >
> > default.html
> > 
> >
> > HelloWorld.scala
> > Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
> > "meta_desc" -> "test desc")
> >
> > I'm using a basic archetype build of 2.0-M3 and it produces an error:
> >
> > This page contains the following errors:
> >
> > error on line 6 at column 28: Namespace prefix b on meta_desc is not
> > defined
> > Below is a rendering of the page up to the first error.
> >
> >
> > It appears to me that the template is not parsed by the Helpers.bind,
> > is this correct?
> >
> > --
> > 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

Re: [Lift] Customizing meta fields

[Martin Dale Lyness]

Thank you Ross, for the very informative response!

Now, I consider SEO to be closer to a designer task than a developer task so
keeping the power in the design documents would be my best idea. Is there
anyway to allow individual pages to define blocks that are read into the
snippets and then injected into the template?

Here is the scenario i'm thinking of:
1. A single uniform website template: default.html
2. Several HTML files: index.html, product_list.html, product_overview.html
3. Each of these HTML files containing  tags referencing snippets.

What i would want is for index.html, product_list.html, and
product_overview.html to all use default.html and various Snippet classes.
Now for SEO i would want the meta tags in the header of default.html to be
customized to index.html, product_list.html, and product_overview.html;
furthermore, product_list and product_overview are dynamic pages so they
would need further customization based on what the snippets are returning.

Essentially, i would want tags something like:
This site is totally awesome, better than all our
competitors   in index.html
Look at all these products in
%%category_name%%in product_list.html
%product_name% - %product_description%
in product_overview.html

The conceptual road block for me is coming from the controller first pattern
used in frameworks like Rails. In lift snippets are not really the same
conceptually. If i use the second proposed method
(i.e.  wrapping the entire template) i would have a
battle between snippets used by each page. For example, perhaps i have a
product overview snippet that sets the meta one way and a login snippet that
sets it another way (intended for when show standalone in a login.html).

The first solution with using a  to inject a
snippet at a meta location fits better because it would allow me to create a
generic function that would attempt to create the keyword and description
data based on whatever global information is made available to snippets by
lift (i.e. Request Parameters?). My only problem with using this option is
it puts all of the text on the developer side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.

Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?

-- Martin

On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren  wrote:

> To be parsed by the bind, it must be enclosed by
> ...
>
> There is relatively little magic -- Lift goes through your template looking
> for lift: prefixed tags. For those tags, it will look up a snippet class by
> using the part before the period (HelloWorld, in the above example) and then
> look for a method on that snippet class mentioned after the period (hello in
> the example). If there is no period, the method is assumed to be called
> "render".
>
> Once that method is found, the method is called with the contents of the
> lift: tag, and the result of the method call is spliced into the XML to
> replace the lift: tag.
>
> bind is a function that does something kind of similar to overall template
> processing, except you supply some prefix other than lift: (b: in the
> example) and a limited set of things after the colon that are valid (time
> and meta_desc in the example)
>
> So, you might want something like this instead:
>
> 
>
> class HelloWorld {
>
>def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")
>
> }
>
> Which will result in this XHTML:
>
> test desc
>
> Or, if you want to keep it in the hello method, you'd then have to move the
>  to the outside of the template:
>
> 
>   ...
>   
> 
> 
>...
>
> 
>
> Hope that helps,
> -Ross
>
>
> On Mar 7, 2010, at 4:38 AM, Martin wrote:
>
> > How would one go about having dynamic description and keyword meta
> > tags in a template? Here is what i've tried:
> >
> > default.html
> > 
> >
> > HelloWorld.scala
> > Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
> > "meta_desc" -> "test desc")
> >
> > I'm using a basic archetype build of 2.0-M3 and it produces an error:
> >
> > This page contains the following errors:
> >
> > error on line 6 at column 28: Namespace prefix b on meta_desc is not
> > defined
> > Below is a rendering of the page up to the first error.
> >
> >
> > It appears to me that the template is not parsed by the Helpers.bind,
> > is this correct?
> >
> > --
> > 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

Re: [Lift] Customizing meta fields

[Ross Mellgren]

To be parsed by the bind, it must be enclosed by 
...

There is relatively little magic -- Lift goes through your template looking for 
lift: prefixed tags. For those tags, it will look up a snippet class by using 
the part before the period (HelloWorld, in the above example) and then look for 
a method on that snippet class mentioned after the period (hello in the 
example). If there is no period, the method is assumed to be called "render".

Once that method is found, the method is called with the contents of the lift: 
tag, and the result of the method call is spliced into the XML to replace the 
lift: tag.

bind is a function that does something kind of similar to overall template 
processing, except you supply some prefix other than lift: (b: in the example) 
and a limited set of things after the colon that are valid (time and meta_desc 
in the example)

So, you might want something like this instead:



class HelloWorld {

def meta_desc(ns: NodeSeq): NodeSeq = Text("test desc")

}

Which will result in this XHTML:

test desc

Or, if you want to keep it in the hello method, you'd then have to move the 
 to the outside of the template:


   ...
   


...



Hope that helps,
-Ross


On Mar 7, 2010, at 4:38 AM, Martin wrote:

> How would one go about having dynamic description and keyword meta
> tags in a template? Here is what i've tried:
> 
> default.html
> 
> 
> HelloWorld.scala
> Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
> "meta_desc" -> "test desc")
> 
> I'm using a basic archetype build of 2.0-M3 and it produces an error:
> 
> This page contains the following errors:
> 
> error on line 6 at column 28: Namespace prefix b on meta_desc is not
> defined
> Below is a rendering of the page up to the first error.
> 
> 
> It appears to me that the template is not parsed by the Helpers.bind,
> is this correct?
> 
> -- 
> 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] LongMappedForeignKey should call primeObj in apply(v: O) and apply(v: Box[O])

[Naftoli Gugenheim]

Is there any objection to
https://www.assembla.com/spaces/liftweb/tickets/411 - MappedLongForeignKey
should call primeObj in apply(v: O) and apply(v: Box[O])?
In other words, if you set a MappedLongForeignKey by passing it a Mapper
instance of the referenced table, is there any reason not to cache it? The
current behavior is that the next time, after setting it from a Mapper, one
calls obj, another instance will be fetched from the database and cached.

-- 
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: IdPK Model boiler-plate

[Naftoli Gugenheim]

What's wrong with KeyedMapper's implementation?

-
aw wrote:

Done.  Issue 408.  Thanks!

https://www.assembla.com/spaces/liftweb/tickets/408-add-equals-and-hashcode-to-idpk-trait

On Mar 7, 11:53 am, David Pollak 
wrote:
> Good idea.  Please open a ticket 
> athttps://liftweb.assembla.com/spaces/liftweb/ticketsand assign it to me.

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

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

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

[Naftoli Gugenheim]

What is the current implementation?

-
aw wrote:

Done.  Issue 408.  Thanks!

https://www.assembla.com/spaces/liftweb/tickets/408-add-equals-and-hashcode-to-idpk-trait

On Mar 7, 11:53 am, David Pollak 
wrote:
> Good idea.  Please open a ticket 
> athttps://liftweb.assembla.com/spaces/liftweb/ticketsand assign it to me.

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

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

[Lift] Re: IdPK Model boiler-plate

[aw]

Done.  Issue 408.  Thanks!

https://www.assembla.com/spaces/liftweb/tickets/408-add-equals-and-hashcode-to-idpk-trait

On Mar 7, 11:53 am, David Pollak 
wrote:
> Good idea.  Please open a ticket 
> athttps://liftweb.assembla.com/spaces/liftweb/ticketsand assign it to me.

-- 
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: Js normalizations

[Naftoli Gugenheim]

I may have a project coming up that would use it though. :)

-
Marius wrote:

You must be unique :)

On Mar 7, 10:21 pm, Naftoli Gugenheim  wrote:
> Then it sounds good to me, although that doesn't count as much since I must 
> admit I haven't really had the opportunity to use Lift's ajax and javascript 
> parts.
>
> -
>
> Marius wrote:
>
> Yes that's the idea ... I apologize I didn't actually mean to just
> remove things out of the sudden. But I'll know more once I get to dig
> deeper.
>
> On Mar 7, 10:13 pm, Naftoli Gugenheim  wrote:
>
>
>
>
>
> > Can it be changed with a deprecation phase?
>
> > -
>
> > Marius wrote:
>
> > I'm not sure about the fastness as I also have other things and a 4
> > days baby boy ;) ... but I think this is fairly important and I'll try
> > to prioritize.
>
> > On Mar 7, 8:52 pm, Mads Hartmann Jensen  wrote:
>
> > > Marius,
> > > I think this sounds like a great idea - but I only have 2 Lift projects 
> > > under development so it would be quite fast for me to make any changes
>
> > > Mads
>
> > > On 07/03/2010, at 19.37, Marius wrote:
>
> > > > Dear all,
>
> > > > Looking at Js api and specifically JsCmds and JqJsCmds (the Js
> > > > abstractions vs Jquery specify abstractions) IMHO there are several
> > > > redundancies:
>
> > > > 1. JsCmds has ~> method for referencing member of "objects" (i.e
> > > > elem.focus()) but JQuery abstractions have >> method that "chains" a
> > > > JQueryLeft with JQueryRight
> > > > 2. JQueryLeft and JQueryRight also seems redundant because JsExp
> > > > already have the support for building expressions, composing them,
> > > > chaining expressions etc.
>
> > > > My proposal is to normalize this API and have the JQuery specific
> > > > things to rely on the JsExp support. I'm aware that this would lead to
> > > > some breaking changes but I believe they are necessary.
>
> > > > If you think that this makes sense I'll add a ticket and put it in my
> > > > backlog.
>
> > > > Thoughts?
>
> > > > Br's,
> > > > Marius
>
> > > > --
> > > > You received this message because you are subscribed to the Google 
> > > > Groups "Lift" group.
> > > > To post to this group, send email to lift...@googlegroups.com.
> > > > To unsubscribe from this group, send email to 
> > > > liftweb+unsubscr...@googlegroups.com.
> > > > For more options, visit this group 
> > > > athttp://groups.google.com/group/liftweb?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/liftweb?hl=en.

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

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

[Lift] Reorganize mapper specs?

[Naftoli Gugenheim]

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?

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

[Lift] Re: Js normalizations

[Marius]

You must be unique :)

On Mar 7, 10:21 pm, Naftoli Gugenheim  wrote:
> Then it sounds good to me, although that doesn't count as much since I must 
> admit I haven't really had the opportunity to use Lift's ajax and javascript 
> parts.
>
> -
>
> Marius wrote:
>
> Yes that's the idea ... I apologize I didn't actually mean to just
> remove things out of the sudden. But I'll know more once I get to dig
> deeper.
>
> On Mar 7, 10:13 pm, Naftoli Gugenheim  wrote:
>
>
>
>
>
> > Can it be changed with a deprecation phase?
>
> > -
>
> > Marius wrote:
>
> > I'm not sure about the fastness as I also have other things and a 4
> > days baby boy ;) ... but I think this is fairly important and I'll try
> > to prioritize.
>
> > On Mar 7, 8:52 pm, Mads Hartmann Jensen  wrote:
>
> > > Marius,
> > > I think this sounds like a great idea - but I only have 2 Lift projects 
> > > under development so it would be quite fast for me to make any changes
>
> > > Mads
>
> > > On 07/03/2010, at 19.37, Marius wrote:
>
> > > > Dear all,
>
> > > > Looking at Js api and specifically JsCmds and JqJsCmds (the Js
> > > > abstractions vs Jquery specify abstractions) IMHO there are several
> > > > redundancies:
>
> > > > 1. JsCmds has ~> method for referencing member of "objects" (i.e
> > > > elem.focus()) but JQuery abstractions have >> method that "chains" a
> > > > JQueryLeft with JQueryRight
> > > > 2. JQueryLeft and JQueryRight also seems redundant because JsExp
> > > > already have the support for building expressions, composing them,
> > > > chaining expressions etc.
>
> > > > My proposal is to normalize this API and have the JQuery specific
> > > > things to rely on the JsExp support. I'm aware that this would lead to
> > > > some breaking changes but I believe they are necessary.
>
> > > > If you think that this makes sense I'll add a ticket and put it in my
> > > > backlog.
>
> > > > Thoughts?
>
> > > > Br's,
> > > > Marius
>
> > > > --
> > > > You received this message because you are subscribed to the Google 
> > > > Groups "Lift" group.
> > > > To post to this group, send email to lift...@googlegroups.com.
> > > > To unsubscribe from this group, send email to 
> > > > liftweb+unsubscr...@googlegroups.com.
> > > > For more options, visit this group 
> > > > athttp://groups.google.com/group/liftweb?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/liftweb?hl=en.

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

Re: [Lift] Re: Js normalizations

[Naftoli Gugenheim]

Then it sounds good to me, although that doesn't count as much since I must 
admit I haven't really had the opportunity to use Lift's ajax and javascript 
parts.

-
Marius wrote:

Yes that's the idea ... I apologize I didn't actually mean to just
remove things out of the sudden. But I'll know more once I get to dig
deeper.

On Mar 7, 10:13 pm, Naftoli Gugenheim  wrote:
> Can it be changed with a deprecation phase?
>
> -
>
> Marius wrote:
>
> I'm not sure about the fastness as I also have other things and a 4
> days baby boy ;) ... but I think this is fairly important and I'll try
> to prioritize.
>
> On Mar 7, 8:52 pm, Mads Hartmann Jensen  wrote:
>
>
>
>
>
> > Marius,
> > I think this sounds like a great idea - but I only have 2 Lift projects 
> > under development so it would be quite fast for me to make any changes
>
> > Mads
>
> > On 07/03/2010, at 19.37, Marius wrote:
>
> > > Dear all,
>
> > > Looking at Js api and specifically JsCmds and JqJsCmds (the Js
> > > abstractions vs Jquery specify abstractions) IMHO there are several
> > > redundancies:
>
> > > 1. JsCmds has ~> method for referencing member of "objects" (i.e
> > > elem.focus()) but JQuery abstractions have >> method that "chains" a
> > > JQueryLeft with JQueryRight
> > > 2. JQueryLeft and JQueryRight also seems redundant because JsExp
> > > already have the support for building expressions, composing them,
> > > chaining expressions etc.
>
> > > My proposal is to normalize this API and have the JQuery specific
> > > things to rely on the JsExp support. I'm aware that this would lead to
> > > some breaking changes but I believe they are necessary.
>
> > > If you think that this makes sense I'll add a ticket and put it in my
> > > backlog.
>
> > > Thoughts?
>
> > > Br's,
> > > Marius
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Lift" group.
> > > To post to this group, send email to lift...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > liftweb+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/liftweb?hl=en.

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

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

[Lift] Re: Js normalizations

[Marius]

Yes that's the idea ... I apologize I didn't actually mean to just
remove things out of the sudden. But I'll know more once I get to dig
deeper.

On Mar 7, 10:13 pm, Naftoli Gugenheim  wrote:
> Can it be changed with a deprecation phase?
>
> -
>
> Marius wrote:
>
> I'm not sure about the fastness as I also have other things and a 4
> days baby boy ;) ... but I think this is fairly important and I'll try
> to prioritize.
>
> On Mar 7, 8:52 pm, Mads Hartmann Jensen  wrote:
>
>
>
>
>
> > Marius,
> > I think this sounds like a great idea - but I only have 2 Lift projects 
> > under development so it would be quite fast for me to make any changes
>
> > Mads
>
> > On 07/03/2010, at 19.37, Marius wrote:
>
> > > Dear all,
>
> > > Looking at Js api and specifically JsCmds and JqJsCmds (the Js
> > > abstractions vs Jquery specify abstractions) IMHO there are several
> > > redundancies:
>
> > > 1. JsCmds has ~> method for referencing member of "objects" (i.e
> > > elem.focus()) but JQuery abstractions have >> method that "chains" a
> > > JQueryLeft with JQueryRight
> > > 2. JQueryLeft and JQueryRight also seems redundant because JsExp
> > > already have the support for building expressions, composing them,
> > > chaining expressions etc.
>
> > > My proposal is to normalize this API and have the JQuery specific
> > > things to rely on the JsExp support. I'm aware that this would lead to
> > > some breaking changes but I believe they are necessary.
>
> > > If you think that this makes sense I'll add a ticket and put it in my
> > > backlog.
>
> > > Thoughts?
>
> > > Br's,
> > > Marius
>
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Lift" group.
> > > To post to this group, send email to lift...@googlegroups.com.
> > > To unsubscribe from this group, send email to 
> > > liftweb+unsubscr...@googlegroups.com.
> > > For more options, visit this group 
> > > athttp://groups.google.com/group/liftweb?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/liftweb?hl=en.

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

Re: [Lift] Re: [lift] superficial first impressions from a rails junkie

[Naftoli Gugenheim]

I think that Jonathan was impolite in expressing his frustration at being 
misunderstood.
But are his points not valuable?

-
David Pollak wrote:

Jonathan, your comments are someplace between not helpful and troll-like.
It'd be best if you did not continue to participate in this thread.

On Sun, Mar 7, 2010 at 5:36 AM, jonathan mawson  wrote:

>
>
>
> If there's no rational reason to use Lift, then perhaps you could find
> another community to spend your time in.
>
>
> I didn't say that there was no rational reason to use Lift BUT THAT YOU ARE
> FAILING TO COMMUNICATE WHAT THAT REASON MIGHT BE TO POTENTIAL USERS! You
> can't expect potential users to be Internet mind readers. Which is what
> your
> current strategy amounts to - other than "People will try Lift because
> there
> is a buzz about Scala."
>
>
>
> > Lift is not a clone of any framework.  It's different and there are
> > reasons for those differences.  If you don't like them, please use what
> > you like best.  Use what feels most comfortable for you.  Use what works
> > best for you.
> >
>
> I very carefully did NOT say that Lift should be a clone. I did say that,
> when you ask users to do things contrary to their expectations of a modern
> web framework, you tell them WHY you are asking them to do that and what
> the
> payoff will be for them. I'd talk them through these "surprises" with a
> series of short snippets in boxes - I'd also use these snippets for any
> "gotchas" like those critical spaces after the "/". I might start with:
>
> Working through this tutorial you'll encounter a horrible surprise - Lift
> is
> not YARC! (Yet Another Rails Clone.) That is because we have designed Lift
> to be a fundamentally different creature to Rails. Rails is an excellent
> framework whose first priority is ease of use for simple jobs where server
> efficiency can be traded away to get a site running quickly with minimum
> effort. Lift is a framework designed for jobs where Rails has run out. A
> well designed Lift site can handle up to 20 times the traffic of an
> equivalent Rails site on the same server. And while it perhaps isn't as
> easy
> to do simple things in Lift as in Rails, it is much easier to do most of
> the
> hard ones. In a way, both frameworks carry their philosophy in their names
> -
>
> - Rails expects you, the programmer, to be happy to run on a relatively
> pre-determined track in return for a simpler life.
>
> - Lift, like its host language Scala, is designed for HEAVY LIFTING. Its
> priorities are delivering security, maintainability and performance over
> the
> widest possible range of applications. It makes obtaining these good things
> as simple as possible, but occasionally you just have to eat your greens if
> you want to grow up big and strong.
>
> Those are the rationales behind the design choices we made. Creating your
> first toy site with Lift will take longer than with Rails, but creating
> your
> first secure, scalable site will take less time. Whenever Lift wants you to
> do something particularly surprising in this tutorial you'll see another
> box
> explaining why and what the pay-off will be for you. You'll also see boxes
> warning you of any fiddly 'gotchas'. Happy Lifting!
>
> Lightly adapted that might work as an intro for Lift in general. It
> *differentiates* you from Rails and gives potential users the info they
> need
> to decide whether or nor Lift is right for them to try, which is what
> technical marketing should be about. (It also obeys the "tell them three
> times" rule of Writing Stuff You Really Want People To Remember.")
>
> Oh - and I have now seen the Lift logo, and I think it looks fine!
>
> --
> View this message in context:
> http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27811402.html
> Sent from the liftweb mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


-- 
Lift, 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.

Re: [Lift] Re: Js normalizations

[Naftoli Gugenheim]

Can it be changed with a deprecation phase?

-
Marius wrote:

I'm not sure about the fastness as I also have other things and a 4
days baby boy ;) ... but I think this is fairly important and I'll try
to prioritize.

On Mar 7, 8:52 pm, Mads Hartmann Jensen  wrote:
> Marius,
> I think this sounds like a great idea - but I only have 2 Lift projects under 
> development so it would be quite fast for me to make any changes
>
> Mads
>
> On 07/03/2010, at 19.37, Marius wrote:
>
>
>
> > Dear all,
>
> > Looking at Js api and specifically JsCmds and JqJsCmds (the Js
> > abstractions vs Jquery specify abstractions) IMHO there are several
> > redundancies:
>
> > 1. JsCmds has ~> method for referencing member of "objects" (i.e
> > elem.focus()) but JQuery abstractions have >> method that "chains" a
> > JQueryLeft with JQueryRight
> > 2. JQueryLeft and JQueryRight also seems redundant because JsExp
> > already have the support for building expressions, composing them,
> > chaining expressions etc.
>
> > My proposal is to normalize this API and have the JQuery specific
> > things to rely on the JsExp support. I'm aware that this would lead to
> > some breaking changes but I believe they are necessary.
>
> > If you think that this makes sense I'll add a ticket and put it in my
> > backlog.
>
> > Thoughts?
>
> > Br's,
> > Marius
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/liftweb?hl=en.

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

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

[Lift] Re: Js normalizations

[Marius]

I'm not sure about the fastness as I also have other things and a 4
days baby boy ;) ... but I think this is fairly important and I'll try
to prioritize.

On Mar 7, 8:52 pm, Mads Hartmann Jensen  wrote:
> Marius,
> I think this sounds like a great idea - but I only have 2 Lift projects under 
> development so it would be quite fast for me to make any changes
>
> Mads
>
> On 07/03/2010, at 19.37, Marius wrote:
>
>
>
> > Dear all,
>
> > Looking at Js api and specifically JsCmds and JqJsCmds (the Js
> > abstractions vs Jquery specify abstractions) IMHO there are several
> > redundancies:
>
> > 1. JsCmds has ~> method for referencing member of "objects" (i.e
> > elem.focus()) but JQuery abstractions have >> method that "chains" a
> > JQueryLeft with JQueryRight
> > 2. JQueryLeft and JQueryRight also seems redundant because JsExp
> > already have the support for building expressions, composing them,
> > chaining expressions etc.
>
> > My proposal is to normalize this API and have the JQuery specific
> > things to rely on the JsExp support. I'm aware that this would lead to
> > some breaking changes but I believe they are necessary.
>
> > If you think that this makes sense I'll add a ticket and put it in my
> > backlog.
>
> > Thoughts?
>
> > Br's,
> > Marius
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/liftweb?hl=en.

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

Re: [Lift] Re: [lift] superficial first impressions from a rails junkie

[David Pollak]

Jonathan, your comments are someplace between not helpful and troll-like.
It'd be best if you did not continue to participate in this thread.

On Sun, Mar 7, 2010 at 5:36 AM, jonathan mawson  wrote:

>
>
>
> If there's no rational reason to use Lift, then perhaps you could find
> another community to spend your time in.
>
>
> I didn't say that there was no rational reason to use Lift BUT THAT YOU ARE
> FAILING TO COMMUNICATE WHAT THAT REASON MIGHT BE TO POTENTIAL USERS! You
> can't expect potential users to be Internet mind readers. Which is what
> your
> current strategy amounts to - other than "People will try Lift because
> there
> is a buzz about Scala."
>
>
>
> > Lift is not a clone of any framework.  It's different and there are
> > reasons for those differences.  If you don't like them, please use what
> > you like best.  Use what feels most comfortable for you.  Use what works
> > best for you.
> >
>
> I very carefully did NOT say that Lift should be a clone. I did say that,
> when you ask users to do things contrary to their expectations of a modern
> web framework, you tell them WHY you are asking them to do that and what
> the
> payoff will be for them. I'd talk them through these "surprises" with a
> series of short snippets in boxes - I'd also use these snippets for any
> "gotchas" like those critical spaces after the "/". I might start with:
>
> Working through this tutorial you'll encounter a horrible surprise - Lift
> is
> not YARC! (Yet Another Rails Clone.) That is because we have designed Lift
> to be a fundamentally different creature to Rails. Rails is an excellent
> framework whose first priority is ease of use for simple jobs where server
> efficiency can be traded away to get a site running quickly with minimum
> effort. Lift is a framework designed for jobs where Rails has run out. A
> well designed Lift site can handle up to 20 times the traffic of an
> equivalent Rails site on the same server. And while it perhaps isn't as
> easy
> to do simple things in Lift as in Rails, it is much easier to do most of
> the
> hard ones. In a way, both frameworks carry their philosophy in their names
> -
>
> - Rails expects you, the programmer, to be happy to run on a relatively
> pre-determined track in return for a simpler life.
>
> - Lift, like its host language Scala, is designed for HEAVY LIFTING. Its
> priorities are delivering security, maintainability and performance over
> the
> widest possible range of applications. It makes obtaining these good things
> as simple as possible, but occasionally you just have to eat your greens if
> you want to grow up big and strong.
>
> Those are the rationales behind the design choices we made. Creating your
> first toy site with Lift will take longer than with Rails, but creating
> your
> first secure, scalable site will take less time. Whenever Lift wants you to
> do something particularly surprising in this tutorial you'll see another
> box
> explaining why and what the pay-off will be for you. You'll also see boxes
> warning you of any fiddly 'gotchas'. Happy Lifting!
>
> Lightly adapted that might work as an intro for Lift in general. It
> *differentiates* you from Rails and gives potential users the info they
> need
> to decide whether or nor Lift is right for them to try, which is what
> technical marketing should be about. (It also obeys the "tell them three
> times" rule of Writing Stuff You Really Want People To Remember.")
>
> Oh - and I have now seen the Lift logo, and I think it looks fine!
>
> --
> View this message in context:
> http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27811402.html
> Sent from the liftweb mailing list archive at Nabble.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>


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

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

Re: [Lift] IdPK Model boiler-plate

[David Pollak]

Good idea.  Please open a ticket at
https://liftweb.assembla.com/spaces/liftweb/tickets and assign it to me.

On Sun, Mar 7, 2010 at 10:57 AM, aw  wrote:

> My model classes mix-in IdPK and have the following boiler-plate for
> equals and hashCode:
>
> class Team extends LongKeyedMapper[Team] with IdPK {
>  
>
>  override def equals (other : Any) = other match {
>case t : Team if t.id.is == this.id.is => true
>case _ => false
>  }
>
>  override def hashCode = this.id.is.hashCode
> }
>
>
> I'm pretty sure I acquired this boiler-plate for equals and hashCode
> from this Google Group.
>
> Is this implementation for equals and hashCode a good idea?  If so,
> shouldn't it be part of the IdPK trait?
>
> --
> 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.

Re: [Lift] toForm function passing problem ... ?

[David Pollak]

On Sun, Mar 7, 2010 at 9:54 AM, hexa  wrote:

> Hi,
>
>  I'm trying to do something which should be simple I think .. passing
> a function to toForm like so :
>
> class AddClient {
>
>  def add (inhtml: NodeSeq) : NodeSeq = {
>
>val client = Client.create
>
>def processEntry () =  {
>  client.save
>  S.notice ("Entre : Prenom " + client.prenom + " Nom : " +
> client.nom)
>}
>
>client.toForm (Full ("Ajouter Client"),   processEntry )
>

try:

client.toForm(Full(""), processEntrry _ ) // the _ turns it into a
function


>  }
> }
>
> But I keep getting something like :
>
> AddClient.scala:23: error: overloaded method value toForm with
> alternatives (net.liftweb.util.Box[String],
> (com.envirobiz.model.Client) => Any)scala.xml.NodeSeq 
> (net.liftweb.util.Box[String],String)scala.xml.NodeSeq cannot be
> applied to (net.liftweb.util.Full[java.lang.String],Unit)
> [INFO] client.toForm (Full ("Ajouter Client"),   processEntry )
>
> Looking at the spect I see :
> def toForm(button : Box[String], f : (A) => Any)
>
> So seems to me it should take any func... ,
>
> Any ideas ?
>
> Note that i'm new to scala/lift...
>
>
>
>
> --
> 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.

[Lift] toForm function passing problem ... ?

[hexa]

Hi,

  I'm trying to do something which should be simple I think .. passing
a function to toForm like so :

class AddClient {

  def add (inhtml: NodeSeq) : NodeSeq = {

val client = Client.create

def processEntry () =  {
  client.save
  S.notice ("Entre : Prenom " + client.prenom + " Nom : " +
client.nom)
}

client.toForm (Full ("Ajouter Client"),   processEntry )
  }
}

But I keep getting something like :

AddClient.scala:23: error: overloaded method value toForm with
alternatives (net.liftweb.util.Box[String],
(com.envirobiz.model.Client) => Any)scala.xml.NodeSeq 
(net.liftweb.util.Box[String],String)scala.xml.NodeSeq cannot be
applied to (net.liftweb.util.Full[java.lang.String],Unit)
[INFO] client.toForm (Full ("Ajouter Client"),   processEntry )

Looking at the spect I see :
def toForm(button : Box[String], f : (A) => Any)

So seems to me it should take any func... ,

Any ideas ?

Note that i'm new to scala/lift...




-- 
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] IdPK Model boiler-plate

[aw]

My model classes mix-in IdPK and have the following boiler-plate for
equals and hashCode:

class Team extends LongKeyedMapper[Team] with IdPK {
  

  override def equals (other : Any) = other match {
case t : Team if t.id.is == this.id.is => true
case _ => false
  }

  override def hashCode = this.id.is.hashCode
}


I'm pretty sure I acquired this boiler-plate for equals and hashCode
from this Google Group.

Is this implementation for equals and hashCode a good idea?  If so,
shouldn't it be part of the IdPK trait?

-- 
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] Js normalizations

[Mads Hartmann Jensen]

Marius,
I think this sounds like a great idea - but I only have 2 Lift projects under 
development so it would be quite fast for me to make any changes 

Mads

On 07/03/2010, at 19.37, Marius wrote:

> Dear all,
> 
> Looking at Js api and specifically JsCmds and JqJsCmds (the Js
> abstractions vs Jquery specify abstractions) IMHO there are several
> redundancies:
> 
> 1. JsCmds has ~> method for referencing member of "objects" (i.e
> elem.focus()) but JQuery abstractions have >> method that "chains" a
> JQueryLeft with JQueryRight
> 2. JQueryLeft and JQueryRight also seems redundant because JsExp
> already have the support for building expressions, composing them,
> chaining expressions etc.
> 
> My proposal is to normalize this API and have the JQuery specific
> things to rely on the JsExp support. I'm aware that this would lead to
> some breaking changes but I believe they are necessary.
> 
> If you think that this makes sense I'll add a ticket and put it in my
> backlog.
> 
> Thoughts?
> 
> Br's,
> Marius
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en.
> 

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

[Lift] Js normalizations

[Marius]

Dear all,

Looking at Js api and specifically JsCmds and JqJsCmds (the Js
abstractions vs Jquery specify abstractions) IMHO there are several
redundancies:

1. JsCmds has ~> method for referencing member of "objects" (i.e
elem.focus()) but JQuery abstractions have >> method that "chains" a
JQueryLeft with JQueryRight
2. JQueryLeft and JQueryRight also seems redundant because JsExp
already have the support for building expressions, composing them,
chaining expressions etc.

My proposal is to normalize this API and have the JQuery specific
things to rely on the JsExp support. I'm aware that this would lead to
some breaking changes but I believe they are necessary.

If you think that this makes sense I'll add a ticket and put it in my
backlog.

Thoughts?

Br's,
Marius

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

[Lift] Re: Lift security vulnerability

[Joni Freeman]

Note, it is very easy to clean up the JSON before rendering by using
'map' function:

json map {
  case JString(s) => JString(sripOutBinaryChars(s))
  case x => x
}

(You just need to implement that sripOutBinaryChars function...).

Cheers Joni

On Mar 5, 8:26 pm, Dano  wrote:
> I think I would like to amend my last post by asking if it is possible
> that the lift-jsonlibrary support the ability to strip out binary
> characters since many times an application uses the results ofJSON
> operations to render back to the client.
>
> Thanks.
>
> Dan
>
> On Mar 5, 9:53 am, Dano  wrote:
>
> > I can reproduce it in our application, but I think it is not
> > necessarily due to Lift.  This is what I am trying to sort out.  We
> > have client-side javascript which is sendingJSONcommands to the
> > server and things blow up once things come back from the server.  In
> > this case, Lift is not responsible for the rendering so I would say
> > this is an application issue.
>
> > I am poking at the demo lift application to try to flush out issues
> > common to the group and understand what is a framework issue and what
> > needs to be addressed by the application.
>
> > Thanks.
>
> > Dan
>
> > On Mar 5, 9:47 am, Naftoli Gugenheim  wrote:
>
> > > Can you reproduce the vulnerability in your own M3 app?
>
> > > -
>
> > > Dano wrote:
>
> > > I would never claim to be astute.  However, I did observe that
> > > demo.liftweb.net is now built using 2.0-M3 as is clearly listed at the
> > > bottom of the page.  I also observed that the Wizard example is still
> > > broken (paste binary characters into 'First Name' and then click the
> > > Next button).  I have not yet registered for an account with Assembla
> > > but would be happy to file the bug.
>
> > > Dan
>
> > > On Mar 4, 7:33 pm, Ross Mellgren  wrote:
>
> > > > Check dpp's response as of 8:01
>
> > > > -Ross
>
> > > > On Mar 4, 2010, at 7:49 PM, Naftoli Gugenheim wrote:
>
> > > > > What version is the demo running?
>
> > > > > -
> > > > > Dano wrote:
>
> > > > > Just saw that Lift 2.0-M3 was released.  I looked to see if the
> > > > > vulnerability was still present in demo.liftweb.net and I am still
> > > > > able to generate exceptions in the browser when I paste binary
> > > > > characters in the textfields for the Wizard, Wizard Challenge, and Arc
> > > > > Challenge examples in the Misc section.
>
> > > > > Don't know if this remaining problem is supposed to be handled by the
> > > > > application or framework, but thought I would make a post to alert the
> > > > > group.
>
> > > > > Dan
>
> > > > > On Feb 24, 11:49 am, Dano  wrote:
> > > > >> The recent scala days conference activity may have cause the updates
> > > > >> to this thread to escape notice.  Just wondering if there is concern
> > > > >> about the remaining binary character problems I noted in my prior
> > > > >> post.
>
> > > > >> Thanks in advance.
>
> > > > >> Dan
>
> > > > >> On Feb 22, 1:34 pm, Dano  wrote:
>
> > > > >>> More information on this in case anyone is interested.  If you go to
> > > > >>> theliftdemo website, it appears the issue with characters is mostly
> > > > >>> addressed except for the "Misc code" section.   Specifically, the
> > > > >>> "Wizard", "Wizard Challenge" and "Arc Challenge #1" examples will
> > > > >>> generate XML parsing errors.
>
> > > > >>> For these problems, I am not sure if the issue if the example or the
> > > > >>> framework.  If the issue is with the example, it would be good to 
> > > > >>> know
> > > > >>> whatLiftapps need to do to avoid getting bitten by binary characters
> > > > >>> entered into form fields.
>
> > > > >>> Thanks in advance.
>
> > > > >>> Dan
>
> > > > >>> On Feb 17, 11:06 am, Dano  wrote:
>
> > > >  Hello,
>
> > > >  I was wondering if the fix for the control characters issue was
> > > >  included in 2.0-M2.  I just did a test with ourLiftapplication 
> > > >  built
> > > >  with 2.0-M2 and I am still seeing problems (i.e. javascript 
> > > >  exceptions
> > > >  - NS_ERROR_INVALID_POINTER).
>
> > > >  Thanks in advance.
>
> > > >  Dan
>
> > > >  On Feb 3, 9:08 am, David Pollak  
> > > >  wrote:
>
> > > > > Thanks for pointing that out.  There are other problems as 
> > > > > well... I'll fix
> > > > > them (in both the Scala andLiftdiffs)
>
> > > > > On Wed, Feb 3, 2010 at 7:39 AM, Feng Zhang  
> > > > > wrote:
> > > > >> I found that in the fix, \n is changed to \t, while \t to \n. Is 
> > > > >> this
> > > > >> desired behavior?
>
> > > > >> Thank you,
>
> > > > >> Feng
>
> > > > >> On Wed, Feb 3, 2010 at 9:20 AM, Indrajit Raychaudhuri 
> > > > >>  > > > >>> wrote:
>
> > > > >>> 1. Fix in head/master (2.0-SNAPSHOT) and prepone 2.0-M2.
>
> > > > >>> 2. Backport in 1.0.x branch and spin 1.0.4. We haven't marked 
> > > > >>> 1.0.x
> > > > >>> 'unsupported' yet.

[Lift] Re: [lift] superficial first impressions from a rails junkie

[jonathan mawson]

If there's no rational reason to use Lift, then perhaps you could find
another community to spend your time in.


I didn't say that there was no rational reason to use Lift BUT THAT YOU ARE
FAILING TO COMMUNICATE WHAT THAT REASON MIGHT BE TO POTENTIAL USERS! You
can't expect potential users to be Internet mind readers. Which is what your
current strategy amounts to - other than "People will try Lift because there
is a buzz about Scala."



> Lift is not a clone of any framework.  It's different and there are
> reasons for those differences.  If you don't like them, please use what
> you like best.  Use what feels most comfortable for you.  Use what works
> best for you.
> 

I very carefully did NOT say that Lift should be a clone. I did say that,
when you ask users to do things contrary to their expectations of a modern
web framework, you tell them WHY you are asking them to do that and what the
payoff will be for them. I'd talk them through these "surprises" with a
series of short snippets in boxes - I'd also use these snippets for any
"gotchas" like those critical spaces after the "/". I might start with: 

Working through this tutorial you'll encounter a horrible surprise - Lift is
not YARC! (Yet Another Rails Clone.) That is because we have designed Lift
to be a fundamentally different creature to Rails. Rails is an excellent
framework whose first priority is ease of use for simple jobs where server
efficiency can be traded away to get a site running quickly with minimum
effort. Lift is a framework designed for jobs where Rails has run out. A
well designed Lift site can handle up to 20 times the traffic of an
equivalent Rails site on the same server. And while it perhaps isn't as easy
to do simple things in Lift as in Rails, it is much easier to do most of the
hard ones. In a way, both frameworks carry their philosophy in their names -

- Rails expects you, the programmer, to be happy to run on a relatively
pre-determined track in return for a simpler life.

- Lift, like its host language Scala, is designed for HEAVY LIFTING. Its
priorities are delivering security, maintainability and performance over the
widest possible range of applications. It makes obtaining these good things
as simple as possible, but occasionally you just have to eat your greens if
you want to grow up big and strong.

Those are the rationales behind the design choices we made. Creating your
first toy site with Lift will take longer than with Rails, but creating your
first secure, scalable site will take less time. Whenever Lift wants you to
do something particularly surprising in this tutorial you'll see another box
explaining why and what the pay-off will be for you. You'll also see boxes
warning you of any fiddly 'gotchas'. Happy Lifting!

Lightly adapted that might work as an intro for Lift in general. It
*differentiates* you from Rails and gives potential users the info they need
to decide whether or nor Lift is right for them to try, which is what
technical marketing should be about. (It also obeys the "tell them three
times" rule of Writing Stuff You Really Want People To Remember.")

Oh - and I have now seen the Lift logo, and I think it looks fine!

-- 
View this message in context: 
http://old.nabble.com/superficial-first-impressions-from-a-rails-junkie-tp27802055p27811402.html
Sent from the liftweb mailing list archive at Nabble.com.

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

Re: [Lift] Re: superficial first impressions from a rails junkie

[Timothy Perrett]

Business wise, rails / php etc are not even on the same scale as lift. Rails / 
PHP etc are cheap, easy ways to deploy *sites*. Lift is for building serious 
*web applications*. there is a distinct difference... and yes, for these 
reasons no doubt the higher cost of deployment will scare some people off, but 
personally, im not too worried about that as its not the kind of people we 
want. That is not to say those people aren't smart and pragmatic, rather, its a 
case of "horses for courses"... and Lift quite possibly isn't the weapon of 
choice for an agency just banging out dynamic sites.

If however, you want to build a proper web application, you'll quickly out-grow 
rails and friends. This is where Lift shines. The issue is not a technological, 
its a business one - Lift will ultimately be cheaper to maintain, less 
error-prone, cheaper to scale and a bunch of other good stuff. None of this 
stuff matters to the person who wants £5.99 hosting, so Lift is totally the 
wrong tool for them.

Your making the mistake of assuming that we want mass-market share. That is not 
to say we don't want to grow, but it has to be the right type of growth... for 
the right reasons, and in the right areas. 

Cheers, Tim



On 7 Mar 2010, at 02:09, cageface wrote:

> I think you're making a common programmer's mistake of assuming the
> people that value aesthetics aren't capable of making deeper
> distinctions. The working web programmer that wants to move beyond
> Rails/Django/PHP has a ton of options right now and is much more
> likely to pick something that looks polished and ready to use and not
> like yet another impractical academic exercise. If your intent is to
> scare people like that away you're probably succeeding but that also
> means that people like that aren't trying Lift out on little test
> sites, then bigger sites, then selling it to management and adding to
> your list of success stories.
> 
> Who knows, maybe your strategy of growing Lift top-down with the
> eggheads will pay off. TBH it sounds disturbingly reminiscent of the
> kind of ivory tower arguments I've heard functional programming
> apologists make for many years now.

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

[Timothy Perrett]

We are currently on version 2.0-M3. Its stable, and production ready... we keep 
our snapshots very stable and you shouldnt get any problems using it.

Cheers, Tim

On 7 Mar 2010, at 03:10, Martin wrote:

> I notice the last production quality release was over a year ago; I do
> notice there have been much more frequent updates to say the wiki and
> the work on the 1.1 milestones. It just seems strange that a minor
> release on such a young project would taking such a long time. This is
> a completely naive view of what is going on, and this is why i post
> this query because I want to be disproven so I can feel comfortable
> suggesting the use of this framework for the long term.

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

[Lift] Re: superficial first impressions from a rails junkie

[cageface]

On Mar 6, 5:28 pm, David Pollak  wrote:
> Back in 2005-2006 Ruby and Rails were not easy to
> get started with.

My first Rails checkins in our VCS are from 2004. I had no trouble at
all getting things running back then and don't remember hearing a lot
of complaints about this from other quarters either but I do remember
that getting a lot of Unix-y software to build on Macs at the time was
a real bitch so that may have been a factor in your experience.

> DHH promoted Rails too early in my opinion.  VeriSign adopted Rails for some
> projects and after deploying those projects and then paying Zed Shaw to
> write Mongrel, VeriSign dumped Rails.

Reasonable people could disagree about this. Who knows. I think if
you've got a hardcover book out on Lift though the horse has left the
gate.

> Another failing of Rails is the community.  The Rails community is a
> significant detractor to adoption outside of the young hip kids.

I wish I could disagree with you about this.

> The way you come across is "whatever isn't Rails is bad and everything that
> is Maven is bad."  It will never be my goal to convince folks with that kind
> of mind set to use Lift.

That's not where I'm coming from at all. I have a lot of misgivings
about the direction Ruby and Rails are taking. In fact it's the reason
I've been dabbling with a lot of alternatives lately. There are a
bunch of architectural decisions in Rails I've never been happy about.

> You did not discuss Lift's Ajax stuff in your review.  Instead of having to
> change 2 or 3 files for each Ajax request as in Rails, you only need change
> 1.

I ran out of steam before really getting into that stuff and I have
some very bad associations left over from RJS with server-side
shortcut syntax for AJAX but I'd have to take a closer look at what
Lift is doing.

> At this point, I see this as a feature.  Anyone who is going to evaluate
> Lift purely on the looks of the HTML on the getting started guide, is not
> likely to fit into the community.  This may seem like a jerky thing to say
> and may seem like it feeds into your concern about the anti-marketing
> functional language folks.  It's not.  I'd prefer people who will do some
> substantive evaluation of Lift... maybe spend a whole day on it rather than
> simply looking at the docs and say, "these guys can't make it pretty... they
> must be morons."

I think you're making a common programmer's mistake of assuming the
people that value aesthetics aren't capable of making deeper
distinctions. The working web programmer that wants to move beyond
Rails/Django/PHP has a ton of options right now and is much more
likely to pick something that looks polished and ready to use and not
like yet another impractical academic exercise. If your intent is to
scare people like that away you're probably succeeding but that also
means that people like that aren't trying Lift out on little test
sites, then bigger sites, then selling it to management and adding to
your list of success stories.

Who knows, maybe your strategy of growing Lift top-down with the
eggheads will pay off. TBH it sounds disturbingly reminiscent of the
kind of ivory tower arguments I've heard functional programming
apologists make for many years now.

-- 
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] Customizing meta fields

[Martin]

How would one go about having dynamic description and keyword meta
tags in a template? Here is what i've tried:

default.html


HelloWorld.scala
Helpers.bind("b", in, "time" -> date.map(d => Text(d.toString)),
"meta_desc" -> "test desc")

I'm using a basic archetype build of 2.0-M3 and it produces an error:

This page contains the following errors:

error on line 6 at column 28: Namespace prefix b on meta_desc is not
defined
Below is a rendering of the page up to the first error.


It appears to me that the template is not parsed by the Helpers.bind,
is this correct?

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

[Martin]

Hey,

First of all, let me take the complete opposite stance observed from
one of the most reason posts from a "Rails Junkie". I'm very excited
to see a framework that takes the good from so many different projects
and houses it under a language that does the same. I find it
refreshing to have the powerful tools developed around Java available
for development in this new Scala language and the Lift framework. No
matter how much one hates the design choices and the verbosity of the
most popular platform in our lifetime, it is only a benefit that we
have access to the years of effort devoted to it. The powerful
compiler behind Scala is my sole reason for preferring it to ports
like JRuby and Groovy.

Now to the point of my query, what is the activity and excitement
levels around lift at this point? I understand that money drives the
world and to make a framework successful one must market like Rails
and make some bank to promote future maintenance and improvements.

I notice the last production quality release was over a year ago; I do
notice there have been much more frequent updates to say the wiki and
the work on the 1.1 milestones. It just seems strange that a minor
release on such a young project would taking such a long time. This is
a completely naive view of what is going on, and this is why i post
this query because I want to be disproven so I can feel comfortable
suggesting the use of this framework for the long term.

Thanks for letting me take some of your time away from more important
things :). I just figured seeing this was a question in my mind,
others thinking about using the framework might have the same
question.

-- Martin

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