Re: [Lift] Need for lift application to coexist with spring in the same webapp
Don't forget that if the lift filter is inspecting the request before your servlet, you'll need to tell lift to pass it on. In boot: LiftRules.passNotFoundToChain = true chris sunanda wrote: Hi David, Thank for all the help so far. My lift application needs to coexist with the spring servlet in the same web application. I have configured the web.xml file for both of the spring servlet and lift filter. Hence I need to configure the url pattern in such a way that /grid/* request will be handled by lift application and other urls will be processed by spring. What I need to understand is how to set up the rules such that this can be achieved. -- You received this message because you are subscribed to 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] labels for inputs
Thanks Naftoli, that did it. I wonder, why use a new method -% for attribute preservation? Naftoli Gugenheim wrote: This was changed. Instead, with the regular arrow - attributes are not preserved at all, and a new arrow was introduced -% that preserves all attributes from the template as is. This is in addition to being able to pass attributes to many SHtml methods; being able to add attributes to the returned NodeSeq; binding on attributes; and attribute snippets. - Chris Lewisburningodzi...@gmail.com wrote: Hello list, I was looking for a way to attach label elements to form inputs (via DOM id), and I came across this thread: http://www.mail-archive.com/liftweb@googlegroups.com/msg04821.html This suggests that bind points, when expanded, result in elements that have any attribute under the bind point namespace merged into the result element. This isn't working in 1.1-M7, unless I'm misunderstanding something. Given this template code: lift:Order.allOrders tr tdorder:status order:id=status//td /tr /lift:Order.allOrders I should see a DOM id of status on the resulting element, right? Instead it's just ignored. Am I doing something wrong? thanks! chris -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
Re: [Lift] opening new window from snippet.
I'm not sure what you mean exactly. If you have a link on a page that
wants to open in a new window, just specify that in the template html:
a href=/home target=homeHome/a
If you're wanting to wire up some ajax behavior to fire when a link is
click and then open a window, you have several options. Here's one:
the snippet:
class Snippet{
def snippet(xhtml: NodeSeq): NodeSeq = {
def runThenOpen(): JsCmd = {
println( ajax handler )
JsRaw(window.open('http://foo.com/home', 'fooWin'))
}
bind(page, xhtml,
link - SHtml.a(runThenOpen _, Text(Home))
)
}
}
Now the template code:
lift:Snippet.snippet
page:link/
/lift:Snippet.snippet
When you run this and click on the link, server side code in the handler
runThenOpen will execute, and then the server will send back some
javascript to the client, which tells it to do a pop up.
I'm not sure why you'd do this, but that's how you can.
sincerely,
chris
jack wrote:
I want to put a link in a snippet that opens up a web page in a new
browser window. What is the best way to do this?
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
Re: [Lift] JPA and eager fetch
No, CascadeType.ALL should work as expected. By chance does replacing
the use of Model.persist with Model.mergeAndFlush work as you'd expected?
Warren Strange wrote:
OK, I think I fixed my problem
I did not call Model.persist on my linked child object. I thought the
cascade = ALL would take care of that, but apparently not? It seems
to work fine now.
Thanks
Warren
On Fri, Nov 20, 2009 at 2:36 PM, Warren Strange
warren.stra...@gmail.com wrote:
OK - just a quick follow up.
I got a chance this afternoon to test the simple demo app that
Jean-Luc suggested. I changed the mapping on books to be
fetch=EAGER. and put a debug statement on the list method in
authorOps. Of course it works just fine :-) - so the problem lies
somewhere else in my code.
I'll keep digging.
Warren
On Fri, Nov 20, 2009 at 12:48 PM, Warren Strange
warren.stra...@gmail.com wrote:
Jim and Jean-Luc - thanks so much for your offer of assistance.
It might take me a while to put together a buildable sample. I'm just
learning lift and scala right now. This is not a critical problem for
me, and I can work around it. When I have something I will post a
follow up.
Warren
On Fri, Nov 20, 2009 at 12:26 PM, Jean-Luc jlcane...@gmail.com wrote:
Your mapping looks like normal.
If you provide a buildable project, either tgz or link to github.com, I may
be able to reproduce your problem and help you identify the issue.
Jean-Luc
PS : If you need a git project to fork, I just prepared
http://github.com/jlcanela/scalajpademo (based on the maven scalajpa
archetype)
2009/11/20 wstrange warren.stra...@gmail.com
Newbie Lift / JPA alert!
I am sure I am doing something dumb here, but I can't quite figure it
out. I have a JPA project (modelled after the lift JPA demo app).
I have an object with a one-to-many association, and I want to eager
fetch the collection. It is declared like :
@OneToMany(){ val targetEntity = classOf[OpenIdUser], val cascade =
Array(CascadeType.ALL), val fetch=FetchType.EAGER}
var openIds : _root_.java.util.Set[OpenIdUser] = new
_root_.java.util.HashSet[OpenIdUser]()
In my spa persistence unit, eager fetching works fine from the unit
test. The unit test uses plain old emf factory instances.
However, from my web application (run with jetty:run) and using
Model.createNamedQuery, or Model.find, only the parent object is
fetched. The collection is not.
I gather this has something to do with the way that Model works? Or
are my annotations being ignored when they are packed in a .jar file?
Clues would be appreciated.
Thanks
Warren
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
--
Jean-Luc Canela
jlcane...@gmail.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=.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
Re: [Lift] Mapper vs. Record vs. JPA
I'm writing an app to deploy to googele app engine, and so I'm using JPA. Here are the cons I've encountered: 1) JPA mandates conventions on model class code. In scala this usually means any persistent fields are public vars, which is theoretically dangerous (and generally frowned upon). I personally have mixed feelings on mutability in domain entity classes (Mapper entities are also mutable), and there is ongoing discussion on this topic. 2) Collections in JPA are java.util, not scala. This means that you can't transform them as you can with the usual higher order functions found scala collections (map, filter, etc), unless you use implicit conversions (usually via jcl). Implicits make your code feel like scala code, but I'm not a fan of having conversions rampant for this, and I don't like to explicitly pollute my namespaces by importing jcl. 3) JPA is not monadic. JPA entities are from java land, and in java land you represent optional members with null. Idiomatic scala doesn't do nulls because they wreak havoc at runtime. Always. Consider an entity Person with a member middleName. In your domain it isn't required, and so you allow null at the database level. In a JPA impl you allow this to be null, and now everywhere you reference middleName, you absolutely must test for null. In scala you use the Option monad, so middleName is no longer of type String but Option[String]. NPEs are now effectively impossible. chris Oscar Picasso wrote: I am starting to (re)learn lift and wondering which persistence mechanism I should use: Mapper, Record or JPA? It should be ready for for prime time and fit perfectly with the lift / scala way of doing things but still be powerful enough. * I have read that Mapper has some limitations like when dealing with complex object graphs, many to many relationships etc. * I don't know Record but I have two concern with it: is it mature enough? I have read that David is not satisfied with Record especially on the mutability front. What are the practical implications of not having immutability for Record? * JPA: I practice it on a daily base and it's very good but I feel like there is between JPA and lisft / scala. Not that I have thought a lot about it, it's just a feeling. I have also read there are some issues with the Hibernate Validators. Could some people on the list be kind enough to summarize the pros and cons of using any of these solutions at this stage? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
[Lift] labels for inputs
Hello list, I was looking for a way to attach label elements to form inputs (via DOM id), and I came across this thread: http://www.mail-archive.com/liftweb@googlegroups.com/msg04821.html This suggests that bind points, when expanded, result in elements that have any attribute under the bind point namespace merged into the result element. This isn't working in 1.1-M7, unless I'm misunderstanding something. Given this template code: lift:Order.allOrders tr tdorder:status order:id=status//td /tr /lift:Order.allOrders I should see a DOM id of status on the resulting element, right? Instead it's just ignored. Am I doing something wrong? thanks! chris -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
Re: [Lift] Three years of a Scala lust affair, the blog post
David, Thank you for being so generous with your knowledge and experience, for your tireless efforts on Lift, and for always reaching out to newbies in the scala and lift communities. Several times you've answered my own questions directly, and your unwavering patience speaks volumes to your character. Thank you for your continued vision and effort on Lift and for fostering the Lift community. Also, the Beginning Scala book is great - an absolute must read for beginners (and I'd say ALL java programmers). I bought it after 4 or so months with scala, figuring I'd be passed what it had to offer. I was sorely wrong. Thanks again, Chris Lewis David Pollak wrote: Folks, I've been doing Scala for three years as of today. I wrote a blog post about it: http://blog.lostlake.org/index.php?/archives/97-Happy-3rd-Anniversay.html There are a lot of people to thank for making Scala the great thing it is today. Martin has led his EPFL team to bridge academia and commercial, vigorous debating and politeness, functional and object oriented to bring us Scala and the Scala community. It's been 3 years for me and I can't think of a better language or a better community than what Scala has evolved into. Thanks, David -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
[Lift] A sensible AJAX approach
Classic use case: a user chooses to view/edit and object by clicking on a link. This causes the app to fetch an edit view (form) and render it asynchronously, probably rendering it as a modal dialog. To specify the case a bit more, consider a table of like objects that allows you to edit them (orders or accounts). As far as the user experience, clicking edit for one would yield the same edit form as any other - only the contents (the target of the edit) would change. Normal ajax forms in lift are simple - just wrap the bind in an ajax form (http://is.gd/4Z61Z) and you get an async submit with essentially the same template code. But what about ajax forms delivered by ajax? What's the best way to implement this in lift? It seems like there are two routes: client and server-based. 1) In the client-based approach, I can declare an invisible form in the template, as well as write some static javascript to do the heavy lifting (no pun intended). This JS would be responsible for receiving the data representing the object to edit from the server as json, unpacking it into the form for editing, rendering the form, handling the submit as ajax, and finally hiding the form. This means writing a good bit more JS by hand, but it keeps the (compiled) snippet code smaller. Ordinarily I'd see that as good, but more and more snippets seem like they are intended for such heavy view meddling. 2) The server-based approach would require very little of the main template: basically just a containing element (w/ dom id) to host the delivered form. The snippet itself would yield a form on an ajax call via SetHtml. It would also have to set up the handlers and populate the form contents with the target object. This is the part that I'm not clear on. I know I can just inline the XML with bind points as if it were in a form, but that just feels strange. Would it make more sense to use an external template, similar to a rails partial? Is there a template loading facility for this? Thanks for any and all input. chris -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
Re: [Lift] A sensible AJAX approach
Thanks for the feedback Jeppe. I can't completely infer the context of
your example, but I get the idea (and I hadn't known about
TemplateFinder). Here's what I've hacked together so far.
In my normal snippet, I have a render loop that binds orders to template
names. One of the bind points looks like this:
..
label - SHtml.a(viewOrder _, Text(View)),
..
Here, viewOrder is a function called by ajax, so a () = JsCmd. I've
defined it as follows (assume i've imported TemplateFinder.findAnyTemplate):
def viewOrder(): JsCmd = {
SetHtml(order, SHtml.ajaxForm(
bind(order, findAnyTemplate(List(orders/_edit_order)).open_!,
orderNo - Text(order.orderNo),
submit - SHtml.submit(submit, () = println( -- submit!))
) ++ SHtml.hidden(() = println( -- submit!))
))
}
Using the usual ajaxForm technique, I wrap the result of a bind which
results in the contents passed to SetHtml. The funny part is that I
directly load a template file as a NodeSeq and use that as the arg to
bind. That template file doesn't call a snippet, but it uses the bind
points bound in the call - and it works! Here's the full _edit_order.html:
div
order:orderNo/
order:submit/
/div
It's just raw xml. No snippet calls, yet bind still processes it
correctly - even the ajax wiring! I think this is all in all a pretty
good way to handle the common-edit-dialog problem, and certainly the
cleanest I've seen yet. I wonder though, is it intentional that bind
points work when not explicitly wrapped in a snippet call tag?
thanks!
chris
Jeppe Nejsum Madsen wrote:
Chris Lewis burningodzi...@gmail.com writes:
Classic use case: a user chooses to view/edit and object by clicking on
a link. This causes the app to fetch an edit view (form) and render it
asynchronously, probably rendering it as a modal dialog. To specify the
case a bit more, consider a table of like objects that allows you to
edit them (orders or accounts). As far as the user experience, clicking
edit for one would yield the same edit form as any other - only the
contents (the target of the edit) would change.
Seems you're a few steps ahead of me. I'll be looking at basically the same
use case soon :-)
Normal ajax forms in lift are simple - just wrap the bind in an ajax
form (http://is.gd/4Z61Z) and you get an async submit with essentially
the same template code.
But what about ajax forms delivered by ajax? What's the best way to
implement this in lift? It seems like there are two routes: client and
server-based.
Agreed
1) In the client-based approach, I can declare an invisible form in the
template, as well as write some static javascript to do the heavy
lifting (no pun intended). This JS would be responsible for receiving
the data representing the object to edit from the server as json,
unpacking it into the form for editing, rendering the form, handling the
submit as ajax, and finally hiding the form.
This means writing a good bit more JS by hand, but it keeps the
(compiled) snippet code smaller. Ordinarily I'd see that as good, but
more and more snippets seem like they are intended for such heavy view
meddling.
Probably depends on the app. If it's mostly a single-url, js based app
this would work. Personally (and since I'm not a JS ninja :-) I try to
limit the amount of client side code to the where it makes sense. I
think the development experience (for me) is better with a statically
typed languagne (tdd etc).
2) The server-based approach would require very little of the main
template: basically just a containing element (w/ dom id) to host the
delivered form. The snippet itself would yield a form on an ajax call
via SetHtml. It would also have to set up the handlers and populate the
form contents with the target object.
This is the part that I'm not clear on. I know I can just inline the XML
with bind points as if it were in a form, but that just feels strange.
Would it make more sense to use an external template, similar to a rails
partial? Is there a template loading facility for this?
I've been doing this (external templates) and it works great. Very easy
for designers to modify layout etc.
Here's a simple example the changes several page elements when a select
is changed:
bind(select, in,
type - ajaxSelectObj(reportTypes, currentType.is,
(f:ResultF) = {
currentResult(Empty)
currentType(Full(f))
val nodeseq =
TemplateFinder.findAnyTemplate(List(tender, results)).open_!
SetHtml(comparison, resultComparison(tender,
chooseTemplate(lift, tender.result_comparison, nodeseq)))
SetHtml(summary, segmentSummary(tender,
chooseTemplate(lift, tender.segment_summary, nodeseq)))
})
)
Here the two elements are read from the same template file
Re: [Lift] scala eclipse plugin with lift
I can't say I enjoy eclipse for scala code, but did you make sure your project has the Scala Nature? Oscar Picasso wrote: Hi, I did import a new created lift project in a eclipse as a maven project. The project is recognized as a scala project but there is neither syntax syntax highlighting nor auto completion while it works fine, in the same workspace when I create directly a scala project with the scala eclipse plugin. Any idea? -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=.
[Lift] Re: Lift Scala style.
On a related note, I suggest that the lift community read through the general Scala style guide proposed by Daniel Spiewak. Lift set a few norms of its own; I'm wondering what the reaction of the core team might be to some of the suggestions. http://www.codecommit.com/scala-style-guide.pdf sincerely, chris Kris Nuttycombe wrote: Hi, all, This is just a starting point for debate with a hope of eventual consensus on something that's ultimately somewhat trivial matter. Since style is currently a topic of discussion on the main scala-users list, I thought it an appropriate time to bring it up. Lift is one of the most prominent, perhaps the most prominent Scala applications in current existence, and as such I think it has a significant role to play in exemplifying good Scala style. At the same time, Lift has also been developed over the course of its' developers familiarization with the language, and so it displays some occasional stylistic warts. At the same time, major changes coming with Scala 2.8, particularly named default parameters, may be something we want to take advantage of in ways that may have a substantial effect on usability of our APIs. I guess my general question is, how does the Lift community want to deal with the stylistic warts and naming inconsistencies, and how do we want to go about integrating some of these new features? In some cases, we may be able to use a strategy of giving some operations new names and deprecating the old, but in others this might lead to some really hacky looking APIs since we've already got good names, and changing their signatures might break a lot of code. Also, what are the big warts on Lift that ought to be resolved by renames or named/default parameters? Two naming issues that have come up recently in Lift internal discussions follow: First, Alex Boisvert suggested that S.init be renamed to S.doWith to have more consistency with Req and LiftSession. At least internally, I think that the consensus was that this wasn't necessarily appropriate. Second, I suggested the deprecation of the pattern of using apply() on AnyVar to provide setter functionality, since to me using something that looks like function application to do a mutation seems ill-conceived. My initial suggestion was to piggyback our functionality on the update() rewriting that is done by Scala, but on further reflection and David's feedback I realized that this would be even uglier since you'd have to use myRequestVar() = foo. So, what would folks think about defining the symbolic method := on both AnyVal and within the Mapper framework instead, with the goal of eventual deprecation of the apply style? Thirdly, I would like to propose that any marker traits (i.e. traits that declare no methods) within Lift either be sealed, or have the relevant methods tailored to the shared functionality they represent added (or both.) Match errors can be nasty, and sealing the traits (providing an extension point for users if need be) can help the compiler help us to eliminate that class of errors. Fourth, in compiling the Lift source I see far more warnings related to type erasure in match statements than I'm strictly comfortable with. My personal plan is to start working through these and eliminating them where possible, but in general I think that we as a community should start running all of our builds with all warnings enabled, and strive to eliminate them. The Scala type system can be complicated, but in my experience it is virtually always possible to avoid such warnings (and type unsafety!) with a bit of extra thought. The less we subvert the type system, the less likely we are to have unexpected errors. Kris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] JS event source in a server side handler
Hello list, Often in an AJAX handler I need to update something on the client side; usually a UI control that initiated the handler. The only way I know to handle this is to generate a DOM id in the snippet during a rendering call (like a bind() call in a flatMap over a dataset), look for that id in my handler, and then query up or down the DOM to find the corresponding UI component to tweak. It'd be nice if I could access the event source node in my handler. In a standard JS event handler, 'this' references the source element, and in some JS libraries like prototype, a method is added to the event object to access the source element. Given the current implementation, what's the best way to access the client side source of a UI event in a server-side handler? It seems like there'd be a cleaner way than what I'm doing. Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JPADemo 1.1-SNAPSHOT: id with auto-increment (MySQL or H2)
Troy,
I ran into the same problem. It seems to be a hibernate issue - that
archetype uses an older version of hibernate that breaks with mysql.
Change the version in your pom for hibernate (I don't remember the
latest, maybe 3.4GA). I meant to post this a while ago, as it cost me an
hour or more to figure out.
chris
Troy Noble wrote:
I'm not even sure this is a Lift issue, could be Hibernate or Scala...
but here goes...
I get one test failure in TestJPAWeb.scala when I use JPA with MySQL
(also confirmed with H2) with auto-increment id column.
@Entity
class Author {
@Id
@GeneratedValue(){val strategy = GenerationType.AUTO}
var id : Long = _
...
}
Note that I also tried adding @Column{val nullable = false, val
insertable = false, val updatable = false} per another JPA+Scala page
I read, just to see if it makes a difference. It didn't. I also
tried GenerationType.IDENTITY. No difference.
If I turn on showSql it appears that auto-increment columns are
getting included in the SQL statement for some reason such as:
insert into author (name, id) values (?, ?)
And I get an error indicating no value is set for column 2. The
Hibernate output using H2 database appears in spa/target/surefire-
reports/com.foo.jpaweb.model.TestJPAWeb-output.txt is as follows:
Hibernate: insert into Author (name, id) values (?, ?)
Oct 31, 2009 7:05:48 AM org.hibernate.util.JDBCExceptionReporter
logExceptions
WARNING: SQL Error: 90012, SQLState: 90012
Oct 31, 2009 7:05:48 AM org.hibernate.util.JDBCExceptionReporter
logExceptions
SEVERE: Parameter #2 is not set; SQL statement:
insert into Author (name, id) values (?, ?) [90012-121]
A similar problem was reported in Hibernate 3.2.4 but was fixed in
3.2.6... so I'm assuming version 3.3.1GA that Liftweb presently uses
should not be the source of this problem? That might not be a good
assumption. I was going to try to do a stand-alone Scala + JPA test
case apart from Lift, and then try with Java + JPA.
But before I go too far down that path, I wanted to make sure I'm not
doing something wrong or that it's not a lift issue.
This is very easy to reproduce if you start by downloading a clean
JPADemo as per the liftweb + JPA wiki page (or the liftbook example)
and change the top level pom.xml to include:
dependency
groupIdcom.h2database/groupId
artifactIdh2/artifactId
version1.2.121/version
/dependency
or for MySQL:
dependency
groupIdmysql/groupId
artifactIdmysql-connector-java/artifactId
version5.0.8/version
/dependency
And then change the following entries in the spa/src/main/resources/
META-INF/persistence.xml to target an h2 database instead of the
default derby:
property name=hibernate.dialect
value=org.hibernate.dialect.H2Dialect/
property name=hibernate.connection.driver_class
value=org.h2.Driver/
property name=hibernate.connection.url
value=jdbc:h2:testDB/
or if you want to use your local MySQL 5.0.x server instead (assumes
local DB named JPADemo exists, and is writable by user named lifdev
with password lift1234 (note the amp; is very important between the
username the password=):
property name=hibernate.dialect
value=org.hibernate.dialect.MySQL5InnoDBDialect/
property name=hibernate.connection.driver_class
value=com.mysql.jdbc.Driver/
property name=hibernate.connection.url value=jdbc:mysql://
localhost/JPADemo?user=liftdevamp;password=lift1234/
Then cd spa and type mvn clean install -Dscala.version=2.7.7
For what it's worth, if I open the H2 scheme with Squirrel SQL it all
looks happy from the schema creation side and has auto-increment in
the 'id' column. I can insert rows manually just fine. Similarly for
MySQL even for the newly-created tables 'author' and 'book'.
Thanks, Troy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: A Critique On Lift
I *think* you're referring to a thread I started some time ago: http://www.nabble.com/functional-newbie,-domain-entities-td22957479.html It turned out to be a lively discussion. On a related note, Jonas Boner gisted this in August: http://gist.github.com/173921 It's not full code, but it gives you an idea how an immutable data model might be composed and backed with JPA. There are pain points (java collections) and unanswered questions here (how will the JPA provider initialize such a class), but there's what I feel is a language-level issue. In Scala, if you want methods to immutably evolve an objects' state, then you must, as Jonas did, write your own setters that yield a new instance with the modification. Sounds like boilerplate to me, that's another topic. For the record, I'm not yet fully convinced of the gains in using immutability in a domain model. Domain entities represent the state of an application, and in many cases that changes frequently and naturally. Period. How and why those changes occur are often the result of human behavior (twitter, facebook). These behaviors are not functional in the mathematical sense (at least, not that we've discovered), and so I'm not clear on what we stand to gain in a typical domain model. Naftoli Gugenheim wrote: How hard can automatic save be? But how would immutable DAOs work? There was a thread, I think on scala-user, a long time ago discussing it, that pretty much concluded it would be very problematic. David weighed in and said after a long time he concluded that databases represent state. - Timothy Perretttimo...@getintheloop.eu wrote: Right, no one likes mutable anything :-) I kinda wondered why you haven't pushed forward any more with the current record implementation... can one assume that is why - because it didn't feel right? Some of this stuff is going to be fundamental to how we move forward - id love to perhaps discuss something that would be better than what we have already. Even if its just pie in the sky talk... Cheers, Tim On 22 Oct 2009, at 17:22, David Pollak wrote: I don't like mutable fields. I don't like manual saving. Dunno... it's hard to articulate... it just feels wrong in my tummy. Also, I want to be clear that I think Marius did a great job of cleaning up some of the problems with Mapper when he did Record... my comments are not a negative to him... there's just something unsatisfying about the whole approach. Bet that was less than helpful. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: A Critique On Lift
bob wrote: i believe that one of the best ways to learn a new programming language is to read software written in it when reading Scala code, I rarely say i don't understand how that works and when I do, there's usually a good explanation of it somewhere on the web. usually I find myself asking where is that defined? or what part of the language is that? Scala is not like, for example, BASIC, where you can look up FOR, IF/ THEN/ELSE. there's lots of individual and compound punctuation marks that are very difficult to search for online and in PDFs (try searching for !). Indeed, but even cursory survey of scala will reveal that scala has no operators, only methods. This leads the user to search for docs on type of instance on which the punctuated invocation is made. I don't see the confusion there. You could of course make an argument on implicits ... a lot of scala also relies on syntactic sugar, such as omitted types (no : T after a val/var/def); the dreaded underbar; operator overloading; and implicit conversions. you can hate on Java's verbosity (i know i have), but brevity has its own difficulties. On Oct 22, 11:44 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?. - tirotim.romb...@googlemail.com wrote: override def validations = validPriority _ :: super.validations funny, I had stumbled on exactly the same line of code when beginning. Took me more than a day to understand what's going on. Especially because when you copied code from the PDF version of the Liftbook/Lift getting started guide, it would mess up spaces, so I would keep loooking for a _:: operator. The Scala guys have really pushed it a bit hard on the use of the underscore. At least four different uses: - it for defining anonymous functions like above - default value - matching placeholder whose value is ignored - use for constructing setter method names boolean functions (empty_?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: catch a URL
Thanks for that link, however it doesn't seem like rewrite rules fire for paths that are mapped in the SiteMap. Can anyone confirm that? I could have the redirect point to a non-existing URL, and do logic + rewrite there. I'm curious though, are rewrites considered if the URL matches a page in the SiteMap? Jeppe Nejsum Madsen wrote: Chris Lewis burningodzi...@gmail.com writes: Hi list, I'm working on an appengine app, and need to store some user information. I authenticate the user with their google account, and I need to create their local entity only if it's their first time logging in. When a user logs in via google, they are redirected back to your app, to a URL of your choosing. My thought was to catch the request as it comes back and, if it's their first time logging in, create a User entity. My question then is how can I do this without: a) Using a snippet, called from the return landing page and emitting NodeSeq.Empty - hack. b) Using custom dispatch and then redirecting. That may work, but it's an unneeded round trip. Any thoughts? Thanks! Not sure if the landing page is static, has parameters etc and what you want to do afterwards. Assume you need to render some template and the landing page is not static (if it is you could just use a normal Loc) I would probably wrap the landing page in a RewriteRequest, and when a match is made, do the user creation/lookup thing and then just render the template. Tim wrote and article about rewriting http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework Also, I've been using the Locs from CRUDify as an example of how to do more custom-type Locs with rewriting. /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: catch a URL
Hi Tim, I don't specifically want to rewrite anything. What I want is to be able to run some initialization code when a specific page is requested. As I said, I'm writing a google app engine app that uses google's authentication service to auth users (using their google account). I'm instructing the auth service to returned the authenticated user to their home page, a page protected and mapped via SiteMap. However, if it's their first time logging in, I need to bootstrap them in my app. Rewriting was suggested by Jeppe, and I had thought that way might work. It doesn't seem to, b/c Lift doesn't appear to fire the rewriters on URLs mapped in SiteMap. I'm not married to the idea of rewrites to solve this problem, I just need a non-snippet way to solve it. -chris Timothy Perrett wrote: Chris, SiteMap deals with what pages you are saying should be visible. Here, I term page as the physical xhtml file that represents the stuff the users sees - its a file on your system. Rewritten URLs dont need to feature in SiteMap because lift is clever enough to know that the page you are rewriting to already has (or has not) been allowed access via sitemap. Sounds like your trying to add rewritten URLs to your sitemap? Cheers, Tim PS: Jeppe, thanks for the link recycling!! On 23 Oct 2009, at 16:43, Chris Lewis wrote: Thanks for that link, however it doesn't seem like rewrite rules fire for paths that are mapped in the SiteMap. Can anyone confirm that? I could have the redirect point to a non-existing URL, and do logic + rewrite there. I'm curious though, are rewrites considered if the URL matches a page in the SiteMap? Jeppe Nejsum Madsen wrote: Chris Lewis burningodzi...@gmail.com writes: Hi list, I'm working on an appengine app, and need to store some user information. I authenticate the user with their google account, and I need to create their local entity only if it's their first time logging in. When a user logs in via google, they are redirected back to your app, to a URL of your choosing. My thought was to catch the request as it comes back and, if it's their first time logging in, create a User entity. My question then is how can I do this without: a) Using a snippet, called from the return landing page and emitting NodeSeq.Empty - hack. b) Using custom dispatch and then redirecting. That may work, but it's an unneeded round trip. Any thoughts? Thanks! Not sure if the landing page is static, has parameters etc and what you want to do afterwards. Assume you need to render some template and the landing page is not static (if it is you could just use a normal Loc) I would probably wrap the landing page in a RewriteRequest, and when a match is made, do the user creation/lookup thing and then just render the template. Tim wrote and article about rewriting http://blog.getintheloop.eu/2009/5/3/url-rewriting-with-the-lift-framework Also, I've been using the Locs from CRUDify as an example of how to do more custom-type Locs with rewriting. /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: A Critique On Lift
My head just exploded. Twice. ngocdaothanh wrote: Because Lift's ad is so good. *boom* For example: Lift is the only new framework in the last four years to offer fresh and innovative approaches to web development. It's not just some incremental improvements over the status quo, it redefines the state of the art. If you are a web developer, you should learn Lift. Even if you don't wind up using it everyday, it will change the way you approach web applications. Lift can't be used without Scala. Is there a plan to implement Lift in Clojure, for example? :D *BOOM* On Oct 22, 3:47 pm, TylerWeir tyler.w...@gmail.com wrote: On Oct 22, 2:02 am, ngocdaothanh ngocdaoth...@gmail.com wrote: jlist9, This is a Lift group, but I have to say I feel the same about Scala. I had to ask for advice here:http://groups.google.com/group/liftweb/browse_thread/thread/a588f997a... Scala may help me to get my work done for the day. But I don't feel happy with Scala. Scala makes me feel I'm a slave all the day to machines (or Scala itself!). If it makes you feel like a slave, why are you using Scala at all then? On Oct 22, 2:13 pm, jlist9 jli...@gmail.com wrote: override def validations = validPriority _ :: super.validations This is a more of a comment about Scala than one about Lift - this does look cryptic to me. And this is just one of the simpler syntax that confuses people, who are new to the language. And I'm one of them. I understand that you don't have to learn all the tricks/syntax to start coding in Scala but you do have to understand it when you read source code of libraries written by someone with much more advanced language skills. In David's book he says After more than two years of coding Scala, ... My brain has finally stopped hurting. This sounds like a very high barrier to entry. I'm just wondering why Scala has to be so complicated. I'm sure a lot of things in Scala have their reasons but at the mean time I also suspect that many of the odd things are there to reduce typing, which is advertised as one of the advantages of this language - conciseness. (I could be very wrong due to my lack of understanding.) If the latter is true, I feel that I'd rather type a little more to make the code easier to read. Just feeling a little frustrated learning Scala. I think it's much easier learning Java. Not much surprise. Not sure if anyone shares my experience (and opinion, if there is one.) On Wed, Oct 21, 2009 at 3:56 PM, Randinn rand...@gmail.com wrote: http://localhost3000.de/2009/10/a-quick-glance-at-lift/ The site above is a blog post from a Rails developer, he had some good and bad things to say about Lift and since I do not know enough to debate with him I thought I'd post it here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: A Critique On Lift
jlist9 wrote: It's often hard to describe some (I'd say most) of the Scala syntax if you want to search for an answer online. I can't relate with that. I've been coding scala for 3-4 months, and I've never had any problem finding method definitions. Most of this probably had to do with that fact that I was reading through several language overviews and tutorials. It would be great if the eclipse plugin can tell you what the code is trying to do and what kind of syntax is that, for example, linking an operator back to a method name. I'll repeat: there are no operators in scala. Not a single one. linking an operator back to a method name doesn't make sense. Accept that _everything_ in scala, except methods, is an object, and as such adheres to its respective class contract. If you need to look up the meaning of an operator, all you need to know is the type on which it is being invoked. The only real complexity in this resolution then is introduced by implicits. On Fri, Oct 23, 2009 at 6:27 AM, bob rbpas...@gmail.com wrote: i believe that one of the best ways to learn a new programming language is to read software written in it when reading Scala code, I rarely say i don't understand how that works and when I do, there's usually a good explanation of it somewhere on the web. usually I find myself asking where is that defined? or what part of the language is that? Scala is not like, for example, BASIC, where you can look up FOR, IF/ THEN/ELSE. there's lots of individual and compound punctuation marks that are very difficult to search for online and in PDFs (try searching for !). a lot of scala also relies on syntactic sugar, such as omitted types (no : T after a val/var/def); the dreaded underbar; operator overloading; and implicit conversions. you can hate on Java's verbosity (i know i have), but brevity has its own difficulties. On Oct 22, 11:44 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: The last use of _, as in empty_?, is not a special scala meaning. As on Java, underscores can be part of an identifier. Scala takes advantage of this to combine letters and symbols in one name. These names, like empty_?, are a Lift convention, as well as ..._! for use-with-care methods. The scala library uses isEmpty. David, is it your original convention?. - tirotim.romb...@googlemail.com wrote: override def validations = validPriority _ :: super.validations funny, I had stumbled on exactly the same line of code when beginning. Took me more than a day to understand what's going on. Especially because when you copied code from the PDF version of the Liftbook/Lift getting started guide, it would mess up spaces, so I would keep loooking for a _:: operator. The Scala guys have really pushed it a bit hard on the use of the underscore. At least four different uses: - it for defining anonymous functions like above - default value - matching placeholder whose value is ignored - use for constructing setter method names boolean functions (empty_?) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: catch a URL
Great suggestions - thanks guys!
Jeppe Nejsum Madsen wrote:
Timothy Perrett timo...@getintheloop.eu writes:
Ah. In that case, does this help:
Menu(Loc(Some, List(some,page), Some,
EarlyResponse(() = {
// do some response here,
// return Empty if you dont want
// a response but a filter style
// intercept.
Empty
})
))
Does that help?
Or, if you just need to run some code before a template is rendered:
Menu(Loc(test, List(landing), test, Template{() =
println(Hit the template URL);
// Handle Empty case :-)
TemplateFinder.findAnyTemplate(List(mytemplat,index)).open_!
}))
/Jeppe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] catch a URL
Hi list, I'm working on an appengine app, and need to store some user information. I authenticate the user with their google account, and I need to create their local entity only if it's their first time logging in. When a user logs in via google, they are redirected back to your app, to a URL of your choosing. My thought was to catch the request as it comes back and, if it's their first time logging in, create a User entity. My question then is how can I do this without: a) Using a snippet, called from the return landing page and emitting NodeSeq.Empty - hack. b) Using custom dispatch and then redirecting. That may work, but it's an unneeded round trip. Any thoughts? Thanks! PS - will share my app engineified code soon. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Question about the Getting Started Guide
Maven stores artifacts in your local repository, which by default is in ~/.m2/repository. jli...@gmail.com wrote: Hello Indrajit and those who replied, thanks for all your help. Finally I got it working. It probably had something to do with the proxy in my work environment. BTW, do you know where maven stores those downloaded files? Tuesday, September 29, 2009, 10:49:20 PM, you wrote: Jack, maven-jetty-plugin belongs to the group org.mortbay.jetty, not org.apache.maven.plugins. This makes me suspect that your jetty plugin isn't configured properly. A minimal jetty plugin configuration would look like this: plugin groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId configuration contextPath//contextPath /configuration /plugin Could you please ensure this config under build - plugin section in your pom.xml and retry? Cheers, Indrajit On 30/09/09 10:09 AM, jlist9 wrote: I just tried it on another computer and got exactly the same error when running (below). I think something is broken. I checked the mvn output in the first run to create helloworld project and didn't see any mentioning of jetty... D:\Java\liftweb\workmvn jetty:run [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'jetty'. [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version c ould be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Sep 29 21:16:31 PDT 2009 [INFO] Final Memory: 1M/4M [INFO] On Tue, Sep 29, 2009 at 8:59 PM, Naftoli Gugenheimnaftoli...@gmail.com wrote: I had such an issue when it was confused about which version of Jetty. Is there any more detail? Try running with error details enabled (mvn -help should tell you how). - jlist9jli...@gmail.com wrote: Yes, I have a network connection. Maven downloaded some other components and the end result was BUILD SUCCESSFUL... On Tue, Sep 29, 2009 at 8:29 PM, Naftoli Gugenheimnaftoli...@gmail.com wrote: Do you have a network connection? The idea of maven is that it downloads whatever it's missing. On Tue, Sep 29, 2009 at 9:11 PM, jlist9jli...@gmail.com wrote: Hi, I'm new to Lift. I'm trying to follow the getting started guide to build the first simple demo.helloworld project. At the end of Maven command output I see BUILD SUCCESSFUL. However, when I run mvn jetty:run, I get error: The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version could be found I wonder if I need to manually install jetty? If so, is there any configuration instructions? Thanks Jack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: all page URLs appended with ;jsessionid=knq01t90ajh7
It has nothing to do with lift, but the servlet container. jsessionid is a specified standard, and appending it I *think* is part of the mandate when implementing the servlet api. That is to say, the automatic appending will probably occur on any servlet container. Google around and you'll find various ways people deal with it. Grant Wood wrote: The first time a browser visits my site, all the path-only URLs embedded in the requested page are being appended with what looks like a malformed query parameter containing the session id. for example: a href=/correct/path/ link/a is being rewritten: a href=/correct/path/;jsessionid=knq01t90ajh7 link/a What's odd is that it is also happening to img elements as well: img src=/s/images/site/light_blue.png / is being rewritten: img src=/s/images/site/light_blue.png;jsessionid=knq01t90ajh7 / This happens reliably if you clear the cache and all session data from your browser and visit any page in the site first. ANy subsequent pages are fine. The result is that links work fine (which is why I didn't notice the problem right away) but images and embedded media are broken. If you reload the page, the URLs are all fine. The ;jsessionid=session id Other facts: - It is NOT affecting URLs in CSS or js in external files. - It is NOT being added to URLs with a protocol and authority such as: http://www.foo.com/path/to/page (and it makes no difference if its an external link or not) - I first suspected that a script somewhere was doing this, however, disabling javascript in the browser causes no change. I verified this using curl.. the URLs are being altered on the server. - I'm on the latest 1.1-SNAPSHOT, but this has been happening for some time, possibly since I started my work on lift 6 weeks ago. I have been searching through lift code for jsessionid without luck, so hopefully David or someone knows exactly what part of the chain is causing this. Its certainly possible I'm doing this somehow, but I can find nothing that would come close to doing this in any of my snippets (or models or libs for that matter) Thanks for any insight, let me know what other information would be helpful. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: JPA with more than one front end (Maven! sigh...)
Charles F. Munat wrote: It's not the AS, it's the souped-up Tomcat (JBoss Web). All their examples are WARs. But sure, send an EAR along, Mr. Van Gogh. nice. Chas. Derek Chen-Becker wrote: Also, if you're loading this up in JBoss, it might make more sense to bundle the artifacts into an EAR, unless you intend for the two web modules to have completely separate persistence units (e.g. different DBs, etc). Maven has a nice plugin for doing EARs. I can send a sample pom.xml if you'd like. Derek On Thu, Sep 17, 2009 at 1:01 PM, Derek Chen-Becker dchenbec...@gmail.com mailto:dchenbec...@gmail.com wrote: JBoss includes its own JTA libs, so you need to set the scope to exclude the other ones or else they'll conflict. Generally with any JEE container you would need to do that, since JTA is part of the spec. What exactly do you mean by the objects are created, but none of the properties are saved? Is an insert occurring but no fields are saved? If it's transaction related it's almost always a binary outcome (works/doesn't work), not something in between, although I've seen enough oddities to know that there are always exceptions :P Derek On Thu, Sep 17, 2009 at 12:03 PM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: Actually, I figured that out. They're included. But I have a different problem now -- one that you might know the answer to. I'm loading this war file up in JBossWeb (basically a hopped-up Tomcat) and when I try to use it, I get a problem with transactions. I assume this is something in the JBossWeb server, since I have nothing in my code to cause that. Something on the server wants that jta.jar in there. So I tried commenting out the javax.transaction exclusion in the pom.xml file for the spa project, and that added the jta jar to the lib, as expected. That also solved the problem with the server. But now when I merge objects to the database, the objects are created, but none of the properties are saved. It's very strange. I am wondering if this is a transaction issue. And just out of curiosity, why is the javax.transaction exclusion in there? I've often wondered about that. Chas. Derek Chen-Becker wrote: Are you sure that they're not getting included (e.g. not actually in the WAR file), or that they're not activated? If your dependency (in the web modules) on the spa module is default scope, then it should be including them. Derek On Wed, Sep 16, 2009 at 10:32 PM, Charles F. Munat c...@munat.com mailto:c...@munat.com mailto:c...@munat.com mailto:c...@munat.com wrote: I have a Lift project with a JPA backend subproject, and then two Lift front ends that access the same back end, also as subprojects. So my master pom.xml looks like this: modules moduleweb/module moduleweb2/module modulespa/module /modules Works beautifully. Web responds on one port and Web2 on another (when I use the internal Jetty). But when I do mvn package and put the war on the server, somehow the spa backend classes do not get included. Any idea what I'm doing wrong? Chas. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: CMS for Lift?
javax.script glenn wrote: I think the trick to a really vibrant CMS is the ability to create plugins - modules in Lift that can be dynamically installed. I'm not sure how to affect this except through OSGi. On Aug 19, 8:55 am, TylerWeir tyler.w...@gmail.com wrote: Wonderful! On Aug 19, 11:03 am, David Pollak feeder.of.the.be...@gmail.com wrote: FWIW... I got roped into hosting a CMS by the PTA of my kids' school. I may knock something together in Lift or leverage off the work Glenn has done. On Tue, Aug 18, 2009 at 3:26 PM, Timothy Perrett timo...@getintheloop.euwrote: Just my two cents, but I wouldn't use the lift namespace... If you use the lift tags OOTB, you risk designers shoving lots of comet actors on a single page. You would get more granular control if you created a special set of tags: cms:something .. / Cheers, Tim On 18/08/2009 23:00, Ewan ehar...@gmail.com wrote: I've been scratching my head about that one too. I have used both Alfresco and opencms to produce both dynamic and static and in the case of dynamic they have their own servlet/filter to render the content - I've not yet spent enough time working out how and if they can be fitted together. For me, having used Hybris (J2EE ecommerce engine with some CMS built in), I'd like to be able to have page fragments in a template served from the CMS (lift snippets presumably) that would be created/ maintained with some aspect of workflow by CMS user(s) in an associated CMS lift webapp with funky (X)HTML editor support. My web guys, non-lift devs, can then sprinkle cms tags where appropriate. A tag might be lift:cms contentId=news count=5 order=ascending/ which would render the last five news items in ascending order. Just some thoughts -- Ewan On Aug 18, 10:09 pm, Terry J. Leach terry.le...@gmail.com wrote: I would like to know how the Lift/Scala can leveraged to with Alfresco or any other open source Java based CMS. Terry J. Leach On Aug 17, 2:09 pm, Stefan Scott stefanscottal...@gmail.com wrote: I'll chime in here since I've been evaluating several CMSs lately. I previously used Drupal and WordPress as my CMSs - now however I'm moving everything to MODx because of the increased flexibility and more-logical organization, and I'm also impressed with the demos of SilverStripe, TypoLight Typo3 - and LifeRay, which is written in Java instead of PHP. (LifeRay seems to be much more than a CMS - it claims to offer collaboration and social networking.) Some on-line demos here: MODx -http://trymodx.com/ SilverStripe -http://demo.silverstripe.com/ TypoLight -http://www.typolight.org/demo.html Typo3 -http://testsite.punkt.de/ LifeRay -http://demo.liferay.net/web/guest/home It would be good to take a look at these additional CMSs as they offer some capabilities beyond WordPress and Drupal. Drupal in particular is wildly popular but it may no longer be the best candidate to imitate, as it is less well-organized and less flexible/customizable (compared say to MODx, which lets you take CSS from an existing site and use it for your site, and which lets you apply a template to a single document, unlike Drupal where a theme applies to the entire site). To keep up with advanced CMSs, Drupal has evolved to use a bunch of (often redundant or competing) modules which are not always compatible with current releases. Examples of things that Drupal treats as add-ons (modules) are: custom content (the CCK/Views modules, with their confusing albeit AJAX-y interface), multi-language, and photo galleries (I gave up on Drupal after a few days of trying out various photo gallery modules, none of which I could understand). Finally, it seems odd that Drupal, as a content management system, lacks something all advanced CMSs have: a *treeview* of the overall site content. Instead, it only has a jumbled *list* of content, sorted by not by location but by last edited (!), with all translations also scattered through the list based on last- edited date, and this list is buried several levels deep in the admin navigation system, unlike the site content treeview navigator which is prominently displayed (usually on the left) in advanced CMSs. (Of course, I don't want to veer off-topic here and start a CMS flame war here in this liftweb discussion. :-) Regarding dynamic site map creation - I do know that MODx has something like this, using WayFinder to create a menu from selected branches of the site's document tree, automatically including any updated sub-branches, and I believe most other advanced CMSs have something like this too. LifeRay seems very intriguing - it claims to do a lot beyond just CMS. Since it's written in Java (not PHP), who knows if some of its code could be leveraged in Scala. So these might be some additional interesting CMSs to keep in mind (beyond Drupal and WordPress) when building a new CMS using liftweb. - Stefan Scott On Aug 16, 3:13 pm, glenn
[Lift] Re: Dependency Injection in Lift
Jeppe Nejsum Madsen wrote: Chris Lewis burningodzi...@gmail.com writes: Take a payment service example. I start off with PayPal and some months later I switch my processor to CyberSource. I don't want to tie the snippet to a specific processor, so my mind, transposing java, says to write a payment service interface and implementation (of course there's a DI container that manages the wiring). In scala, if I mixin a trait that provides the payment service implementation, I still have to change the trait being mixed in if I want a different implementation. But how is that different from e.g changing a bean name in a Spring configuration (it's been a while since I used Spring, things may have changed :-) How can it be tested with different implementations? I change the trait being extended when I run tests, then change back for deployment (that is, change the actual source)? A spring context isn't compiled into the code, so I can simply change the context being used and I have my different implementations. I DO NOT want this. I want to understand the trait example as I'm sure I'm missing something. David's explanation of the architecture of S and LiftRules was convincing, and I'm sure I could be convinced on the trait issue if I could see an exmaple that proves it's not a maintenance nightmare. That, or have the trait itself resolve the implementation, which is plumbing that would have to be repeated per dependency-bearing trait. I you need the same dependency injected in several places, you could create a Configuration trait that holds all your dependencies (akin to the Spring context). Granted, this will provide all your services to all snippets, which seems less than ideal. This is an interesting discussion, and I'm still pondering at a good solution to the above. /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Dependency Injection in Lift
Timothy Perrett wrote:
Chris,
I read your comments with interest - just to clarify, are you against
changing code / would prefer a configuration file? I sort of got that
vibe from some of your posts... Personally, im not down with
configuration files and prefer code that configures code.
No, I prefer wiring configurations to be in code. Certain artifacts
however, like localized strings or environmental configurations that
depend on the server (dev/qa/prod), seem better off externalized.
I suppose you got that vibe from the comment I made a bit earlier, about
needing to recompile to reflect a change in a dependency configuration
upstream (in a trait). That was a vague comment rooted in my ignorance
of the apparently late binding of calls on trait methods. More on that
later.
Some of the systems i've got actually use a pattern very similar to
what DPP detailed - it works fine for me as I use specs and mokkito to
do testing - have you seen those?
DPP's explanation of how to mock infrastructure code (bound to S, etc)
made since, but it still feels a bit sketchy. Again, this may be my
misunderstanding, but he's saying to do something like replace the value
of the function S.redirectTo, so I can test as needed. So here we go:
S.redirectTo = () = { println(redirect received); }
Now that value is overwritten. What if I was unit testing a bunch of
snippets, some of those snippets call the same global function, but I
need to do per-snippet recordings/inspections of those calls? Must I
reconfigure the values under S each time? What if I forget one?
I've seen Bill Venner's specs - haven't used it but it looks cool. I've
not heard of mokkito (and didn't see a relevant link on google), so I
don't know how these tools might help here. Do share :-)
sincerely,
chris
Cheers, Tim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Dependency Injection in Lift
David, I'm still investigating options, but I wanted to restate my main issue simply. It is the requirement snippets have on global data; that is it. The way they receive data from and expose data to templates is really nice. However, without the use of global objects (including lift infrastructure like S, as well as application-level services), a snippet cannot do anything useful. Instead of expressing dependencies via constructor or function arguments, snippets must reach out. Calls to factories provide a way to ask for dependencies, but again binds the snippet to a specific factory (which in turn requires dependencies be configured such that a specific factory can provide them). I see this as problematic. I don't want spring in the mix, and I share the disdain for java annotations in scala - but there has to be a better way than globals. Thanks so much for your work and continued engagement. sincerely, chris Jeppe Nejsum Madsen wrote: David Pollak feeder.of.the.be...@gmail.com writes: Chris, I agree with Marius' comments. By using Scala's functions and partial functions, I have not found any need for Dependency Injection or many of the other Java limitation workaround patterns. Snippets are not associated in any way with persistence. Snippets can work any way you want and are not tied to a particular mechanism for storing data. Snippets are simply a way to transform XML to XML. David. I'm also struggling with some of these issues, mostly due to the fact that I need to supply mocks for testing and not so much because I crave another layer of indirection :-) I think what Chris was talking about was not so much that snippets are tied to any specific persistence mechanism, but more that many (most?) snippets, to do something useful, needs to access some functionality in the business logic. An using a static reference for this makes it difficult to swap BL implementations (ie with mocks). In an IoC container, those dependencies would be injected automatically to the snippet. I'm unsure how this could be implemented in Lift/Scala but would prefer to use the language itself. Chris already showed one possible solution with implicits, but I think there may be better solutions out there. I agree with you on your view on annotations :-) I feel I have a pretty good grasp on using FP in the small e.g for algorithms and data structures, but can't yet see how FP constructs (partial functions etc) can be used in the large e.g. for composing whole applications. Even more so when combining this with scala's powerful type system. Scala's traits used in conjunction with runtime logic singletons (e.g., LiftRules and S in Lift) mean that you don't need DI or other stuff. How can these things be used together? One of my issues wrt to testing lift apps is actually the use of these singletons. Much of my application code relies on these and requires an elaborate setup to test properly. I can of course extract my own traits for all the functionality that I use in S, LiftRules etc. but this seems like something that could be integrated into lift proper. I'll spend some more time on this and get back when/if I have some suggested improvements :-) I don't believe snippets need this kind of configuration if you follow the same patterns as we've followed with LiftRules and S. Could you briefly mention these patterns (or point to the code :-)? There's a lot of code in there and, while readable, I don't think I can distill the patterns yet /Jeppe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Dependency Injection in Lift
Ok, I had never looked at the source for S or LiftRules, but just poked
around in S and some dots connected. Assign different functions to the S
var members and you change functionality. Cool! Different than what my
mind defaults to, but so simple.
(You can see I have some baggage, and I am happy to let it go.)
Forgive my ignorance, and this issue probably has more to do with my
newness to scala rather than lift, but I don't see how your trait
example allows one to construct the snippet. Take a payment service
example. I start off with PayPal and some months later I switch my
processor to CyberSource. I don't want to tie the snippet to a specific
processor, so my mind, transposing java, says to write a payment service
interface and implementation (of course there's a DI container that
manages the wiring). In scala, if I mixin a trait that provides the
payment service implementation, I still have to change the trait being
mixed in if I want a different implementation. That, or have the trait
itself resolve the implementation, which is plumbing that would have to
be repeated per dependency-bearing trait.
This sounds messy and like a maintenance headache - I feel like I'm
missing your point here. I get the answer to mocking lift internals,
but hot-swapping service implementations without incurring a maintenance
hit is still unclear. Thanks again!
sincerely,
chris
David Pollak wrote:
On Tue, Sep 1, 2009 at 5:56 AM, Chris Lewis burningodzi...@gmail.com
mailto:burningodzi...@gmail.com wrote:
David,
I'm still investigating options, but I wanted to restate my main issue
simply. It is the requirement snippets have on global data; that is it.
The way they receive data from and expose data to templates is really
nice. However, without the use of global objects (including lift
infrastructure like S, as well as application-level services), a snippet
cannot do anything useful. Instead of expressing dependencies via
constructor or function arguments, snippets must reach out.
And where do these constructor parameters come from?
How is:
class Foo(snippetConstructors: XX) extends Snippet {
}
Any more abstract than:
class Foo with MyProjectState {
}
where:
trait MyProjectState {
def snippetConstructor: XX
}
Calls to
factories provide a way to ask for dependencies, but again binds the
snippet to a specific factory (which in turn requires dependencies be
configured such that a specific factory can provide them).
I see this as problematic. I don't want spring in the mix, and I share
the disdain for java annotations in scala - but there has to be a better
way than globals.
S is not global. Sure, it appears to be global, but it's not.
There's nothing magic about S. You can create your own.
You can also have a trait that configures itself on construction and you
can mix that trait into your snippets.
Either of these solutions gives you the ability to achieve your goals...
I'm not sure why you object to the S/factory paradigm. At some point,
the turtles end and you have to provide a mechanism for associating the
abstraction (trait/interface) with some concrete implementation. Why do
you view DI magic as a more satisfying mechanism for resolving abstract
to concrete? Personally, I find anything that's magic (rather than
concrete code that I can control, e.g., factory functions, partial
functions, etc. to be much more maintainable.)
Thanks so much for your work and continued engagement.
sincerely,
chris
Jeppe Nejsum Madsen wrote:
David Pollak feeder.of.the.be...@gmail.com
mailto:feeder.of.the.be...@gmail.com writes:
Chris,
I agree with Marius' comments. By using Scala's functions and
partial
functions, I have not found any need for Dependency Injection or
many of the
other Java limitation workaround patterns.
Snippets are not associated in any way with persistence.
Snippets can work
any way you want and are not tied to a particular mechanism for
storing
data. Snippets are simply a way to transform XML to XML.
David. I'm also struggling with some of these issues, mostly due
to the
fact that I need to supply mocks for testing and not so much
because I
crave another layer of indirection :-)
I think what Chris was talking about was not so much that
snippets are
tied to any specific persistence mechanism, but more that many
(most?)
snippets, to do something useful, needs to access some
functionality in
the business logic. An using a static reference for this makes it
difficult to swap BL implementations (ie with mocks). In an IoC
container, those dependencies would be injected automatically to the
snippet
[Lift] Re: authentication and access control
Thanks David,
That does help, yes. My first toy app, which I wrote for a company demo,
used lift 1.0 and mapper. I dug into the MegaProtoUser source and
remember how it worked (providing its own site menu configurations with
access control there). Role-based restrictions could be done much the
same way. Part of my issue with that is probably invalid - I'm
accustomed to the practice of such configurations being stored outside
of application code (XML).
Having known that, I guess my question was focused more on how lift
remembers the user. I think it was using the S object, which ultimately
stores keyed objects on the session, right?
Thanks again for your dedication and commitment to the lift community.
chris
David Pollak wrote:
On Thu, Aug 27, 2009 at 6:42 PM, Chris Lewis burningodzi...@gmail.com
mailto:burningodzi...@gmail.com wrote:
Lift users,
I'm curious what you all are using for user access control (Mapper users
excluded). I'm seriously evaluating lift for a project that will use
JPA. My full time job uses Spring Security, which while nice in that it
stays out of the way, is too clunky for my tastes. I haven't dissected
how lift implements it with Mapper, but wanted to ask the group first.
Thanks!
For HTML access control, Lift's SiteMap offers URL level protection of
pages (and menu generation based on the access control rules.) For each
Loc (location) in your sitemap, you can chain together If() and Unless()
clauses to define what rules are applied to each page. These rules are
based on invoking functions (e.g., User.superUser_?) and can be
arbitrarily complex.
For protecting non-sitemap resources (stuff that's served up via a
custom dispatch [DispatchPF]), it's best practice to put a guard in the
partial function:
{
case Req(api :: accounts :: Nil, _, GetRequest) if
currentUserCanViewAccounts_? = renderAccounts _
}
Hope this helps.
chris
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Dependency Injection in Lift
I like the Lift framework. It has its rough edges, but it's a great way to get into web app development using scala. It borrows many good ideas from other frameworks, most notably its convention over configuration structure (rails) and its scriptless view layer (wicket). One thing I'm not a big fan of is its baked-in database layer, the Mapper (now in flux and being reborn as Record), and so was pleased to find the JPA archetype in the 1.1 tree. Using this archetype, you get a barebones but functioning lift app using pure JPA. This is a great start, but when I poked around the snippets I saw two things that troubled me: The underlying entity manager API leaks directly into what would be the service layer API; a single object exposed as Model. The snippet code is hardwired to Model, which uses it directly as a global DAO. This archetype is still in development, and it very well may change. It's carries a nature of being experimental; showing you how it can be done, but probably not how it should be done. However, it highlighted an issue I have with Lift, one that the boring enterprise crowd has solved: dependency injection. I have an admittedly specific idea in mind for what I want to implement in my would-be Lift app: I want to be able to declare a few fields and annotate them so that a layer above will provide me with acceptable instances. Yeah, I want to inject DAOs in the oh-so-familiar Guice/Spring/T5 IoC way. I like this partially because it's familiar, but also because it provides me with loosely coupled code. There's been some good discussion on the subject of implementing dependency injection in Scala using mere language constructs. I dove into this subject, starting with chapter 27 of [http://www.artima.com/shop/programming_in_scala]: Modular Programming Using Objects. It's a good read, and I recommend the book. After that I found my way to some relevant posts in the blogs of Debasish Ghosh and Jonas Boner, respectively: http://debasishg.blogspot.com/2008/02/scala-to-di-or-not-to-di.html http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html Very cool indeed, but I've slightly digressed. What I want to explore is how to loosely couple the persistence implementation (be it JPA, JDO, or a baked in model) with the accessing of persistent objects. I don't see how the aforementioned technique (the cake pattern) would help in the case of lift snippets, because we don't have any kind of hooks where we can provide configuration of snippets (at least, not that I know of). This is exactly the issue that DI solves. So what are the thoughts of the lift-power users? Is there a way to get this in lift, or would you say that I am doing it wrong? sincerely, chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Dependency Injection in Lift
I am specifically talking about decoupling my web logic, ie, event handlers for forms in lift snippets, from the persistence layer. As currently implemented, snippets know exactly what persistence mechanism is in use because there is no intermediary API. If I'm using Mapper, my snippets must use the Mapper api. If JPA, the global EM wrapper Model. The same, I imagine, holds true for the Record api. This makes the persistence layer a Leaky Abstraction (http://en.wikipedia.org/wiki/Leaky_abstraction), and I want to avoid that. Most of DI of Lift is currently done using PartialFunction-s and Function lists that people can set in Boot or for snippets in case on binding functions usign SHtml helpers etc. Ok, but how does that help me decouple my web logic from the persistence details? What we've learned with Lift is the it is OK to give to persistence objects understanding of rendering. Having dumb objects that carry on just data and rely of layers that can do different jobs (render, persist) is IMO not a very good design approach. I disagree. An entity, like Author, is nothing more than an expression of a real-world concept modeled in code. It should know about itself, its direct constituents (like a Book collection), anything else that defines its own semantics, and nothing more. How it is stored is none of its business. Don't misunderstand me - I accept that I may be missing something. We agree that the concept of DI is valuable because it helps us keep abstractions loosely coupled. I don't see the problem with annotations, but I am not at all married to them. You point at partial functions and traits to implement abstractions over the persistence layer, but what is missing is how to apply that to snippets. Yes, I could abstract the layer however I want, but my snippets we still be required to get at the layer by calling it directly, instead of having it provided. Can you share some input on that part? Thanks for the discussion, chris marius d. wrote: Most of DI of Lift is currently done using PartialFunction-s and Function lists that people can set in Boot or for snippets in case on binding functions usign SHtml helpers etc. Personally I'm not at all a fan of Pojo/Poji DI by annotations especially in Scala realm where there are other artifacts such as function composition, monads, mixin composition, higher order functions etc. The other problem with annotations is that we can't currently build annotations in Scala to be visible at runtime, so we'd probably have to code them in Java or use some existent Java annotations ... but this already smells hacky IMHO. If enterprise folks solve one problem by DI by annotation it doesn't mean that this fits in all contexts.Persistence loosely coupling can be achieved in many ways: 1. Implement your own persistence semantic on top of Record 2. Implement your own traits hence your own abstractions 3. etc What we've learned with Lift is the it is OK to give to persistence objects understanding of rendering. Having dumb objects that carry on just data and rely of layers that can do different jobs (render, persist) is IMO not a very good design approach. Having snippets invoking the persistence layer is ok, in fact it is natural for applications. Of course with a proper level of persistence abstraction IF there are chances for the application to use a different persistence mechanism then say JDBC. But many application don't really need such a rigorous decoupling so using mapper/record from snippets makes a lot of sense. Br's, Marius On Aug 30, 6:21 pm, Chris Lewis burningodzi...@gmail.com wrote: I like the Lift framework. It has its rough edges, but it's a great way to get into web app development using scala. It borrows many good ideas from other frameworks, most notably its convention over configuration structure (rails) and its scriptless view layer (wicket). One thing I'm not a big fan of is its baked-in database layer, the Mapper (now in flux and being reborn as Record), and so was pleased to find the JPA archetype in the 1.1 tree. Using this archetype, you get a barebones but functioning lift app using pure JPA. This is a great start, but when I poked around the snippets I saw two things that troubled me: The underlying entity manager API leaks directly into what would be the service layer API; a single object exposed as Model. The snippet code is hardwired to Model, which uses it directly as a global DAO. This archetype is still in development, and it very well may change. It's carries a nature of being experimental; showing you how it can be done, but probably not how it should be done. However, it highlighted an issue I have with Lift, one that the boring enterprise crowd has solved: dependency injection. I have an admittedly specific idea in mind for what I want to implement in my would-be Lift app: I want to be able to declare a few fields
[Lift] Re: Dependency Injection in Lift
One option might be implicit parameters, but it doesn't seem as clean
(could be a knee jerk). I tried defining an implicit param on the form
handler, but then lift couldn't find the mapped handler. Doing this I
believe changes the function signature, and so the reflective call
doesn't see it.
However, you can define a method on your snippet that takes an implicit.
Consider a simple snippet:
trait UserService {
def findByUserName(userName: String) : String
}
object Config {
implicit val us = new UserService() {
def findByUserName(userName: String) = userName
}
}
import Config._
class MySnippet {
def userService(implicit us: UserService) = us
def login(xhtml : NodeSeq) : NodeSeq = {
var userName =
var password =
def doLogin() = {
println(userName + ; + userService.findByUserName(userName))
}
bind(user, xhtml,
userName - SHtml.text(userName, userName = _),
password - SHtml.password(password, password = _),
submit - SHtml.submit(?(Save), doLogin _)
)
}
}
Notice the part in the doLogin closure:
userService.findByUserName(userName)
Because of the universal access principal, we can treat userService, a
single argument function that returns type UserService (a trait), as an
object. Also see how the userService method receives an implicit
parameter. Because we define an object (Config) that provides an
implicit value of that type, and we import that value, the compiler can
provide it implicitly.
One thing about this method is that we have to have a satisfying
implicit value in scope. In a unit test we could easily do it on the
fly, but for normal execution I'm not sure where you can plug something in.
I'd still love to hear more thoughts, and if this method could be at all
usable.
sincerely,
chris
Jeppe Nejsum Madsen wrote:
Chris Lewis burningodzi...@gmail.com writes:
I am specifically talking about decoupling my web logic, ie, event
handlers for forms in lift snippets, from the persistence layer. As
currently implemented, snippets know exactly what persistence mechanism
is in use because there is no intermediary API.
Chris, I'm sharing the same concerns as you about the decoupling. For
now, I've just accepted it to get started with Lift.
But now that our app starts to grow, I think we'll need to find a
good solution for this in order to
1) Maintain a good test suite (I'm a strong believer in TDD and
automated testing in general. I don't think that having type safety and
FP makes tests obsolete).
2) Loosely couple the code to make it maintainable over time
One of my big issues right now is how to test snippets that access the
persistence/business layer. This is trivial if snippets has some kind of
DI, as you could just inject mock objects instead of the real
thing. Alas, I haven't found a good solution yet. I do think that Scala
provides some language support for this (ie. the articles you linked to)
and I would like to pursue this first, before using more heavyweight
solutions such as Spring/Guice etc.
/Jeppe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: authentication and access control
Tim, No, just looking around at a higher level. Back to what I like about spring security, it stays entirely out of application code's way (as does the protouser stuff). I will look at those auth examples, and I will poke through (Mega)ProtoUser source (I'm more accustomed to having an application component manage access control, as opposed to http auth. On another note, are you using lift 1.1-M4? I used the jpa basic archetype last night and the web module is broken (mainly imports in Boot). Thanks again for your input! Timothy Perrett wrote: Chris, Are you thinking along the lines of JAAS or similar? As Marius said, we currently don't have a defined way of doing general purpose authentication within Lift apps Cheers, Tim Sent from my iPhone On 28 Aug 2009, at 08:14, marius d. marius.dan...@gmail.com wrote: I'm not sure you HTTP authentication is what your looking for. Lift has support for both BASIC and DIGEST authentication models (irrespective of any persistence technology) and you can grant access based on Roles defined as a hierarchical structure. See /examples/http-authentication application. As far as Mapper goes it has a built in ProtoUser implementation for login, registration, forgot password etc. Br's, Marius On Aug 28, 4:42 am, Chris Lewis burningodzi...@gmail.com wrote: Lift users, I'm curious what you all are using for user access control (Mapper users excluded). I'm seriously evaluating lift for a project that will use JPA. My full time job uses Spring Security, which while nice in that it stays out of the way, is too clunky for my tastes. I haven't dissected how lift implements it with Mapper, but wanted to ask the group first. Thanks! chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] authentication and access control
Lift users, I'm curious what you all are using for user access control (Mapper users excluded). I'm seriously evaluating lift for a project that will use JPA. My full time job uses Spring Security, which while nice in that it stays out of the way, is too clunky for my tastes. I haven't dissected how lift implements it with Mapper, but wanted to ask the group first. Thanks! chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: ProtoUser and securing pages
I guess the first question I should have asked is how do I go about logging a user in. I have my user model, which now mixes in MegaProtoUser. I also persist instances, but I don't know how to start a user session. I noticed the logUserIn method - I assume that's where to start when I get back into the app later this evening, but I was wondering if there are any example apps that use this? I didnt see any in the current source, and, assuming it makes a difference, I'm using 1.0. thanks again, chris David Pollak wrote: On Tue, Jul 14, 2009 at 9:20 AM, glenn gl...@exmbly.com mailto:gl...@exmbly.com wrote: I do something similar in menu items to hide them for different user roles, but the error message: No Navigation Defined, is displayed if the right user isn't logged in. How do I turn this off? Upgrade based on the fix I just checked in. :-) On Jul 14, 4:02 am, Chris Lewis burningodzi...@gmail.com mailto:burningodzi...@gmail.com wrote: Too easy! Thanks for the help David - I'll msg the channel when the app is on github. Fine job with Lift - it's been a joy so far! David Pollak wrote: On Mon, Jul 13, 2009 at 8:57 PM, Chris Lewis burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com wrote: That'll get me started. User there however, must mixin MegaProtoUser instead of ProtoUser right (getting compilation errors)? Yeah... you have to build your User from MegaProtoUser/MetaMegaProtoUser. I guess I'm interested in how/when/where the checking happens, but that suggests I need to have a source dive. I do need secured pages in the SiteMenu (which I can have once I work out the compilation issues), but what if I need to secure a URL handled via custom dispatch, and so is not in the menu? Sitemap is for protecting XHTML pages... stuff that's rendered to the browser. If you have a custom dispatch, then you have to build the protection logic into the dispatch: case Req(my_page :: thing :: Nil, _, GetRequest) if User.loggedIn_? = () = XmlResponse(helloworld/hello) A little bonus of the app is a bookmarklet that actually makes it useful, and it hits up that URL. The idea would be to secure that URL in lift and if the user is logged it would just work. I'll hack on it a bit more tomorrow - thanks again! chris David Pollak wrote: In Boot.scala, define your SiteMap as: // Build SiteMap val entries = Menu(Loc(Home, List(index), Home)) :: Menu(Loc(Protected, List(protected), Protected, If(User.loggedIn_? _, You must be loggd in to view this page))) :: User.sitemap Note the If() clause that tests if the user is logged in and will not display the menu item or let you access that page. Is this what you're looking for? On Mon, Jul 13, 2009 at 8:23 PM, Chris Lewis burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com wrote: Hello list, I'm writing a lift app for a presentation Wednesday. It's a simple little app that is all but done, missing only the ability to secure pages. I've got a /really/ simple registration page (template with a user name field, bound in a snippet that persists the User model). What's missing is the ability to secure pages if the user is logged in. I'm reading through the lift book and I just don't see in there how it's done. FWIW, I'm working with lift 1.0. I switched to 1.1-SNAPSHOT and there were some strange query-related breakages, so for the sake of the demo I'll stick with 1.0. I'm sorry if this question has been asked 1000 times - can anyone offer a good resource or example (logins, logouts, secured pages)? Thanks! Lift is pretty cool so far :) - I'll github the app
[Lift] Re: ProtoUser and securing pages
Thanks for the assistance David, and to suresk in the IRC channel as well as tjweir (I was pointed to his example code). My app is where I wanted it for the demo. This week and next will be pretty slamming at work, but I will try to find some time to push the app to github soon. sincerely, chris David Pollak wrote: On Tue, Jul 14, 2009 at 3:32 PM, Chris Lewis burningodzi...@gmail.com mailto:burningodzi...@gmail.com wrote: I guess the first question I should have asked is how do I go about logging a user in. I have my user model, which now mixes in MegaProtoUser. I also persist instances, but I don't know how to start a user session. I noticed the logUserIn method - I assume that's where to start when I get back into the app later this evening, but I was wondering if there are any example apps that use this? I didnt see any in the current source, and, assuming it makes a difference, I'm using 1.0. thanks again, chris Chris, Did you start your app based on one of the Lift templates? If you take a look at line 27 of: http://github.com/dpp/lift_1_1_sample/blob/master/src/main/scala/bootstrap/liftweb/Boot.scala You'll see how the MegaProtoUser can manage its own menus. From that, you get login, logout, etc. Does this help? Thanks, David David Pollak wrote: On Tue, Jul 14, 2009 at 9:20 AM, glenn gl...@exmbly.com mailto:gl...@exmbly.com mailto:gl...@exmbly.com mailto:gl...@exmbly.com wrote: I do something similar in menu items to hide them for different user roles, but the error message: No Navigation Defined, is displayed if the right user isn't logged in. How do I turn this off? Upgrade based on the fix I just checked in. :-) On Jul 14, 4:02 am, Chris Lewis burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com wrote: Too easy! Thanks for the help David - I'll msg the channel when the app is on github. Fine job with Lift - it's been a joy so far! David Pollak wrote: On Mon, Jul 13, 2009 at 8:57 PM, Chris Lewis burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com mailto:burningodzi...@gmail.com wrote: That'll get me started. User there however, must mixin MegaProtoUser instead of ProtoUser right (getting compilation errors)? Yeah... you have to build your User from MegaProtoUser/MetaMegaProtoUser. I guess I'm interested in how/when/where the checking happens, but that suggests I need to have a source dive. I do need secured pages in the SiteMenu (which I can have once I work out the compilation issues), but what if I need to secure a URL handled via custom dispatch, and so is not in the menu? Sitemap is for protecting XHTML pages... stuff that's rendered to the browser. If you have a custom dispatch, then you have to build the protection logic into the dispatch: case Req(my_page :: thing :: Nil, _, GetRequest) if User.loggedIn_? = () = XmlResponse(helloworld/hello) A little bonus of the app is a bookmarklet that actually makes it useful, and it hits up that URL. The idea would be to secure that URL in lift and if the user is logged it would just work. I'll hack on it a bit more tomorrow - thanks again! chris David Pollak wrote: In Boot.scala, define your SiteMap as: // Build SiteMap val entries = Menu(Loc(Home, List(index), Home)) :: Menu(Loc(Protected, List(protected), Protected, If(User.loggedIn_? _, You must be loggd in to view this page))) :: User.sitemap Note the If() clause that tests if the user is logged in and will not display the menu item or let you access that page
[Lift] Re: ProtoUser and securing pages
That'll get me started. User there however, must mixin MegaProtoUser instead of ProtoUser right (getting compilation errors)? I guess I'm interested in how/when/where the checking happens, but that suggests I need to have a source dive. I do need secured pages in the SiteMenu (which I can have once I work out the compilation issues), but what if I need to secure a URL handled via custom dispatch, and so is not in the menu? A little bonus of the app is a bookmarklet that actually makes it useful, and it hits up that URL. The idea would be to secure that URL in lift and if the user is logged it would just work. I'll hack on it a bit more tomorrow - thanks again! chris David Pollak wrote: In Boot.scala, define your SiteMap as: // Build SiteMap val entries = Menu(Loc(Home, List(index), Home)) :: Menu(Loc(Protected, List(protected), Protected, If(User.loggedIn_? _, You must be loggd in to view this page))) :: User.sitemap Note the If() clause that tests if the user is logged in and will not display the menu item or let you access that page. Is this what you're looking for? On Mon, Jul 13, 2009 at 8:23 PM, Chris Lewis burningodzi...@gmail.com mailto:burningodzi...@gmail.com wrote: Hello list, I'm writing a lift app for a presentation Wednesday. It's a simple little app that is all but done, missing only the ability to secure pages. I've got a /really/ simple registration page (template with a user name field, bound in a snippet that persists the User model). What's missing is the ability to secure pages if the user is logged in. I'm reading through the lift book and I just don't see in there how it's done. FWIW, I'm working with lift 1.0. I switched to 1.1-SNAPSHOT and there were some strange query-related breakages, so for the sake of the demo I'll stick with 1.0. I'm sorry if this question has been asked 1000 times - can anyone offer a good resource or example (logins, logouts, secured pages)? Thanks! Lift is pretty cool so far :) - I'll github the app after it's to a workable state. Should be a decent example of ProtoUser usage and a few other simple things (like a LastFM api using dbDispatch). chris -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
