[Lift] Re: Overriding date/time formatting
Dirk Louwers writes: > > If it would be at all usefull I'd be happy to share the code. Please do. I'll eventually have to support different locales at some point /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: Binding a snippet in a comet actor?
Thanks for responding, Naftoli.
I tried changing the code to:
def handleSubmit() =
{
Log.info("GOT A SUBMIT IN INVITE")
net.liftweb.http.js.JsCmds.Run("alert('Hey')")
}
ajaxForm(
bind("elem", xhtml,
"submit" -> submit("Click", () => handleSubmit() ),
) ++ hidden(() => handleSubmit())
)
The handleSubmit method is still not called. I tried using ajaxButton
instead of submit but that did not help either.
What am I doing wrong?
On Oct 7, 5:06 am, Naftoli Gugenheim wrote:
> What about an Ajax form?
>
> On Tue, Oct 6, 2009 at 9:52 AM, Somindra Bhattacharya
>
> wrote:
>
> > Hi Everyone,
>
> > I have a comet actor that binds XHTML. The XHTML corresponds to a
> > snippet:
>
> > XHTML for comet actor ->
>
> >
> >
> >
>
> > When the comet actor receives a certain message, the render method of
> > the comet actor binds the following XHTML ->
>
> >
> >
> >
>
> > The Discuss snippet's "invite" method definition is:
>
> > def invite(xhtml: NodeSeq): NodeSeq =
> > {
>
> > def handleSubmit() =
> > {
> > Log.info("GOT A SUBMIT IN INVITE")
> > }
>
> > bind("elem", xhtml,
> > "submit" -> submit("Click", () => handleSubmit()))
> > }
>
> > The page does not contain this form when it is first loaded. When the
> > actor receives a certain message, it binds the XHTML (Discuss.invite)
> > to the page and the form and the "submit" button are rendered
> > properly.
>
> > However, when I click on the submit button, the "handleSubmit" method
> > is not called. Instead, the browser displays a page with the text
> > "window.location=/".
> > If I use the browser back button and re-visit the page with the comet
> > actor, the submit button works (i.e., handleSubmit() is called and I
> > can see the info log).
>
> > Is this approach "legal"? Is there a way to make a form submit if it
> > was not originally part of the page?
>
> > Thanks,
> > Som
--~--~-~--~~~---~--~~
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: Started integrating lift in a scala+spring project. Feedback?
Yes, but I am referring to the case when there is no Full(session).
I.e. how do I get the servlet context in the 2nd case at the place
where I am currently throwing a RTE.
def servletContext = {
S.servletSession match {
case Full(session) => session.getServletContext()
case _ => throw new RuntimeException("no session")
}
}
--~--~-~--~~~---~--~~
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: maven and jetty
On Tue, Oct 6, 2009 at 11:10 PM, Jack Widman wrote: > I am picking up a very subtle insinuation that that question was too easy > for this forum. I agree whole heartedly. Won't do it again. My next > question is - Is P=NP? No wait, thats not appropriate. > > No, the question was not to easy for this forum, but it was the wrong forum. > > On Tue, Oct 6, 2009 at 5:07 PM, Timothy Perrett > wrote: > >> Correct. :run uses the stuff under src/main/webapp vs :run-war that uses >> what is bundled in the war (surprise surprise!) >> >> This should all be explained in the maven-jetty-plugin docs as this is not >> something lift specific by any means. >> >> Cheers, Tim >> >> Sent from my iPhone >> >> On 6 Oct 2009, at 21:57, Jack Widman wrote: >> >> I thought run uses classes and run-war uses the war. no? >> >> On Tue, Oct 6, 2009 at 4:54 PM, MarkChance < >> mark.cha...@gmail.com> wrote: >> >>> >>> I use mvn -Djetty.port=8090 jetty:run >>> It builds the war and then runs jetty. If you leave it running and re- >>> build the war, say in your IDE, the Jetty generally restarts >>> automatically. >>> >>> HTH, Mark >>> >>> On Oct 5, 8:44 pm, Jack Widman wrote: >>> > Well it seems that mvn run-war is creating the war and overriding the >>> one I >>> > just uploaded. How do I just run with a given war and not create the >>> war. >>> > >>> >>> >>> >> >> >> -- >> Jack >> >> >> >> >> > > > -- > Jack > > > > -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: lift-json and attributes
On Mon, Oct 5, 2009 at 9:01 PM, Joni Freeman wrote: > > Thanks Richard! > > This is a feature request and I just committed an implementation to my > branch. I've just pulled 1-1 SNAPSHOT, tried it, and it works just how I need it to. Thank you Richard --~--~-~--~~~---~--~~ 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] Supporting Jetty 7 Continuations
Guys,
I just wanted to rename this thread and raise this for proper
discussion. API's between J6.x and J7.x appear to be the same, its
mainly the package names and structure that have changed.
Is it feasible to add a match statement to replace the current val
assignments that have essentially hardcoded dependency on J6.x?
There's some great stuff in Jetty 7 that would really help me (and
lots of others) out
Cheers, Tim
On Oct 5, 5:20 pm, Timothy Perrett wrote:
> Id say that it would be easier to use a match statement as part of the
> val assignment... The current code is just using reflection, so
> factoring into a case statement shouldnt be too tough right?
>
> Thoughts?
>
> Cheers, Tim
>
> On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
>
>
>
>
>
> > On 05/10/09 5:29 PM, Timothy Perrett wrote:
>
> >> So I just wrote a Jetty 6 wrapper - getting the packaging working was
> >> not ideal and not as flexible as Jetty 7 jetty-runner.
>
> > Yes, just took a look at jetty-runner. Feature wise, it's blows away
> > the
> > older mechanism man!
>
> >> Any thoughts in and around altering the lift code to adjust the
> >> package based on jetty version?
>
> > I can think of two options basically:
>
> > 1. Move to jetty 7 and be done with it.
>
> > 2. Allowing user option (via -Djetty.version) during
> > archetype:generate.
> > jetty.version can be an overridable archetype property that defaults
> > to
> > (say 6) but user can do -Djetty.version=7.
>
> > Depending on the jetty version, the *.scala, *.xml etc. can be
> > filtered
> > to make the right kind of adjustment during archetype creation.
>
> > Cheers, Indrajit
>
> >> Cheers, Tim
>
> >> On Oct 5, 9:07 am, Timothy Perrett wrote:
> >>> Indrajit,
>
> >>> Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6
> >>> would be this line:
>
> >>> val cc = Class.forName
> >>> ("org.mortbay.util.ajax.ContinuationSupport")
>
> >>> It would be trivial to add a match or whatever that determined the
> >>> correct type to use... The question is, why haven't we done this
> >>> already? I suspect its just a time / capacity issue but wanted to
> >>> check.
>
> >>> I know I could write a jetty 6 wrapper, but that is my fallback
> >>> position as something more OOTB would be preferable.
>
> >>> Cheers, Tim
>
> >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> >>> wrote:
>
> Tim,
>
> Interestingly, we are trying out something similar in a project
> here and
> this is absolutely cool stuff.
>
> In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as
> 'desktop application'.
>
> That you can have 'double-click' friendly application helps :-)
>
> Few notes:
>
> 1. Embedding Jetty server is super easy with
> org.mortbay.jetty.Server.
> Something that we have in Lift - well almost ;-) The RunWebApp in
> the
> archetypes are primitive use case of such. [1]
>
> 2. Jetty Runner is available only on Jetty 7.x series I think (not
> certain). But yes, looks good either way.
>
> 3. Jetty has this clean and nice way of having web-app specific
> jetty
> config tucked inside the application (war or expanded) within
> WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> instance
> applied on the specific WebApplicationContext instead of the
> Container
> Context. [2]
>
> 4. An archetype that does self deploying is something that I have
> on my
> todo-list. Do you think this would make sense?
>
> 5. Maven assembly plugin would do. I haven't tried this myself, but
> Maven shade plugin looks something close. [3]
>
> [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
> [3]http://maven.apache.org/plugins/maven-shade-plugin/
>
> Cheers, Indrajit
>
> NB: Looks like quite a few night owl here!
>
> On 05/10/09 4:11 AM, Timothy Perrett wrote:
>
> > Viktor, you and I should not be up this late on a sunday! ;-)
>
> > You have to see this:http://blogs.webtide.com/janb/entry/
> > jetty_runner
>
> > Im going to hash this together as a maven assembly; if it works,
> > then
> > i'll write a blog and stuff it on the wiki... this could really
> > make
> > self deploying apps very nice indeed. I'll check with DavidB,
> > but im
> > fairly sure it would also be trivial to make a little maven plugin
> > that builds a single JAR output...
>
> > Cheers, Tim
>
> > On Oct 4, 11:10 pm, Viktor Klang wrote:
> >> Thanks for the linky, mate!
> >> Was a good read :)
>
> >> On Sun, Oct 4, 2009 at 11:45 PM, Timothy
> >> Perrettwrote:
>
> >>> Just some more fuel for this debate:
>
> >>>http://technically.us/code/x/to-jettison-geronimo/
>
> >>> Cheers, Tim
>
> >>> On Oct 4, 8:46 pm, Timothy Perrett
> >>> wrote:
> >>
[Lift] Re: How to suppress / override / escape context path rewriting?
Hi,
Perhaps a bit of a hack, but a redirect like the following might do
the trick:
LiftRules.dispatch.prepend(NamedPF("redirect context/mainapp
requests to mainapp") {
case Req("mainapp" :: page, "", _) => () =>
Full(RedirectResponse(S.hostAndPath.replace(S.contextPath, "") +
S.uri))
})
This will let Lift do it's rewriting and add in the webapp context,
and you can use links like /mainapp/* in your templates... the
redirect catches those requests and does an absolute redirect using
the hostname etc. - so Lift doesn't try to add in the context. Any
good?
Andrew
On Oct 7, 1:21 am, Derek Chen-Becker wrote:
> I don't know of any way to do this currently. If no one else has any ideas,
> I would open an issue.
>
> Derek
>
> On Tue, Oct 6, 2009 at 11:07 AM, Ross Mellgren wrote:
>
> > I'm deploying a Lift application into JBoss as another WAR alongside
> > the rest of our application in a separate WAR, and I'm running into
> > problems with the context path rewriting. I've deployed my WAR with an
> > appropriate jboss-web.xml file which sets the context path to /myapp,
> > and now I'd like to construct relative URLs that go out to the other
> > WAR, e.g.
>
> > Home
>
> > but Lift rewrites anything starting with / to have the context path,
> > so instead I get
>
> > Home
>
> > This is mostly the right thing, and I don't really want to disable it
> > globally (especially because then the /ajax_request paths and so on
> > would probably go wrong), but I'd really like a way to escape it. The
> > only ways so far I've found are:
>
> > 1) Use /../mainapp/home, which rewrites to /myapp/../mainapp/home,
> > which comes out right but seems pretty freaking ugly and depends on my
> > context path only having one segment
> > 2) Use fully-qualified URLs. This has the problem that I can't easily
> > construct these URLs in templates without having some kind of snippet
> > that expands it for me.
>
> > What I'd ideally like is some special syntax to "escape" context
> > rewriting (e.g. //mainapp/home, or something else), or some guidance
> > on how people usually accomplish this and so on.
>
> > Any ideas? I'm using 1.1-SNAPSHOT.
>
> > -Ross
--~--~-~--~~~---~--~~
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: RESTful JSON server that supports jQuery or JSONP callback
Hey guys,
I managed to build in callback support, and I draw your attention to
the implementation here:
http://github.com/opyate/Ken/blob/master/ken-server/src/main/scala/com/opyate/ken/lib/API.scala
Excerpt:
override def dispatch: LiftRules.DispatchPF = {
// modify the returned function to one which converts the result
to JSON
// or a pure LiftResponse (usefull when HTTP response code is not
200)
dispatchMethod.andThen(x =>
{
val unboxed = unbox(x)
unboxed match {
case l:LiftResponse => { () => Full(l) }
case _ => { () => {
if (S.param("callback").isEmpty) {
Full(
JsonResponse(
jsonAttributes(
unbox(x)
)
)
)
} else {
Full(
JavaScriptResponse(
JE.JsFunc(S.param("callback").open_!,
jsonAttributes(
unbox(x)
)
).cmd
)
)
}
}
}
}
}
)
}
So, basically it will handle any callback function name you give it,
because it will just echo it back in the response. (default for jQuery
JSONP is "C").
Please be very critical of my code: I'm not doing things properly, or
in a particularly functional manner, but I'm learning :-)
Shameless plug: another little Scala/Lift project of mine which I'd
like feedback on:
http://wiki.github.com/opyate/yauser
Thanks, and happy coding!
Juan
On Oct 6, 6:23 pm, opyate wrote:
> Sorry - APIResponse code not borrowed from skittr, but ESME (http://
> incubator.apache.org/esme/)
> Thus, depending on your call's extension (.json or .xml) you can serve
> the response in the required format.
>
> Anyhoo, back to the question... :-)
>
> Thanks,
> Juan
>
> On Oct 6, 5:48 pm, Juan M Uys wrote:
>
>
>
> > Hi Lifters,
>
> > I'm building a REST server and a separate stand-alone DHTML client
> > which won't necessarily be hosted on the same server. Some browsers do
> > not support cross site Ajax, henceJSONP(i.e. callback support).
>
> > My DHTML client now makes calls like the following, using jQuery:
>
> >
> > GET /api/version.json?callback=C&_1254838856015= HTTP/1.1
> > Host: localhost:8080
> > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> > rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
> > Accept: */*
> > Accept-Language: en-us,en;q=0.5
> > Accept-Encoding: gzip,deflate
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > Cookie: JSESSIONID=13k8ykwq2u2w6
> >
>
> > I need to know if I need to build manual support in for the callback:
> > * grab the token 'C'
> > * generate a JsCmd named 'C' with my JSON response as parameter (It
> > will be great if someone can suggest which parts of the Lift API to
> > use for this)
> > * send it back to the client (as an extra parameter to the original
> > JSON, or on it's own?)
>
> > It doesn't seem like Lift automatically picks up on "?callback=" (it's
> > not a standard, so - understandable), and my response looks like this:
>
> >
> > HTTP/1.1 200 OK
> > Content-Length: 16
> > Content-Type: application/json
> > X-Lift-Version: 1.1-SNAPSHOT
> > Server: Jetty(6.1.21)
>
> > {"version": "1"}
> >
>
> > The above response is generated by:
>
> >
> > def version(): Box[APIResponse] = {
> > Full(
> > Right(
> > Map("version" ->
> > Map("version" -> APIHelper.getParam("api.version"))
> > )
> > )
> > )
> > }
> >
>
> > ...where APIResponse is borrowed from TwitterResponse (from the skittr
> > example).
>
> > Another problem I have is that Firefox complains about "invalid label"
> > for the above response, so I think wrapping it up in a callback will
> > fix it.
>
> > Here's an answer related to PHP for this
> > issue:http://stackoverflow.com/questions/790910/jquery-getjson-to-external-...
>
> > Thanks,
>
> > --
> > juan
> > +44 7702 783 956
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: lift nearly inaccessible for newby
Hi Stefan and everybody, I am a bit overwhelmed by the enormous response on my mail and am very grateful for it. Last evening, after seeing the amounts of mail, I started working again and ended quite late. I think I even made some progress! (at least Maven thought I made some) So the encouragements have helped, I think. The way I feel right now, I would like to end this discussion, would like to thank everybody, and hope that the Robert A. Heinlein readers among you will grok me when I say: I am only an egg. Cheers! Ko On 6 okt, 22:10, Stefan Langer wrote: > I didn't want to discourage you I just wanted to be honest and please do > come back with any question you have as we learn by asking. But at the same > time as was said in this thread already take the time to expriment and use > the resources that are there (google and the like) to come up with the > answers yourself. As you do this you will start to understand stuff more and > more and things will get easier. > > With the professional help I simply ment that if you have a short time to > market then you will not get happy with experimenting and you might consider > paying someone (a professional) or finding someone who will do it for you > since the other way is going to cost you a lot of time. > > About what David Pollak said: > I think he does a great job designing and maintaining lift but I still think > without knowing Scala it is virtually impossible to come to grips with Lift > no matter how easy it is to set it up. > Learning a programming language with no programming background is quite a > job, and in my opinion well worth it, but a long term commitment is > required. > > About the comment with Rails... not too sure if Rails or Lift is easier or > they are the same. I have experience with Rails and I love the Ruby syntax > which I think is a tad better then Scalas so I find Rails still a tad easier > but that is because of lack of experience with Lift. > If I wouldn't take Lift serious I wouldn't be here and spend my time > learning it. I just do not want you to think that you can simply grab lift > and understand it immediately. > > One more thing about the documentation of Lift. The biggest problem I had > when starting was that there is no easy link to a workable Lift demo except > for the maven archetype and that is just not complex enough for learning > purposes. Thank god to github and the likes the applications to checkout are > getting more. Still I think it would be great if the Lift website had a > download for an application like the Java PetStore or the like for beginners > to study. > Befor anyone thinks I'm starting a rant here this is just a suggestion and > if I can find the time besides all the other pet projects of mine ;) I might > just start a demo app. > > Regards > Stefan > > 2009/10/6 koveen > > > > > > > Stefan, > > > thanks for your reply. :) > > > to anwser your questions: I have no experience with Java and I only > > made some very simple static websites, years ago. I will try to listen > > to you and try to make a very simple website with Lift. But if -IF- > > I've succeeded in doing that, I hope you will excuse me when I'll come > > back to ask again the -too complex- question in my mail. > > > I am not sure if what you are referring to if you mention the > > professional help I should get, but Yes! I am not really happy trying > > things out that don't seem to work for me up till now. So shrink or > > programmer, any help is welcome! (For now I think I will experiment > > with some simple things on my own) > > > I know the online liftbook, and I am reading it. I bought the > > "Beginning Scala" book from David Pollak, and haven't read that much > > yet, but I will. > > > Cheers, > > > Ko > > > On Oct 6, 11:52 am, Stefan Langer wrote: > > > Not ment as a offence but you are in way over your head! > > > A couple of things: > > > 1. You say you are a non-programmer but I assume you do understand Scala? > > Or > > > else it is pointless to use Lift as it is based on the Scala language and > > > relies heavily on its features. Knowledge of Java is also a plus cause > > some > > > of the libs are not available in Scala but only in Java and it is better > > to > > > know Java in order to understand the libraries. > > > 2. You do have experience with websites? Complex web applications? If not > > > then I suggest you start by doing a simple static page for your design to > > > get to know the technics you are trying to use or you get yourself a > > > programmer/webdesinger to do it for you. If you are not willing to learn > > > about the technical details you will get in big trouble later on and I > > mean > > > trouble that can actually cost you money. > > > 3. If the above points do not seem valid for you then please get > > > professional help > > > 4. If you are not scared by the above points and you are willing to > > invest > > > then I suggest getting some example code and starting to disect that. > > >
[Lift] Re: Override the display names for (Mega)ProtoUser
Cheers,
I've finished the translation. Who do I send the file to for
integration and how can I have Lift pick it up in the meanwhile?
Best,
Dirk Louwers
On Oct 7, 8:41 am, Heiko Seeberger
wrote:
> Take it from
> here:http://github.com/dpp/liftweb/tree/master/lift/src/main/resources/i18n/
>
> Heiko
>
> 2009/10/7 Dirk Louwers
>
>
>
>
>
> > Hi,
>
> > Not to be an evil hijacker of threads, but can anyone supply me the
> > english Lift core resource bundle? I would like to work on a dutch
> > translation.
>
> > Best,
>
> > Dirk Louwers
>
> > On Oct 7, 7:43 am, Heiko Seeberger
> > wrote:
> > > Jeppe,
> > > You are my hero ;-)
>
> > > Thanks,
>
> > > Heiko
>
> > > 2009/10/6 Jeppe Nejsum Madsen
>
> > > > Heiko Seeberger writes:
>
> > > > > Hi,
> > > > > It is not possible to localize or override the display names for
> > > > > (Mega)ProtoUser's first name, last name and time zone. This is
> > because it
> > > > is
> > > > > determined by ??("First Name") and analogous, with "First Name" (with
> > a
> > > > > blank) not a valid key for a PropertyResourceBundle.
>
> > > > > Am I missing something? Or should I file a bug?
>
> > > > I think you're missing something :-)
>
> > > > I had the same issue. Some studying of
>
> > > >http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html#loa.
> > ..
>
> > > > leads to this explanation: "The key contains all of the characters in
> > the
> > > > line starting
> > > > with the first non-white space character and up to, but not including,
> > > > the first unescaped '=', ':', or white space character other than a
> > line
> > > > terminator. All of these key termination characters may be included in
> > > > the key by escaping them with a preceding backslash character"
>
> > > > And, while not very intuitive, this works for me:
>
> > > > First\ Name = Fornavn
> > > > Last\ Name = Efternavn
>
> > > > /Jeppe
>
> --
> Heiko Seeberger
>
> My job: weiglewilczek.com
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to 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: Override the display names for (Mega)ProtoUser
Dirk Louwers writes: > Cheers, > > I've finished the translation. Who do I send the file to for > integration and how can I have Lift pick it up in the meanwhile? You can place the file in src/main/resources/i18n and set the locale using LiftRules.localeCalculator /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: Override the display names for (Mega)ProtoUser
An example of locale calculator can be found here: http://is.gd/1NXGN Cheers, Tim On 7 Oct 2009, at 13:04, Jeppe Nejsum Madsen wrote: > > Dirk Louwers writes: > >> Cheers, >> >> I've finished the translation. Who do I send the file to for >> integration and how can I have Lift pick it up in the meanwhile? > > You can place the file in src/main/resources/i18n and set the locale > using LiftRules.localeCalculator > > /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: Overriding date/time formatting
Here goes. I have also added the possibility to mark the field as
required. That proved to be less trivial than expected since
validators can only work on the field type and not the raw string.
class MappedLocalDateTime[T<:Mapper[T]](fieldOwner: T) extends
MappedDateTime[T](fieldOwner) {
private var rawString: String = ""
def requiredField_? = false
override def validate : List[FieldError] = {
if (rawString.trim == "" && requiredField_?) FieldError(this,
Text
(S ? "field.required")) :: Nil
else super.validate
}
override def asHtml = Text(dateFormatter.format(is))
override def _toForm: Box[NodeSeq] =
S.fmapFunc({s: List[String] => this.setFromAny(s)}){funcName =>
Full( "" case s =>
dateParser.format(s)}}/
>)
}
override def setFromAny(f : Any): Date = toDate(f).map(d =>
this.set
(d)).openOr(this.is)
def toDate(in: Any): Box[Date] = {
try {
in match {
case null => Empty
case d: Date => Full(d)
case lng: Long => Full(new Date(lng))
case lng: Number => Full(new Date(lng.longValue))
case Nil | Empty | None | Failure(_, _, _) => Empty
case Full(v) => toDate(v)
case Some(v) => toDate(v)
case v :: vs => toDate(v)
case s : String => rawString = s; parseDate(s)
case o => toDate(o.toString)
}
} catch {
case e => Log.debug("Error parsing date "+in, e); Failure("Bad
date: "+in, Full(e), Empty)
}
}
/**
* This DateFormat is used to parse incoming strings and to format
this field's date when displaying
* in a form. Override this to change the format. Default format
is DateFormat.SHORT for the
* current locale.
*/
def dateParser = shortDateFormat
/**
* This DateFormat is used to display this field's date as html.
Override to change the format. The
* default is DateFormat.DEFAULT for the current locale.
*/
def dateFormatter = defaultDateFormat
final protected def makeDateFormat(key: String, format: Int):
DateFormat = {
val formatString = S ? key
def localeFormat: DateFormat = {
try { DateFormat.getDateInstance(format, S.locale) }
catch { case e => DateFormat.getDateInstance(DateFormat.DEFAULT,
S.locale) }
}
if (formatString == key) localeFormat
else
try { new SimpleDateFormat(formatString, S.locale) }
catch { case e => localeFormat }
}
def defaultDateFormat = DateFormat.getDateInstance
(DateFormat.DEFAULT, S.locale)
def shortDateFormat = makeDateFormat("date.short.formatter",
DateFormat.SHORT)
def mediumDateFormat = makeDateFormat("date.medium.formatter",
DateFormat.MEDIUM)
def longDateFormat = makeDateFormat("date.long.formatter",
DateFormat.LONG)
def fullDateFormat = makeDateFormat("date.full.formatter",
DateFormat.FULL)
final protected def parseDate(s: String): Box[Date] = {
try {
Full(dateParser.parse(s))
} catch {
case _ => Empty
}
}
}
Have fun with it.
Dirk Louwers
On Oct 7, 9:31 am, Jeppe Nejsum Madsen wrote:
> Dirk Louwers writes:
>
> > If it would be at all usefull I'd be happy to share the code.
>
> Please do. I'll eventually have to support different locales at some
> point
>
> /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: Override the display names for (Mega)ProtoUser
Thanks, works like a charm. Am quite happy with the way Lift calculates the locale at the moment though. Dirk On Oct 7, 2:25 pm, Timothy Perrett wrote: > An example of locale calculator can be found here:http://is.gd/1NXGN > > Cheers, Tim > > On 7 Oct 2009, at 13:04, Jeppe Nejsum Madsen wrote: > > > > > Dirk Louwers writes: > > >> Cheers, > > >> I've finished the translation. Who do I send the file to for > >> integration and how can I have Lift pick it up in the meanwhile? > > > You can place the file in src/main/resources/i18n and set the locale > > using LiftRules.localeCalculator > > > /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: Supporting Jetty 7 Continuations
I was hoping to generically support Servlet 3.0 continuations (which should
work for Jetty 7 and Glassfish). Please open a ticket for it.
On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett wrote:
>
> Guys,
>
> I just wanted to rename this thread and raise this for proper
> discussion. API's between J6.x and J7.x appear to be the same, its
> mainly the package names and structure that have changed.
>
> Is it feasible to add a match statement to replace the current val
> assignments that have essentially hardcoded dependency on J6.x?
>
> There's some great stuff in Jetty 7 that would really help me (and
> lots of others) out
>
> Cheers, Tim
>
> On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > Id say that it would be easier to use a match statement as part of the
> > val assignment... The current code is just using reflection, so
> > factoring into a case statement shouldnt be too tough right?
> >
> > Thoughts?
> >
> > Cheers, Tim
> >
> > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> >
> >
> >
> >
> >
> > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> >
> > >> So I just wrote a Jetty 6 wrapper - getting the packaging working was
> > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> >
> > > Yes, just took a look at jetty-runner. Feature wise, it's blows away
> > > the
> > > older mechanism man!
> >
> > >> Any thoughts in and around altering the lift code to adjust the
> > >> package based on jetty version?
> >
> > > I can think of two options basically:
> >
> > > 1. Move to jetty 7 and be done with it.
> >
> > > 2. Allowing user option (via -Djetty.version) during
> > > archetype:generate.
> > > jetty.version can be an overridable archetype property that defaults
> > > to
> > > (say 6) but user can do -Djetty.version=7.
> >
> > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > filtered
> > > to make the right kind of adjustment during archetype creation.
> >
> > > Cheers, Indrajit
> >
> > >> Cheers, Tim
> >
> > >> On Oct 5, 9:07 am, Timothy Perrett wrote:
> > >>> Indrajit,
> >
> > >>> Your right, jetty-runner is Jetty 7. The only tie we have to Jetty 6
> > >>> would be this line:
> >
> > >>> val cc = Class.forName
> > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> >
> > >>> It would be trivial to add a match or whatever that determined the
> > >>> correct type to use... The question is, why haven't we done this
> > >>> already? I suspect its just a time / capacity issue but wanted to
> > >>> check.
> >
> > >>> I know I could write a jetty 6 wrapper, but that is my fallback
> > >>> position as something more OOTB would be preferable.
> >
> > >>> Cheers, Tim
> >
> > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > >>> wrote:
> >
> > Tim,
> >
> > Interestingly, we are trying out something similar in a project
> > here and
> > this is absolutely cool stuff.
> >
> > In fact, Zimbra Desktop does this too. Pure Prism+Jetty bundled as
> > 'desktop application'.
> >
> > That you can have 'double-click' friendly application helps :-)
> >
> > Few notes:
> >
> > 1. Embedding Jetty server is super easy with
> > org.mortbay.jetty.Server.
> > Something that we have in Lift - well almost ;-) The RunWebApp in
> > the
> > archetypes are primitive use case of such. [1]
> >
> > 2. Jetty Runner is available only on Jetty 7.x series I think (not
> > certain). But yes, looks good either way.
> >
> > 3. Jetty has this clean and nice way of having web-app specific
> > jetty
> > config tucked inside the application (war or expanded) within
> > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > instance
> > applied on the specific WebApplicationContext instead of the
> > Container
> > Context. [2]
> >
> > 4. An archetype that does self deploying is something that I have
> > on my
> > todo-list. Do you think this would make sense?
> >
> > 5. Maven assembly plugin would do. I haven't tried this myself, but
> > Maven shade plugin looks something close. [3]
> >
> > [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> > [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
> > [3]http://maven.apache.org/plugins/maven-shade-plugin/
> >
> > Cheers, Indrajit
> >
> > NB: Looks like quite a few night owl here!
> >
> > On 05/10/09 4:11 AM, Timothy Perrett wrote:
> >
> > > Viktor, you and I should not be up this late on a sunday! ;-)
> >
> > > You have to see this:http://blogs.webtide.com/janb/entry/
> > > jetty_runner
> >
> > > Im going to hash this together as a maven assembly; if it works,
> > > then
> > > i'll write a blog and stuff it on the wiki... this could really
> > > make
> > > self deploying apps very nice indeed. I'll check with DavidB,
> > > but im
> > > fairly sure it would also be trivial to make a little maven plugin
> > > that builds a single
[Lift] Re: How to suppress / override / escape context path rewriting?
It's possible, but not easy. Please open a ticket for "exclude certain paths during URL re-write" and I'll work on it tomorrow. On Tue, Oct 6, 2009 at 10:07 AM, Ross Mellgren wrote: > > I'm deploying a Lift application into JBoss as another WAR alongside > the rest of our application in a separate WAR, and I'm running into > problems with the context path rewriting. I've deployed my WAR with an > appropriate jboss-web.xml file which sets the context path to /myapp, > and now I'd like to construct relative URLs that go out to the other > WAR, e.g. > > Home > > but Lift rewrites anything starting with / to have the context path, > so instead I get > > Home > > This is mostly the right thing, and I don't really want to disable it > globally (especially because then the /ajax_request paths and so on > would probably go wrong), but I'd really like a way to escape it. The > only ways so far I've found are: > > 1) Use /../mainapp/home, which rewrites to /myapp/../mainapp/home, > which comes out right but seems pretty freaking ugly and depends on my > context path only having one segment > 2) Use fully-qualified URLs. This has the problem that I can't easily > construct these URLs in templates without having some kind of snippet > that expands it for me. > > What I'd ideally like is some special syntax to "escape" context > rewriting (e.g. //mainapp/home, or something else), or some guidance > on how people usually accomplish this and so on. > > Any ideas? I'm using 1.1-SNAPSHOT. > > -Ross > > > > > -- 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 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: Started integrating lift in a scala+spring project. Feedback?
In Lift 1.1, there is no S.servletSession method.
Without a session, you cannot find the context and even with a session, you
have to look to see if the session is associated with a particular provider
(Lift-speak for the thing that's forwarding requests to Lift).
Your best bet is to go find some Java static thing that's going to give you
the ServletContext
On Wed, Oct 7, 2009 at 1:12 AM, rintcius wrote:
>
> Yes, but I am referring to the case when there is no Full(session).
> I.e. how do I get the servlet context in the 2nd case at the place
> where I am currently throwing a RTE.
>
> def servletContext = {
>S.servletSession match {
> case Full(session) => session.getServletContext()
> case _ => throw new RuntimeException("no session")
> }
> }
>
>
>
> >
>
--
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 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] Eclipse & m2eclipse builds
Hello, I'd thought I'd try using m2eclipse's SCM import to load the lift trunk source from git and use Eclipse 3.5 + m2eclipse 0.9.8 as the build mechanism. I have the scala 2.7.5 plugin loaded and have made some progress cleaning up the build in Eclipse, adding the Scala nature and such. I encountered these errors that I can just delete from the problems view but I'm just getting started with scala and thought I'd ask wherein these problems truly lie. Thanks. I'm looking forward to trying out the JPA integration! Description ResourcePathLocationType error while loading Box, class file '/home/dols/workspace/lift/lift- util/target/classes/net/liftweb/util/Box.class' is broken (package does not have a member def)lift-webkit Unknown Scala Problem error while loading FatLazy, class file '/home/dols/workspace/lift/ lift-util/target/classes/net/liftweb/util/FatLazy.class' is broken (package does not have a member Empty) lift-webkit Unknown Scala Problem error while loading JsonCmd, class file '/home/dols/workspace/lift/ lift-util/target/classes/net/liftweb/util/JsonCmd.class' is broken (package does not have a member trait) lift-webkit Unknown Scala Problem error while loading LAFuture, class file '/home/dols/workspace/lift/ lift-actor/target/classes/net/liftweb/actor/LAFuture.class' is broken (package does not have a member def)lift-webkit Unknown Scala Problem error while loading NamedPF, class file '/home/dols/workspace/lift/ lift-util/target/classes/net/liftweb/util/NamedPF.class' is broken (package does not have a member object) lift-webkit Unknown Scala Problem error while loading PCDataXmlParser, class file '/home/dols/workspace/ lift/lift-util/target/classes/net/liftweb/util/PCDataXmlParser.class' is broken (package does not have a member val)lift-webkit Unknown Scala Problem error while loading ThreadGlobal, class file '/home/dols/workspace/ lift/lift-util/target/classes/net/liftweb/util/ThreadGlobal.class' is broken (package does not have a member def)lift-webkit Unknown Scala Problem error while loading AnyVar, class file '/home/dols/workspace/lift/lift- util/target/classes/net/liftweb/util/AnyVar.class' is broken (package does not have a member lazy) lift-webkit Unknown Scala Problem --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Having trouble with form submission when using JavaScript to fetch the template
My JavaScript/JQuery programming is weak and I'm not sure how to
explain the issue I'm having, but here goes...
I have a simple template for editing and saving changes to a Mapper
object:
def edit(item: ModelType) =
{item.toForm(Full("Save"), { _.save })}
When I use a snippet to display the template on my page, the Save
submit button works fine. However,
when I grap the template from JavaScript on the client, using a
function like:
$('#show-form').load('/http:localhost:8080/getform');
the Save button doesn't work. Changes made on the form don't get
saved. Here, the URL in load is intercepted
in a dispatch rule that simply calls a function that gets the Mapper
object from the DB and returns the template in a LiftResponse, like
so:
Full(CreatedResponse(edit(foundItem), "text/xml"))
Is the problem with JavaScript in this case or is there something in
the dispatch rule that I'm failing to do?
Any thoughts would be appreciated.
Glenn
--~--~-~--~~~---~--~~
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: Supporting Jetty 7 Continuations
I know that has been the plan - but I cant help but think that Servlet
3.0 is still a long way off standardisation?
What do you think?
Cheers, Tim
On 7 Oct 2009, at 16:53, David Pollak wrote:
> I was hoping to generically support Servlet 3.0 continuations (which
> should work for Jetty 7 and Glassfish). Please open a ticket for it.
>
> On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > wrote:
>
> Guys,
>
> I just wanted to rename this thread and raise this for proper
> discussion. API's between J6.x and J7.x appear to be the same, its
> mainly the package names and structure that have changed.
>
> Is it feasible to add a match statement to replace the current val
> assignments that have essentially hardcoded dependency on J6.x?
>
> There's some great stuff in Jetty 7 that would really help me (and
> lots of others) out
>
> Cheers, Tim
>
> On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > Id say that it would be easier to use a match statement as part of
> the
> > val assignment... The current code is just using reflection, so
> > factoring into a case statement shouldnt be too tough right?
> >
> > Thoughts?
> >
> > Cheers, Tim
> >
> > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> >
> >
> >
> >
> >
> > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> >
> > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> working was
> > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> >
> > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> away
> > > the
> > > older mechanism man!
> >
> > >> Any thoughts in and around altering the lift code to adjust the
> > >> package based on jetty version?
> >
> > > I can think of two options basically:
> >
> > > 1. Move to jetty 7 and be done with it.
> >
> > > 2. Allowing user option (via -Djetty.version) during
> > > archetype:generate.
> > > jetty.version can be an overridable archetype property that
> defaults
> > > to
> > > (say 6) but user can do -Djetty.version=7.
> >
> > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > filtered
> > > to make the right kind of adjustment during archetype creation.
> >
> > > Cheers, Indrajit
> >
> > >> Cheers, Tim
> >
> > >> On Oct 5, 9:07 am, Timothy Perrett
> wrote:
> > >>> Indrajit,
> >
> > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> Jetty 6
> > >>> would be this line:
> >
> > >>> val cc = Class.forName
> > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> >
> > >>> It would be trivial to add a match or whatever that determined
> the
> > >>> correct type to use... The question is, why haven't we done this
> > >>> already? I suspect its just a time / capacity issue but wanted
> to
> > >>> check.
> >
> > >>> I know I could write a jetty 6 wrapper, but that is my fallback
> > >>> position as something more OOTB would be preferable.
> >
> > >>> Cheers, Tim
> >
> > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > >>> wrote:
> >
> > Tim,
> >
> > Interestingly, we are trying out something similar in a project
> > here and
> > this is absolutely cool stuff.
> >
> > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> bundled as
> > 'desktop application'.
> >
> > That you can have 'double-click' friendly application helps :-)
> >
> > Few notes:
> >
> > 1. Embedding Jetty server is super easy with
> > org.mortbay.jetty.Server.
> > Something that we have in Lift - well almost ;-) The
> RunWebApp in
> > the
> > archetypes are primitive use case of such. [1]
> >
> > 2. Jetty Runner is available only on Jetty 7.x series I think
> (not
> > certain). But yes, looks good either way.
> >
> > 3. Jetty has this clean and nice way of having web-app specific
> > jetty
> > config tucked inside the application (war or expanded) within
> > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > instance
> > applied on the specific WebApplicationContext instead of the
> > Container
> > Context. [2]
> >
> > 4. An archetype that does self deploying is something that I
> have
> > on my
> > todo-list. Do you think this would make sense?
> >
> > 5. Maven assembly plugin would do. I haven't tried this
> myself, but
> > Maven shade plugin looks something close. [3]
> >
> > [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> > [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
> > [3]http://maven.apache.org/plugins/maven-shade-plugin/
> >
> > Cheers, Indrajit
> >
> > NB: Looks like quite a few night owl here!
> >
> > On 05/10/09 4:11 AM, Timothy Perrett wrote:
> >
> > > Viktor, you and I should not be up this late on a sunday! ;-)
> >
> > > You have to see this:http://blogs.webtide.com/janb/entry/
> > > jetty_runner
> >
> > > Im going to hash this together as a maven assembly; if it
> works,
> > > then
> > > i'll writ
[Lift] Re: Having trouble with form submission when using JavaScript to fetch the template
If it helps, the HTML produced is identical, regardless of how the
template
is fetched. So this might suggest there is a problem with Request
state regarding
the Mapper object, but I don't understand why that should be so.
Glenn
On Oct 7, 9:12 am, glenn wrote:
> My JavaScript/JQuery programming is weak and I'm not sure how to
> explain the issue I'm having, but here goes...
>
> I have a simple template for editing and saving changes to a Mapper
> object:
>
> def edit(item: ModelType) =
>
> {item.toForm(Full("Save"), { _.save })}
>
>
> When I use a snippet to display the template on my page, the Save
> submit button works fine. However,
> when I grap the template from JavaScript on the client, using a
> function like:
>
> $('#show-form').load('/http:localhost:8080/getform');
>
> the Save button doesn't work. Changes made on the form don't get
> saved. Here, the URL in load is intercepted
> in a dispatch rule that simply calls a function that gets the Mapper
> object from the DB and returns the template in a LiftResponse, like
> so:
>
> Full(CreatedResponse(edit(foundItem), "text/xml"))
>
> Is the problem with JavaScript in this case or is there something in
> the dispatch rule that I'm failing to do?
>
> Any thoughts would be appreciated.
>
> Glenn
--~--~-~--~~~---~--~~
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: Supporting Jetty 7 Continuations
On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett wrote:
>
> I know that has been the plan - but I cant help but think that Servlet
> 3.0 is still a long way off standardisation?
>
It's been 3 months away from being a standard for almost 2 years. ;-)
>
> What do you think?
>
> Cheers, Tim
>
>
> On 7 Oct 2009, at 16:53, David Pollak wrote:
>
> > I was hoping to generically support Servlet 3.0 continuations (which
> > should work for Jetty 7 and Glassfish). Please open a ticket for it.
> >
> > On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > > wrote:
> >
> > Guys,
> >
> > I just wanted to rename this thread and raise this for proper
> > discussion. API's between J6.x and J7.x appear to be the same, its
> > mainly the package names and structure that have changed.
> >
> > Is it feasible to add a match statement to replace the current val
> > assignments that have essentially hardcoded dependency on J6.x?
> >
> > There's some great stuff in Jetty 7 that would really help me (and
> > lots of others) out
> >
> > Cheers, Tim
> >
> > On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > > Id say that it would be easier to use a match statement as part of
> > the
> > > val assignment... The current code is just using reflection, so
> > > factoring into a case statement shouldnt be too tough right?
> > >
> > > Thoughts?
> > >
> > > Cheers, Tim
> > >
> > > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> > >
> > >
> > >
> > >
> > >
> > > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> > >
> > > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> > working was
> > > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> > >
> > > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> > away
> > > > the
> > > > older mechanism man!
> > >
> > > >> Any thoughts in and around altering the lift code to adjust the
> > > >> package based on jetty version?
> > >
> > > > I can think of two options basically:
> > >
> > > > 1. Move to jetty 7 and be done with it.
> > >
> > > > 2. Allowing user option (via -Djetty.version) during
> > > > archetype:generate.
> > > > jetty.version can be an overridable archetype property that
> > defaults
> > > > to
> > > > (say 6) but user can do -Djetty.version=7.
> > >
> > > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > > filtered
> > > > to make the right kind of adjustment during archetype creation.
> > >
> > > > Cheers, Indrajit
> > >
> > > >> Cheers, Tim
> > >
> > > >> On Oct 5, 9:07 am, Timothy Perrett
> > wrote:
> > > >>> Indrajit,
> > >
> > > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> > Jetty 6
> > > >>> would be this line:
> > >
> > > >>> val cc = Class.forName
> > > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> > >
> > > >>> It would be trivial to add a match or whatever that determined
> > the
> > > >>> correct type to use... The question is, why haven't we done this
> > > >>> already? I suspect its just a time / capacity issue but wanted
> > to
> > > >>> check.
> > >
> > > >>> I know I could write a jetty 6 wrapper, but that is my fallback
> > > >>> position as something more OOTB would be preferable.
> > >
> > > >>> Cheers, Tim
> > >
> > > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > > >>> wrote:
> > >
> > > Tim,
> > >
> > > Interestingly, we are trying out something similar in a project
> > > here and
> > > this is absolutely cool stuff.
> > >
> > > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> > bundled as
> > > 'desktop application'.
> > >
> > > That you can have 'double-click' friendly application helps :-)
> > >
> > > Few notes:
> > >
> > > 1. Embedding Jetty server is super easy with
> > > org.mortbay.jetty.Server.
> > > Something that we have in Lift - well almost ;-) The
> > RunWebApp in
> > > the
> > > archetypes are primitive use case of such. [1]
> > >
> > > 2. Jetty Runner is available only on Jetty 7.x series I think
> > (not
> > > certain). But yes, looks good either way.
> > >
> > > 3. Jetty has this clean and nice way of having web-app specific
> > > jetty
> > > config tucked inside the application (war or expanded) within
> > > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > > instance
> > > applied on the specific WebApplicationContext instead of the
> > > Container
> > > Context. [2]
> > >
> > > 4. An archetype that does self deploying is something that I
> > have
> > > on my
> > > todo-list. Do you think this would make sense?
> > >
> > > 5. Maven assembly plugin would do. I haven't tried this
> > myself, but
> > > Maven shade plugin looks something close. [3]
> > >
> > > [1]http://docs.codehaus.org/display/JETTY/Embedding+Jetty
> > > [2]http://docs.codehaus.org/display/JETTY/jetty-web.xml
> > > [3]http://maven.apache.org/plugins/maven-shade-plugin/
> > >
> > > Cheers, Indrajit
[Lift] Re: Supporting Jetty 7 Continuations
My point exactly!
To that end, why dont we just add a small matching statement or switch
that allows using Jetty 7 - only the package structure has changed not
the continuation API itself so it should be fairly trivial. The jetty-
runner stuff would really get me out of jetty-wrapper-hell that im in
right now and would mean we could create an archetype that allows Lift
apps to be deployable as a standalone JAR with jetty built in... would
that not be über cool?
Cheers, Tim
On 7 Oct 2009, at 17:30, David Pollak wrote:
>
>
> On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett > wrote:
>
> I know that has been the plan - but I cant help but think that Servlet
> 3.0 is still a long way off standardisation?
>
> It's been 3 months away from being a standard for almost 2 years. ;-)
>
>
> What do you think?
>
> Cheers, Tim
>
>
> On 7 Oct 2009, at 16:53, David Pollak wrote:
>
> > I was hoping to generically support Servlet 3.0 continuations (which
> > should work for Jetty 7 and Glassfish). Please open a ticket for
> it.
> >
> > On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > > wrote:
> >
> > Guys,
> >
> > I just wanted to rename this thread and raise this for proper
> > discussion. API's between J6.x and J7.x appear to be the same, its
> > mainly the package names and structure that have changed.
> >
> > Is it feasible to add a match statement to replace the current val
> > assignments that have essentially hardcoded dependency on J6.x?
> >
> > There's some great stuff in Jetty 7 that would really help me (and
> > lots of others) out
> >
> > Cheers, Tim
> >
> > On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > > Id say that it would be easier to use a match statement as part of
> > the
> > > val assignment... The current code is just using reflection, so
> > > factoring into a case statement shouldnt be too tough right?
> > >
> > > Thoughts?
> > >
> > > Cheers, Tim
> > >
> > > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
> > >
> > >
> > >
> > >
> > >
> > > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
> > >
> > > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> > working was
> > > >> not ideal and not as flexible as Jetty 7 jetty-runner.
> > >
> > > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> > away
> > > > the
> > > > older mechanism man!
> > >
> > > >> Any thoughts in and around altering the lift code to adjust the
> > > >> package based on jetty version?
> > >
> > > > I can think of two options basically:
> > >
> > > > 1. Move to jetty 7 and be done with it.
> > >
> > > > 2. Allowing user option (via -Djetty.version) during
> > > > archetype:generate.
> > > > jetty.version can be an overridable archetype property that
> > defaults
> > > > to
> > > > (say 6) but user can do -Djetty.version=7.
> > >
> > > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > > filtered
> > > > to make the right kind of adjustment during archetype creation.
> > >
> > > > Cheers, Indrajit
> > >
> > > >> Cheers, Tim
> > >
> > > >> On Oct 5, 9:07 am, Timothy Perrett
> > wrote:
> > > >>> Indrajit,
> > >
> > > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> > Jetty 6
> > > >>> would be this line:
> > >
> > > >>> val cc = Class.forName
> > > >>> ("org.mortbay.util.ajax.ContinuationSupport")
> > >
> > > >>> It would be trivial to add a match or whatever that determined
> > the
> > > >>> correct type to use... The question is, why haven't we done
> this
> > > >>> already? I suspect its just a time / capacity issue but wanted
> > to
> > > >>> check.
> > >
> > > >>> I know I could write a jetty 6 wrapper, but that is my
> fallback
> > > >>> position as something more OOTB would be preferable.
> > >
> > > >>> Cheers, Tim
> > >
> > > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > > >>> wrote:
> > >
> > > Tim,
> > >
> > > Interestingly, we are trying out something similar in a
> project
> > > here and
> > > this is absolutely cool stuff.
> > >
> > > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> > bundled as
> > > 'desktop application'.
> > >
> > > That you can have 'double-click' friendly application
> helps :-)
> > >
> > > Few notes:
> > >
> > > 1. Embedding Jetty server is super easy with
> > > org.mortbay.jetty.Server.
> > > Something that we have in Lift - well almost ;-) The
> > RunWebApp in
> > > the
> > > archetypes are primitive use case of such. [1]
> > >
> > > 2. Jetty Runner is available only on Jetty 7.x series I think
> > (not
> > > certain). But yes, looks good either way.
> > >
> > > 3. Jetty has this clean and nice way of having web-app
> specific
> > > jetty
> > > config tucked inside the application (war or expanded) within
> > > WEB-INF/jetty-web.xml which is basically an XmlConfiguration
> > > instance
> > > applied on the specific WebApplicationContext instead of the
> > > Container
>
[Lift] Re: Started integrating lift in a scala+spring project. Feedback?
> Your best bet is to go find some Java static thing that's going to give you > the ServletContext Yes that could work, but is it an idea to make the liftServlet available as an object in Lift (when it has the right provider)? Then the servletContext can be obtained nicely via liftServlet.getServletContext() --~--~-~--~~~---~--~~ 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: Started integrating lift in a scala+spring project. Feedback?
My interpretation of DPP's last post was that he [or moreover, we the team] would not want the context accessible in a sessionless way. Cheers, Tim On 7 Oct 2009, at 18:40, rintcius wrote: > >> Your best bet is to go find some Java static thing that's going to >> give you >> the ServletContext > > Yes that could work, but is it an idea to make the liftServlet > available as an object in Lift (when it has the right provider)? > Then the servletContext can be obtained nicely via > liftServlet.getServletContext() > > > > > --~--~-~--~~~---~--~~ 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: Started integrating lift in a scala+spring project. Feedback?
On Wed, Oct 7, 2009 at 10:40 AM, rintcius wrote: > > > Your best bet is to go find some Java static thing that's going to give > you > > the ServletContext > > Yes that could work, but is it an idea to make the liftServlet > available as an object in Lift (when it has the right provider)? > That's not going to happen. We're moving away from globals/statics/singletons and to things being session-specific. > Then the servletContext can be obtained nicely via > liftServlet.getServletContext() > > > > > -- 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 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: Started integrating lift in a scala+spring project. Feedback?
Servlet dependencies are abstracted away by a dedicated layer from the
rest of Lift.
LiftRules.context match {
case c: HTTPServletContext => c.ctx // this is a ServletContext
case _ =>
}
So you can take the ServletContext and do your stuff with it. But in
this case you explicitly know that you are running Lift in a JEE web
container.
This abstraction is necessary to us in order to be able to run lift
apps in other no JEE containers (Netty, AsyncWeb, Portlets etc).
Br's,
Marius
On Oct 7, 8:40 pm, rintcius wrote:
> > Your best bet is to go find some Java static thing that's going to give you
> > the ServletContext
>
> Yes that could work, but is it an idea to make the liftServlet
> available as an object in Lift (when it has the right provider)?
> Then the servletContext can be obtained nicely via
> liftServlet.getServletContext()
--~--~-~--~~~---~--~~
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: Supporting Jetty 7 Continuations
Looks like you need to open a ticket for that :P
On Oct 8, 3:50 am, Timothy Perrett wrote:
> My point exactly!
>
> To that end, why dont we just add a small matching statement or switch
> that allows using Jetty 7 - only the package structure has changed not
> the continuation API itself so it should be fairly trivial. The jetty-
> runner stuff would really get me out of jetty-wrapper-hell that im in
> right now and would mean we could create an archetype that allows Lift
> apps to be deployable as a standalone JAR with jetty built in... would
> that not be über cool?
>
> Cheers, Tim
>
> On 7 Oct 2009, at 17:30, David Pollak wrote:
>
>
>
> > On Wed, Oct 7, 2009 at 9:19 AM, Timothy Perrett > > wrote:
>
> > I know that has been the plan - but I cant help but think that Servlet
> > 3.0 is still a long way off standardisation?
>
> > It's been 3 months away from being a standard for almost 2 years. ;-)
>
> > What do you think?
>
> > Cheers, Tim
>
> > On 7 Oct 2009, at 16:53, David Pollak wrote:
>
> > > I was hoping to generically support Servlet 3.0 continuations (which
> > > should work for Jetty 7 and Glassfish). Please open a ticket for
> > it.
>
> > > On Wed, Oct 7, 2009 at 2:23 AM, Timothy Perrett > > > wrote:
>
> > > Guys,
>
> > > I just wanted to rename this thread and raise this for proper
> > > discussion. API's between J6.x and J7.x appear to be the same, its
> > > mainly the package names and structure that have changed.
>
> > > Is it feasible to add a match statement to replace the current val
> > > assignments that have essentially hardcoded dependency on J6.x?
>
> > > There's some great stuff in Jetty 7 that would really help me (and
> > > lots of others) out
>
> > > Cheers, Tim
>
> > > On Oct 5, 5:20 pm, Timothy Perrett wrote:
> > > > Id say that it would be easier to use a match statement as part of
> > > the
> > > > val assignment... The current code is just using reflection, so
> > > > factoring into a case statement shouldnt be too tough right?
>
> > > > Thoughts?
>
> > > > Cheers, Tim
>
> > > > On 5 Oct 2009, at 16:48, Indrajit Raychaudhuri wrote:
>
> > > > > On 05/10/09 5:29 PM, Timothy Perrett wrote:
>
> > > > >> So I just wrote a Jetty 6 wrapper - getting the packaging
> > > working was
> > > > >> not ideal and not as flexible as Jetty 7 jetty-runner.
>
> > > > > Yes, just took a look at jetty-runner. Feature wise, it's blows
> > > away
> > > > > the
> > > > > older mechanism man!
>
> > > > >> Any thoughts in and around altering the lift code to adjust the
> > > > >> package based on jetty version?
>
> > > > > I can think of two options basically:
>
> > > > > 1. Move to jetty 7 and be done with it.
>
> > > > > 2. Allowing user option (via -Djetty.version) during
> > > > > archetype:generate.
> > > > > jetty.version can be an overridable archetype property that
> > > defaults
> > > > > to
> > > > > (say 6) but user can do -Djetty.version=7.
>
> > > > > Depending on the jetty version, the *.scala, *.xml etc. can be
> > > > > filtered
> > > > > to make the right kind of adjustment during archetype creation.
>
> > > > > Cheers, Indrajit
>
> > > > >> Cheers, Tim
>
> > > > >> On Oct 5, 9:07 am, Timothy Perrett
> > > wrote:
> > > > >>> Indrajit,
>
> > > > >>> Your right, jetty-runner is Jetty 7. The only tie we have to
> > > Jetty 6
> > > > >>> would be this line:
>
> > > > >>> val cc = Class.forName
> > > > >>> ("org.mortbay.util.ajax.ContinuationSupport")
>
> > > > >>> It would be trivial to add a match or whatever that determined
> > > the
> > > > >>> correct type to use... The question is, why haven't we done
> > this
> > > > >>> already? I suspect its just a time / capacity issue but wanted
> > > to
> > > > >>> check.
>
> > > > >>> I know I could write a jetty 6 wrapper, but that is my
> > fallback
> > > > >>> position as something more OOTB would be preferable.
>
> > > > >>> Cheers, Tim
>
> > > > >>> On Oct 5, 8:29 am, Indrajit Raychaudhuri
> > > > >>> wrote:
>
> > > > Tim,
>
> > > > Interestingly, we are trying out something similar in a
> > project
> > > > here and
> > > > this is absolutely cool stuff.
>
> > > > In fact, Zimbra Desktop does this too. Pure Prism+Jetty
> > > bundled as
> > > > 'desktop application'.
>
> > > > That you can have 'double-click' friendly application
> > helps :-)
>
> > > > Few notes:
>
> > > > 1. Embedding Jetty server is super easy with
> > > > org.mortbay.jetty.Server.
> > > > Something that we have in Lift - well almost ;-) The
> > > RunWebApp in
> > > > the
> > > > archetypes are primitive use case of such. [1]
>
> > > > 2. Jetty Runner is available only on Jetty 7.x series I think
> > > (not
> > > > certain). But yes, looks good either way.
>
> > > > 3. Jetty has this clean and nice way of having web-app
> > specific
> > > > jetty
> > > > config tucked inside the application (war or expanded) within
> > > > WEB-INF/jetty-w
[Lift] Re: How to suppress / override / escape context path rewriting?
That is a pretty good suggestion, unfortunately my cocktail-napkin
example of what I was doing was missing out on the fact that the other
application has contextPath "/" -- but, there are some well known
prefixes under there so your technique could still work for me, it
would just require a set of rules instead of just one.
Thanks,
-Ross
On Oct 7, 2009, at 4:02 AM, AndrewM wrote:
>
> Hi,
>
> Perhaps a bit of a hack, but a redirect like the following might do
> the trick:
>
>LiftRules.dispatch.prepend(NamedPF("redirect context/mainapp
> requests to mainapp") {
>case Req("mainapp" :: page, "", _) => () =>
> Full(RedirectResponse(S.hostAndPath.replace(S.contextPath, "") +
> S.uri))
> })
>
> This will let Lift do it's rewriting and add in the webapp context,
> and you can use links like /mainapp/* in your templates... the
> redirect catches those requests and does an absolute redirect using
> the hostname etc. - so Lift doesn't try to add in the context. Any
> good?
>
> Andrew
>
> On Oct 7, 1:21 am, Derek Chen-Becker wrote:
>> I don't know of any way to do this currently. If no one else has
>> any ideas,
>> I would open an issue.
>>
>> Derek
>>
>> On Tue, Oct 6, 2009 at 11:07 AM, Ross Mellgren
>> wrote:
>>
>>> I'm deploying a Lift application into JBoss as another WAR alongside
>>> the rest of our application in a separate WAR, and I'm running into
>>> problems with the context path rewriting. I've deployed my WAR
>>> with an
>>> appropriate jboss-web.xml file which sets the context path to /
>>> myapp,
>>> and now I'd like to construct relative URLs that go out to the other
>>> WAR, e.g.
>>
>>> Home
>>
>>> but Lift rewrites anything starting with / to have the context path,
>>> so instead I get
>>
>>> Home
>>
>>> This is mostly the right thing, and I don't really want to disable
>>> it
>>> globally (especially because then the /ajax_request paths and so on
>>> would probably go wrong), but I'd really like a way to escape it.
>>> The
>>> only ways so far I've found are:
>>
>>> 1) Use /../mainapp/home, which rewrites to /myapp/../mainapp/home,
>>> which comes out right but seems pretty freaking ugly and depends
>>> on my
>>> context path only having one segment
>>> 2) Use fully-qualified URLs. This has the problem that I can't
>>> easily
>>> construct these URLs in templates without having some kind of
>>> snippet
>>> that expands it for me.
>>
>>> What I'd ideally like is some special syntax to "escape" context
>>> rewriting (e.g. //mainapp/home, or something else), or some guidance
>>> on how people usually accomplish this and so on.
>>
>>> Any ideas? I'm using 1.1-SNAPSHOT.
>>
>>> -Ross
>
> >
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: How to suppress / override / escape context path rewriting?
Created, thanks! http://github.com/dpp/liftweb/issues/#issue/83 -Ross On Oct 7, 2009, at 11:56 AM, David Pollak wrote: > It's possible, but not easy. Please open a ticket for "exclude > certain paths during URL re-write" and I'll work on it tomorrow. > > On Tue, Oct 6, 2009 at 10:07 AM, Ross Mellgren > wrote: > > I'm deploying a Lift application into JBoss as another WAR alongside > the rest of our application in a separate WAR, and I'm running into > problems with the context path rewriting. I've deployed my WAR with an > appropriate jboss-web.xml file which sets the context path to /myapp, > and now I'd like to construct relative URLs that go out to the other > WAR, e.g. > > Home > > but Lift rewrites anything starting with / to have the context path, > so instead I get > > Home > > This is mostly the right thing, and I don't really want to disable it > globally (especially because then the /ajax_request paths and so on > would probably go wrong), but I'd really like a way to escape it. The > only ways so far I've found are: > > 1) Use /../mainapp/home, which rewrites to /myapp/../mainapp/home, > which comes out right but seems pretty freaking ugly and depends on my > context path only having one segment > 2) Use fully-qualified URLs. This has the problem that I can't easily > construct these URLs in templates without having some kind of snippet > that expands it for me. > > What I'd ideally like is some special syntax to "escape" context > rewriting (e.g. //mainapp/home, or something else), or some guidance > on how people usually accomplish this and so on. > > Any ideas? I'm using 1.1-SNAPSHOT. > > -Ross > > > > > > > -- > 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 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] MappedLong & null values
I have a long field in my database that I want to have a unique index (enforced by the database). Sometimes this field will be empty, in which case I'd like to set it to NULL. 0 won't work because that won't work with the unique index. MappedLong appears to be converting null to 0 internally. Additionally overriding defaultValue for the field and returning null does not appear to work. Is this by design? Is it possible that I am misunderstanding something here? -harryh --~--~-~--~~~---~--~~ 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] PayPal Subscriptions
I'm receiving IPN updates from PayPal when a subcription is created and when it is canceled. However, the cancel message never make it to my actions method. Apparently, the cancel message does not include the payment_status. I think this results in the message being dropped on the floor because of the for-comprehension on line 458 in Paypal.scala. Would appreciate any help. By the way, we've been using the paypal module in production for a couple months now (a very small app for selling a partner-branded version of our screen recorder). Thanks, Ryan --~--~-~--~~~---~--~~ 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: MappedLong & null values
On Wed, Oct 7, 2009 at 12:55 PM, harryh wrote: > > I have a long field in my database that I want to have a unique index > (enforced by the database). Sometimes this field will be empty, in > which case I'd like to set it to NULL. 0 won't work because that > won't work with the unique index. > > MappedLong appears to be converting null to 0 internally. > Additionally overriding defaultValue for the field and returning null > does not appear to work. > > Is this by design? Yes. > Is it possible that I am misunderstanding something > here? > I think you're looking for a MappedOptLong which will treat None (or Empty) as NULL and Some(Long) as the value. Please open a ticket and I'll add the code. > > -harryh > > > > -- 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 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: Started integrating lift in a scala+spring project. Feedback?
Thanks Marius, that was what I was looking for! So in 1.0.2 I can call: def servletContext = LiftRules.context And when I upgrade to 1.1. I will change that into your suggestion. --~--~-~--~~~---~--~~ 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] API data linked to a user
I'm doing a prototype (learning a little bit more of everything) just for fun using lift and a Firefox extension to understand the usual infrastructure of a delicious api kinda thing. Right now i have the communication from the FFext to a restApi in scala (and it was painless to do it =) ), but right now im sending the username and password in each request so the api can decide if the information should be stored and if so, linked to what user. Analyzing a little bit of code of other firefox extensions and some network behaviour i realize most of them are not sending that auth information in every request, but the server already have a way to associate a session with the FFext(im not sure). So the options i have so far are: ->keep sending the username and password(not a good idea) ->keep sending the username and password encripted(any ideas what algorithm to use here?) ->Generate a token after the login and after that handshake trust that token(any guideline on the use of this tokens? possible security issues?) ->Use a OAuth server/cliente industry standard bullet-proof handshack Also, i would like to know how important is to encrypt the bjax (browser ajax) post information? Im sending information i would like to know its secure. I just wanted to bring this ideas to the table to know a little bit more of the best practices and security involved in this kind of projects and if someone has a very simple solution to "trusting" a input received like this and/or how to link this to a user, help me brainstorm pls =) --~--~-~--~~~---~--~~ 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: Mapper SQL issues w/ Oracle
Please file an issue for the first one on Git: http://github.com/dpp/liftweb/issues As for logging the generated SQL, check out this thread: http://groups.google.com/group/liftweb/browse_thread/thread/36b9080ded72d6e5/b9e7e5724f6594e3?hl=en&lnk=gst&q=logging#b9e7e5724f6594e3 Let me know if that doesn't show you what's being executed. Derek On Tue, Oct 6, 2009 at 11:27 PM, pbridger wrote: > > Hi all, > > I've noticed a couple of SQL-generation problems when using lift > (1.0.2) with oracle (10.2, and using latest drivers). > > Firstly, schemify fails on adding a column to a model: > INFO - ALTER TABLE table_name ADD COLUMN label VARCHAR(1000) > ERROR - Failed to Boot > java.sql.SQLException: ORA-00904: : invalid identifier > > The correct syntax for this in oracle is: > ALTER TABLE table_name ADD label VARCHAR(1000) > > Is this due to the oracle drivers not handling jdbc-standard sql? > > > Secondly, a CRUDify generated object list generates "ORA-00933: SQL > command not properly ended". > What's the best way to log SQL executed by mapper? > > > Thanks! > Paul > > > > --~--~-~--~~~---~--~~ 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: Naming CometActors
It's been a while since I looked at this, but IIRC, the name for CometActor is there so that you can distinguish multiple actors on the same page. I don't think that you share a CometActor between multiple requests. I think that each request gets a new CometActor that's in place as long as the page is active. Derek On Tue, Oct 6, 2009 at 1:28 PM, Jack Widman wrote: > > So if give a CometActor a static name, say "Other", then every request > will get the same running instance of the CometActor. But if I name it > dynamically, say with a random string, each request will get its own > instance of the CometActor. Right? > -- > 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: Naming CometActors
On Wed, Oct 7, 2009 at 2:39 PM, Derek Chen-Becker wrote: > It's been a while since I looked at this, but IIRC, the name for CometActor > is there so that you can distinguish multiple actors on the same page. I > don't think that you share a CometActor between multiple requests. I think > that each request gets a new CometActor that's in place as long as the page > is active. > Multiple requests share the same CometActor given type/name. The CometActor lives until the session ends or until it times out based on its lifespan. > > Derek > > > On Tue, Oct 6, 2009 at 1:28 PM, Jack Widman wrote: > >> >> So if give a CometActor a static name, say "Other", then every request >> will get the same running instance of the CometActor. But if I name it >> dynamically, say with a random string, each request will get its own >> instance of the CometActor. Right? >> -- >> Jack >> >> >> > > > > -- 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 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: Naming CometActors
The naming each CometActor with a different name is working quite nicely. On Wed, Oct 7, 2009 at 5:51 PM, David Pollak wrote: > > > On Wed, Oct 7, 2009 at 2:39 PM, Derek Chen-Becker > wrote: > >> It's been a while since I looked at this, but IIRC, the name for >> CometActor is there so that you can distinguish multiple actors on the same >> page. I don't think that you share a CometActor between multiple requests. I >> think that each request gets a new CometActor that's in place as long as the >> page is active. >> > > Multiple requests share the same CometActor given type/name. The > CometActor lives until the session ends or until it times out based on its > lifespan. > > >> >> Derek >> >> >> On Tue, Oct 6, 2009 at 1:28 PM, Jack Widman wrote: >> >>> >>> So if give a CometActor a static name, say "Other", then every request >>> will get the same running instance of the CometActor. But if I name it >>> dynamically, say with a random string, each request will get its own >>> instance of the CometActor. Right? >>> -- >>> Jack >>> >>> >>> >> >> >> > > > -- > 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 > > > > > -- 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: PayPal Subscriptions
Ryan, The PayPal stuff is pretty much my baby - its awesome that your using it in production! See what your saying - its been a while since I did anything with PayPal; what fields *are* returned when the transaction is canceled? Or, specifically, the question is what behaviour do you need? Lets start there and then I can work on a solution - it was my understanding that all responses from paypal had the payment_status field; im using the reference here: http://is.gd/43po4 can you detail the type of transaction you've been seeing this behaviour on? Cheers, Tim On 7 Oct 2009, at 20:56, Ryan Donahue wrote: > > I'm receiving IPN updates from PayPal when a subcription is created > and when it is canceled. However, the cancel message never make it to > my actions method. Apparently, the cancel message does not include > the payment_status. I think this results in the message being dropped > on the floor because of the for-comprehension on line 458 in > Paypal.scala. Would appreciate any help. By the way, we've been > using the paypal module in production for a couple months now (a very > small app for selling a partner-branded version of our screen > recorder). > > Thanks, > > Ryan > > > --~--~-~--~~~---~--~~ 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: Started integrating lift in a scala+spring project. Feedback?
Marius,
Out of interest, have you physically ran lift in asyncweb or netty?
Just thinking about the embedding possibilities...
Cheers, Tim
Sent from my iPhone
On 7 Oct 2009, at 19:50, "marius d." wrote:
>
> Servlet dependencies are abstracted away by a dedicated layer from the
> rest of Lift.
>
> LiftRules.context match {
>
> case c: HTTPServletContext => c.ctx // this is a ServletContext
>
> case _ =>
>
> }
>
>
> So you can take the ServletContext and do your stuff with it. But in
> this case you explicitly know that you are running Lift in a JEE web
> container.
>
> This abstraction is necessary to us in order to be able to run lift
> apps in other no JEE containers (Netty, AsyncWeb, Portlets etc).
>
> Br's,
> Marius
>
> On Oct 7, 8:40 pm, rintcius wrote:
>>> Your best bet is to go find some Java static thing that's going to
>>> give you
>>> the ServletContext
>>
>> Yes that could work, but is it an idea to make the liftServlet
>> available as an object in Lift (when it has the right provider)?
>> Then the servletContext can be obtained nicely via
>> liftServlet.getServletContext()
> >
>
--~--~-~--~~~---~--~~
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] problem in getting started
I followed the document at liftweb and here is what I get: PS C:\Users\Prabhat Gupta\work> mvn archetype:generate -U - DarchetypeGroupId=net.liftweb -DarchetypeArtifactId=lift-a rchetype-blank -DarchetypeVersion=1.0 -DremoteRepositories=http:// scala-tools.org/repo-releases -DgroupId=demo.hellow orld -DartifactId=helloworld -Dversion=1.0-SNAPSHOT [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from central [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task '.liftweb': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginG roupId:pluginArtifactId:pluginVersion:goal [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Oct 07 20:57:08 EDT 2009 [INFO] Final Memory: 4M/61M [INFO] PS C:\Users\Prabhat Gupta\work> --~--~-~--~~~---~--~~ 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: problem in getting started
Do try with -Dversion=1.1-SNAPSHOT and see. Which version of maven are you using? On Thu, Oct 8, 2009 at 8:57 AM, Prabhat wrote: > > I followed the document at liftweb and here is what I get: > > PS C:\Users\Prabhat Gupta\work> mvn archetype:generate -U - > DarchetypeGroupId=net.liftweb -DarchetypeArtifactId=lift-a > rchetype-blank -DarchetypeVersion=1.0 -DremoteRepositories=http:// > scala-tools.org/repo-releases -DgroupId=demo.hellow > orld -DartifactId=helloworld -Dversion=1.0-SNAPSHOT > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [INFO] org.apache.maven.plugins: checking for updates from central > [INFO] org.codehaus.mojo: checking for updates from central > [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: > checking for updates from central > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Invalid task '.liftweb': you must specify a valid lifecycle > phase, or a goal in the format plugin:goal or pluginG > roupId:pluginArtifactId:pluginVersion:goal > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Wed Oct 07 20:57:08 EDT 2009 > [INFO] Final Memory: 4M/61M > [INFO] > > PS C:\Users\Prabhat Gupta\work> > > > > --~--~-~--~~~---~--~~ 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: problem in getting started
It looks like you probably have a typo on the command line, although the command line you pasted is wrapped and so on, so I can't see it there. Look for erroneous spaces before ".liftweb" in your command line. -Ross On Oct 7, 2009, at 8:57 PM, Prabhat wrote: > > I followed the document at liftweb and here is what I get: > > PS C:\Users\Prabhat Gupta\work> mvn archetype:generate -U - > DarchetypeGroupId=net.liftweb -DarchetypeArtifactId=lift-a > rchetype-blank -DarchetypeVersion=1.0 -DremoteRepositories=http:// > scala-tools.org/repo-releases -DgroupId=demo.hellow > orld -DartifactId=helloworld -Dversion=1.0-SNAPSHOT > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [INFO] org.apache.maven.plugins: checking for updates from central > [INFO] org.codehaus.mojo: checking for updates from central > [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: > checking for updates from central > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Invalid task '.liftweb': you must specify a valid lifecycle > phase, or a goal in the format plugin:goal or pluginG > roupId:pluginArtifactId:pluginVersion:goal > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Wed Oct 07 20:57:08 EDT 2009 > [INFO] Final Memory: 4M/61M > [INFO] > > PS C:\Users\Prabhat Gupta\work> > > > --~--~-~--~~~---~--~~ 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: Binding a snippet in a comet actor?
Apologies for bumping this.
Is there a way to get the submit button (or an ajaxButton) to work if
the snippet which was not originally part of the page is bound by a
comet actor?
Thanks,
Som
On Oct 7, 12:32 pm, Somindra Bhattacharya
wrote:
> Thanks for responding, Naftoli.
>
> I tried changing the code to:
>
> def handleSubmit() =
> {
> Log.info("GOT A SUBMIT IN INVITE")
> net.liftweb.http.js.JsCmds.Run("alert('Hey')")
> }
>
> ajaxForm(
> bind("elem", xhtml,
> "submit" -> submit("Click", () => handleSubmit() ),
> ) ++ hidden(() => handleSubmit())
> )
>
> The handleSubmit method is still not called. I tried using ajaxButton
> instead of submit but that did not help either.
>
> What am I doing wrong?
>
> On Oct 7, 5:06 am, Naftoli Gugenheim wrote:
>
> > What about an Ajax form?
>
> > On Tue, Oct 6, 2009 at 9:52 AM, Somindra Bhattacharya
>
> > wrote:
>
> > > Hi Everyone,
>
> > > I have a comet actor that binds XHTML. The XHTML corresponds to a
> > > snippet:
>
> > > XHTML for comet actor ->
>
> > >
> > >
> > >
>
> > > When the comet actor receives a certain message, the render method of
> > > the comet actor binds the following XHTML ->
>
> > >
> > >
> > >
>
> > > The Discuss snippet's "invite" method definition is:
>
> > > def invite(xhtml: NodeSeq): NodeSeq =
> > > {
>
> > > def handleSubmit() =
> > > {
> > > Log.info("GOT A SUBMIT IN INVITE")
> > > }
>
> > > bind("elem", xhtml,
> > > "submit" -> submit("Click", () => handleSubmit()))
> > > }
>
> > > The page does not contain this form when it is first loaded. When the
> > > actor receives a certain message, it binds the XHTML (Discuss.invite)
> > > to the page and the form and the "submit" button are rendered
> > > properly.
>
> > > However, when I click on the submit button, the "handleSubmit" method
> > > is not called. Instead, the browser displays a page with the text
> > > "window.location=/".
> > > If I use the browser back button and re-visit the page with the comet
> > > actor, the submit button works (i.e., handleSubmit() is called and I
> > > can see the info log).
>
> > > Is this approach "legal"? Is there a way to make a form submit if it
> > > was not originally part of the page?
>
> > > Thanks,
> > > Som
--~--~-~--~~~---~--~~
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: problem in getting started
Prabhat, the command works fine for me, using Maven 2.0.9. Could it be a problem with a corporate proxy perhaps ? I executed : mvn archetype:generate -U -DarchetypeGroupId=net.liftweb - DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=1.0 - DremoteRepositories=http://scala-tools.org/repo-releases - DgroupId=demo.helloworld -DartifactId=helloworld -Dversion=1.0- SNAPSHOT --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
