[Lift] Customizing meta fields
How would one go about having dynamic description and keyword meta tags in a template? Here is what i've tried: default.html meta name=descriptionb:meta_desc //meta 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
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.
[Lift] Re: superficial first impressions from a rails junkie
On Mar 6, 5:28 pm, David Pollak feeder.of.the.be...@gmail.com 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.
Re: [Lift] Activity
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.
Re: [Lift] Re: superficial first impressions from a rails junkie
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.
[Lift] Re: [lift] superficial first impressions from a rails junkie
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] Re: Lift security vulnerability
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 olearydani...@gmail.com 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 olearydani...@gmail.com 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 naftoli...@gmail.com wrote:
Can you reproduce the vulnerability in your own M3 app?
-
Danoolearydani...@gmail.com 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 dri...@gmail.com 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?
-
Danoolearydani...@gmail.com 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 olearydani...@gmail.com 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 olearydani...@gmail.com 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 olearydani...@gmail.com 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 feeder.of.the.be...@gmail.com
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 sharpzh...@gmail.com
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
indraj...@gmail.com
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. Forcing apps to move to 2.0-M2 just for this
vulnerability fix isn't fun.
Cheers, Indrajit
On 03/02/10 3:34 PM, Timothy Perrett wrote:
+1
Fix it in head, no need to back-port; M2 is only around the
corner.
Cheers, Tim
On 3 Feb 2010, at 09:49, Jeppe Nejsum Madsen wrote:
[Lift] Js normalizations
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.
Re: [Lift] Js normalizations
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] IdPK Model boiler-plate
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] toForm function passing problem ... ?
On Sun, Mar 7, 2010 at 9:54 AM, hexa hex...@gmail.com 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 and
(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.comliftweb%2bunsubscr...@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
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 anth...@whitford.com 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.comliftweb%2bunsubscr...@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] Re: [lift] superficial first impressions from a rails junkie
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 umpti...@gmail.com 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.comliftweb%2bunsubscr...@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: Js normalizations
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 mads...@gmail.com 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: Js normalizations
Can it be changed with a deprecation phase? - Mariusmarius.dan...@gmail.com 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 mads...@gmail.com 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.
Re: [Lift] Re: [lift] superficial first impressions from a rails junkie
I think that Jonathan was impolite in expressing his frustration at being misunderstood. But are his points not valuable? - David Pollakfeeder.of.the.be...@gmail.com 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 umpti...@gmail.com 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.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit
[Lift] Re: Js normalizations
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 naftoli...@gmail.com wrote: Can it be changed with a deprecation phase? - Mariusmarius.dan...@gmail.com 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 mads...@gmail.com 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: Js normalizations
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. - Mariusmarius.dan...@gmail.com 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 naftoli...@gmail.com wrote: Can it be changed with a deprecation phase? - Mariusmarius.dan...@gmail.com 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 mads...@gmail.com 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
You must be unique :) On Mar 7, 10:21 pm, Naftoli Gugenheim naftoli...@gmail.com 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. - Mariusmarius.dan...@gmail.com 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 naftoli...@gmail.com wrote: Can it be changed with a deprecation phase? - Mariusmarius.dan...@gmail.com 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 mads...@gmail.com 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.
[Lift] Reorganize mapper specs?
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.
Re: [Lift] Re: Js normalizations
I may have a project coming up that would use it though. :) - Mariusmarius.dan...@gmail.com wrote: You must be unique :) On Mar 7, 10:21 pm, Naftoli Gugenheim naftoli...@gmail.com 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. - Mariusmarius.dan...@gmail.com 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 naftoli...@gmail.com wrote: Can it be changed with a deprecation phase? - Mariusmarius.dan...@gmail.com 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 mads...@gmail.com 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] Re: IdPK Model boiler-plate
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 feeder.of.the.be...@gmail.com 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.
[Lift] LongMappedForeignKey should call primeObj in apply(v: O) and apply(v: Box[O])
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] Customizing meta fields
To be parsed by the bind, it must be enclosed by
lift:HelloWorld.hello.../lift:HelloWorld.hello
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:
meta name=descriptionlift:HelloWorld.meta_desc //meta
class HelloWorld {
def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)
}
Which will result in this XHTML:
meta name=descriptiontest desc/meta
Or, if you want to keep it in the hello method, you'd then have to move the
lift:HelloWorld.hello to the outside of the template:
lift:HelloWorld.hello
...
head
meta name=descriptionb:meta:desc //meta
/head
...
b:time /
/lift:HelloWorld.hello
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
meta name=descriptionb:meta_desc //meta
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.
Re: [Lift] Customizing meta fields
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 lift:xxx 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:
lift:meta_descThis site is totally awesome, better than all our
competitors/lift:meta_desc in index.html
lift:meta_descLook at all these products in
%%category_name%%/lift:meta_descin product_list.html
lift:meta_desc%product_name% - %product_description%/lift:meta_desc
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. lift:HelloWorld.hello 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 lift:HelloWorld.funcName / 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 dri...@gmail.com wrote:
To be parsed by the bind, it must be enclosed by
lift:HelloWorld.hello.../lift:HelloWorld.hello
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:
meta name=descriptionlift:HelloWorld.meta_desc //meta
class HelloWorld {
def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)
}
Which will result in this XHTML:
meta name=descriptiontest desc/meta
Or, if you want to keep it in the hello method, you'd then have to move the
lift:HelloWorld.hello to the outside of the template:
lift:HelloWorld.hello
...
head
meta name=descriptionb:meta:desc //meta
/head
...
b:time /
/lift:HelloWorld.hello
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
meta name=descriptionb:meta_desc //meta
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
Re: [Lift] Customizing meta fields
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 Lynessmartin.lyn...@gmail.com 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 lift:xxx 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:
lift:meta_descThis site is totally awesome, better than all our
competitors/lift:meta_desc in index.html
lift:meta_descLook at all these products in
%%category_name%%/lift:meta_descin product_list.html
lift:meta_desc%product_name% - %product_description%/lift:meta_desc
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. lift:HelloWorld.hello 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 lift:HelloWorld.funcName / 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 dri...@gmail.com wrote:
To be parsed by the bind, it must be enclosed by
lift:HelloWorld.hello.../lift:HelloWorld.hello
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:
meta name=descriptionlift:HelloWorld.meta_desc //meta
class HelloWorld {
def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)
}
Which will result in this XHTML:
meta name=descriptiontest desc/meta
Or, if you want to keep it in the hello method, you'd then have to move the
lift:HelloWorld.hello to the outside of the template:
lift:HelloWorld.hello
...
head
meta name=descriptionb:meta:desc //meta
/head
...
b:time /
/lift:HelloWorld.hello
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
meta name=descriptionb:meta_desc //meta
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
[Lift] Re: Response Optimizations too aggressive
On Mar 4, 9:50 am, David Pollak feeder.of.the.be...@gmail.com wrote: On Thu, Mar 4, 2010 at 9:27 AM, aw anth...@whitford.com wrote: On Mar 4, 6:56 am, Naftoli Gugenheim naftoli...@gmail.com 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] Re: [lift] superficial first impressions from a rails junkie
On Sun, Mar 7, 2010 at 12:15 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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 Moorehttp://mdv.com/team_bio.html?id=11and 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 http://twitter.com/dpp which contains a link to my blog http://blog.lostlake.org/. Now, let's take a look at the Lift http://liftweb.net 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
[Lift] Re: IdPK Model boiler-plate
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 a href=http://www.hibernate.org/109.html;Best
strategies for
* implementation of equals() and hashcode() in your persistent
classes./a
*/
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] Activity
On Sat, Mar 6, 2010 at 7:10 PM, Martin martin.lyn...@gmail.com 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.comliftweb%2bunsubscr...@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] Js normalizations
On 7 March 2010 19:37, Marius marius.dan...@gmail.com 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.
