[Lift] Re: Overriding date/time formatting
Derek Chen-Becker dchenbec...@gmail.com writes: I'm planning on making the formatting easier to configure and also to move the Mapper stuff to Joda Time. I know I keep saying this but I hope to start working on this next week :P Awesome! /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?
David,
Thanks for responding.
I have hosted the example at http://174.129.214.150:8080/
The code is at http://174.129.214.150:8080/dynamicForm.tar.gz
Here are the steps to reproduce the issue:
1. Open http://174.129.214.150:8080/ in a browser window. This starts
a comet actor which listens for messages. There is no form present on
this page.
2. Open http://174.129.214.150:8080/testdriver in another browser
window. Juxtapose these two windows.
3. Click on the Click here button in the window opened in (2).
Submitting this form results into a lift:Snippet block being sent to
the actor on the index page. This makes the index page show a form
that was not previously present.
4. Click on the button that has appeared on the index page. This does
not result into calling the handler at the server end.
Please let me know if you need more information.
Thanks again...
Regards,
Som
On Oct 8, 9:40 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
The chat example in demo.liftweb.net (source in examples/example) has a form
that is presented after the initial form is rendered. It works just fine.
Please put together a small example of the failure so I can see the running
code.
On Wed, Oct 7, 2009 at 9:13 PM, Somindra Bhattacharya
somind...@gmail.comwrote:
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 somind...@gmail.com
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 naftoli...@gmail.com wrote:
What about an Ajax form?
On Tue, Oct 6, 2009 at 9:52 AM, Somindra Bhattacharya
somind...@gmail.com wrote:
Hi Everyone,
I have a comet actor that binds XHTML. The XHTML corresponds to a
snippet:
XHTML for comet actor -
lift:comet type=RCActor
Act:act /
/lift:comet
When the comet actor receives a certain message, the render method of
the comet actor binds the following XHTML -
lift:Discuss.invite form=post
elem:submit /
/lift:Discuss.invite
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
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://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: java.lang.OutOfMemoryError: PermGen space, Could't start SessionMaster ping
Javarebel will certainly help here, but it wont solve the problem entirely as there are always going to be somethings that it cannot replace dynamically. Regarding the question about goals, this is the maven syntax: mvn goal goal... etc so, install, and jetty:run are goals in maven terminology. Cheers, Tim On Oct 9, 5:13 am, jon jonhoff...@gmail.com wrote: Yes, I think this will get you going with javarebel: MAVEN_OPTS=-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m - Xmx512m -noverify -javaagent:/path/to/jrebel-2.1/jrebel.jar mvn jetty:run in another terminal window mvn scala:cc get a free license here:http://www.zeroturnaround.com/scala-license/ - Jon On Oct 8, 10:18 pm, Alex Black a...@alexblack.ca wrote: Hi Jon, I haven't narrowed it down to being after a context reload or not. I'll try what you suggested and turn off jetty's reload and use javaRebel instead. Where would I set those JVM flags, should those go in MAVEN_OPTS? I'll keep SBT in mind... - ALex On Oct 8, 4:37 pm, jon jonhoff...@gmail.com wrote: Hi, Is this error occurring after a context reload? You may want to turn off context reloading in your mvn jetty configuration because, as far as i can tell, that has always been a completely broken feature. Do this by adding scanIntervalSeconds0/scanIntervalSeconds to the org.mortbay.jetty configuration/ You can setup javarebel if you want to avoid restarting the container for minor code changes. You may still run into permgen issues as javarebel reloads classes too. But, these JVM flags will help reduce the frequency further: -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128m (add to your MAVEN_OPTS env variable) I would also suggest looking into sbt as the continuous compilation is much more robust than scala:cc (it keeps track of dependencies and will recompile the entire tree). The only downside is there's no yui compressor plugin, yet. - Jon On Oct 8, 2:16 pm, Timothy Perrett timo...@getintheloop.eu wrote: Alex, Any reason your running the install goal? You really don't need to. Regarding the permgen: Can you show your maven options? You can improve the situation by setting a larger heap size, however this is an unfortunate thing that just goes along with jetty and maven. HTH Cheers, Tim On Oct 8, 7:10 pm, Alex Black a...@alexblack.ca wrote: I've encountered this error 3 times, running Jetty and Maven, just trying out Lift scala with a hello-world like website. I have to kill the JVM with kill -9 and restart things to fix it, any ideas? - Command line: mvn install jetty:run - I'm using Lift 1.0, Scala 2.7.6 final, 64bit JDK1.6.0_16, on Ubuntu Desktop x64. - My app is trivial, no comet or actors or mapping, one view, one class, lists records out of a postgres database table (which has 2 records in it, 2 columns) Here are the errors from the terminal running jetty, I am not sure if the actor/SessionMaster errors are related to the memory errors. ERROR - Couldn't start SessionMaster ping net.liftweb.util.ActorPingException: net.liftweb.http.SessionMaster $checkandpur...@7130bd0a could not be scheduled on net.liftweb.http.sessionmast...@36cb1594 at net.liftweb.util.ActorPing$.schedule(ActorPing.scala:51) at net.liftweb.http.SessionMaster$.net$liftweb$http$SessionMaster$ $doPing(LiftSession.scala:209) at net.liftweb.http.SessionMaster$$anonfun$act$1$$anonfun$apply $1.apply(LiftSession.scala:200) at net.liftweb.http.SessionMaster$$anonfun$act$1$$anonfun$apply $1.apply(LiftSession.scala:169) at scala.actors.Reaction.run(Reaction.scala:78) at scala.actors.FJTask$Wrap.run(Unknown Source) at scala.actors.FJTaskRunner.scanWhileIdling(Unknown Source) at scala.actors.FJTaskRunner.run(Unknown Source) Caused by: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor $AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1760) at java.util.concurrent.ThreadPoolExecutor.reject (ThreadPoolExecutor.java:767) at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute (ScheduledThreadPoolExecutor.java:216) at java.util.concurrent.ScheduledThreadPoolExecutor.schedule (ScheduledThreadPoolExecutor.java:379) at java.util.concurrent.Executors $DelegatedScheduledExecutorService.schedule(Executors.java:654) at net.liftweb.util.ActorPing$.schedule(ActorPing.scala:49) ... 7 more INFO - Service request (GET) / took 1411 Milliseconds INFO - Service request (GET) /classpath/jquery.js took 7 Milliseconds [INFO] restarting
[Lift] Re: Missing i18n in Lift?
On Thu, Oct 8, 2009 at 6:26 PM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Try LiftRules.formatDate and LiftRules.parseDate Yes, I'm aware of these and together with localeCalculator they can be made to work. For numbers, I've created http://github.com/dpp/liftweb/issues/#issue/92 /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] Use lift1.0 or 1.1 or 1.x to create a stable and large site(project) ?
Hi liftweb, Is anyone has used lift to create a stable and large site ? If i want to create this site which version that is suit, lift1.0 or higher version. If someone knows the site that develop by lift or has used lift to create a site, could you give me some ideas? Thanks very much! Cheers, Neil --~--~-~--~~~---~--~~ 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] Getting error -Access denied after deploying on Apps Engine
Hi , Its appreciate, If someone look into the issue ,while deploying on Google Apps Engine. Error Log. java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThreadGroup Thanks Technut --~--~-~--~~~---~--~~ 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: Getting error -Access denied after deploying on Apps Engine
Looks like some part of your program is creating threads or trying to modify them which is prohibited by AppEngine as far as I know. Please correct me if I'm wrong. Regards Stefan 2009/10/9 technut worldh...@gmail.com Hi , Its appreciate, If someone look into the issue ,while deploying on Google Apps Engine. Error Log. java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThreadGroup Thanks Technut --~--~-~--~~~---~--~~ 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: Getting error -Access denied after deploying on Apps Engine
Are you trying to use an actor or such? Thread spawning is not allowed on GAE... Cheers, Tim On 9 Oct 2009, at 07:29, technut wrote: Hi , Its appreciate, If someone look into the issue ,while deploying on Google Apps Engine. Error Log. java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThreadGroup Thanks Technut --~--~-~--~~~---~--~~ 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: Ext.Direct
Ok, the ExtJsArtifacts class and the companion script named liftExtJs is finished. I have tested them with the JSON example in the wiki since that seems to use a reasonable amount of functionality. All seems to be working. I would like to write a wiki page detailing how to get Ext support using these files if you think that will be usefull. Also, would you be interested in using this in the Lift distribution? Please advise. Best, Dirk Louwers On Oct 8, 5:04 pm, Dirk Louwers dirk.louw...@stormlantern.nl wrote: Ok, risking that someone else might also be busy doing this, for now, I am writing ExtJsCommands which depends on the MIT licensed Ext-Core 3. I will ask some questions when I am not sure about some things and will make sure I will add adequate comments so others might use them when adapting to another JS framework: - I take it that JsLeft and JsRight are there to chain effects/ operations on an element (visitor style). Is that correct? - Is ScrollToBottom there to make an element and it's siblings scroll to the bottom of the visible document? Is it supposed to be animated or instant? - I think that Click is meant to fire a click event on an element. However I am not sure what the exp: JsExp parameter is for. What does it do? That's it for now. Will continue my work later tonight. Best, Dirk Louwers On Oct 8, 4:07 pm, Dirk Louwers dirk.louw...@stormlantern.nl wrote: Any news on this? I am currently doing some rudimentary Ext.Direct stuff with Lift myself. I would gladly help out there. Best, Dirk Louwers On Aug 31, 7:30 pm, David Pollak feeder.of.the.be...@gmail.com wrote: On Sat, Aug 29, 2009 at 11:14 AM, Josh Suereth joshua.suer...@gmail.comwrote: I believe the core of ExtJS is now MIT licenesed (the widgets being GPL with Commercial licenses available). You could potentially build the Ajax calls on top of this (as long as you stay away from ui components). Then users who have bought an ExtJS subscription (like my company) would have a much easier time moving to lift! I believe the ExtJS core supports many of the same operations as jQuery's core. Josh, Feel free (encouraged, even) to do the ExtJS core layer for Lift... just ping me privately for the specifics of being a Lift committer. Thanks, David - Josh On Thu, Aug 27, 2009 at 5:53 PM, Charles F. Munat c...@munat.com wrote: I haven't used Ext.Direct yet, but I am currently building a site (three sites, really) that uses Ext JS 3.0 for the front end. One site is essentially a CRUD app. The back end is a PostgreSQL database. The middle layer is a Lift app that uses JPA/Hibernate to access the database. It provides a REST interface to the data that accepts and returns JSON. (I've hand written this but must learn more about Lift's JSON capabilities.) The front end is pure Ext JS. All connections to the database are via AJAX-like calls (AJAJ?). The REST interface is pretty pure, using only GET, PUT, and DELETE. (I like idempotency, so I don't use POST. The back end generates UUIDs and prepopulates the add forms with a UUID, then the create calls use the same URL as the update calls. If the object with that ID already exists, it is updated. If it doesn't, it is created. Thus all calls are idempotent. This also improves security, as you're, um, unlikely to guess a UUID.) I'd be happy to talk to you about this. It's still in the early stages, but I have to debut it in a couple weeks if not sooner (what's new?), so I'll be zooming through the front end stuff over the next few days. I plan for all future sites that I build in Lift to follow a similar pattern on the front end. Chas. Naftoli Gugenheim wrote: Has anyone used lift with Ext.JS forms/Ext.Direct? P.S. It would be neat if it could interact with Lift's JSON support. I wonder what it would take. -- Lift, the simply functional web frameworkhttp://liftweb.net Beginning Scalahttp://www.apress.com/book/view/1430219890 Follow me:http://twitter.com/dpp Git some:http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Use lift1.0 or 1.1 or 1.x to create a stable and large site(project) ?
I use Lift 1.1-SNAPSHOT on all the sites I work on (that's currently at 7). There's rarely breakage on SNAPSHOT. On Fri, Oct 9, 2009 at 3:01 AM, Neil.Lv anim...@gmail.com wrote: Hi liftweb, Is anyone has used lift to create a stable and large site ? If i want to create this site which version that is suit, lift1.0 or higher version. If someone knows the site that develop by lift or has used lift to create a site, could you give me some ideas? Thanks very much! Cheers, Neil -- 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: PayPal Subscriptions
Tim,
I locally changed the PaypalIPN.actions method return type to
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Apparently this does not cause any compilation errors for user
implementing their own IPN handler as follows
object MyIPN extends PaypalIPN {
import PaypalTransactionStatus._
def actions = {
case (CompletedPayment, info, req) = // do something
}
}
This is not good since I assume the result is that the case won't
match anymore but we won't have a compilation error to tell us to
change our code. Maybe I missed something, I am a scala newbie :)
-Ryan
On Oct 8, 3:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Ok cool, I'll take a look at this tomrrow all being well.
Thanks for the feedback
Cheers, Tim
Sent from my iPhone
On 8 Oct 2009, at 20:43, Ryan Donahue donahu...@gmail.com wrote:
I created the ticket:http://github.com/dpp/liftweb/issues/#issue/88
I do receive the payment_status field for PDT. I bet in practice
you will never receive a payment_status value other than Completed,
because if the payment was not completed PayPal would not redirect
the user's browser back to your PDT URL. However, I have not
verified this and do check the payment status in my PDT code anyway
(how could I verify that it will never happen?). So I would prefer
that both were consistent, but just boxing the IPN payment status
will be fine too :)
On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett timo...@getintheloop.eu
wrote:
Im not married to the current API, so breaking changes are OK as
there are only a handful of people using this code right now.
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it since
the beginning but just never got round to it and lack of general
demand.
Just about why they have a different signature... if memory serves
that would be because PaypalTransactionStatus is not supplied for
PDT. So whilst I see your point about them being consistent, im not
sure there is value in having a Box parameter that would always be
Empty? For IPN however, boxing sounds good to me.
Should just be a case of:
Box !! info.paymentStatus
Would you be happy with that? If you could raise a ticket for this
issue i'll patch it tomorrow and commit the code on a branch related
to that ticket. One the code goes through review then it will make
it into the master branch all being well.
Cheers, Tim
On 8 Oct 2009, at 18:52, Ryan Donahue wrote:
Yeah, I noticed my email got mangled.
It would make sense to me if PaypalIPN.actions and
PaypalPDT.pdtResponse were consistent.
trait PaypalPDT {
def pdtResponse: PartialFunction[(PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(PayPalInfo, Req), Unit]
}
If matching the status is just too convenient to lose, then how
about this.
trait PaypalPDT {
def pdtResponse: PartialFunction[(Box
[PaypalTransactionStatus.Value], PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Either would be an API breaking change for the paypal module, but
at least it'd be caught be the compiler. What do you think?
On Thu, Oct 8, 2009 at 1:33 PM, Timothy Perrett timo...@getintheloop.eu
wrote:
The parameters were pretty mangled in your email... Which one would
you propose is more generic that the current status one we have?
Alternatively, it sounds to me like we might need to add some kind of
special case match statement.
Thoughts?
Cheers, tim
On 8 Oct 2009, at 13:14, Ryan Donahue wrote:
Hi Tim,
Looking at Table 2. Summary of subscription variables of the page
you reference, payment_status is not included for messages with a
txn_type of subscr_ signup, subscr_ cancel, subscr_ modify, or
subscr_eot.
This matches the results I see in testing with PayPal Sandbox.
Neither subscr_signup or subscr_cancel include the payment_status.
Below are the parameters from two messages I have received (they
contain fake user info generated by PayPal Sandbox, so no security/
privacy concerns).
params from subscr_signup message:
btn_id - List(1070963), test_ipn - List(1), charset - List
(windows-1252), address_country - List(United States), item_name
-
List(Pro Account), recurring - List(1), address_state - List(CA),
amount3 - List(9.99), address_street - List(1 Main St),
verify_sign -
List(Ab4im9HUsk1pOL1dlUXJxEoipQcaAJQqV047JE2KENGFX4meCETo.KLt),
address_status - List(confirmed), period3 - List(1 M),
subscr_date -
List(05:01:02 Oct 08, 2009 PDT), first_name - List(Test),
address_country_code - List(US), address_city - List(San Jose),
mc_currency - List(USD), mc_amount3 -
[Lift] Re: Getting error -Access denied after deploying on Apps Engine
Did you set the in.gae.j System Property to true? On Thu, Oct 8, 2009 at 11:29 PM, technut worldh...@gmail.com wrote: Hi , Its appreciate, If someone look into the issue ,while deploying on Google Apps Engine. Error Log. java.security.AccessControlException: access denied (java.lang.RuntimePermission modifyThreadGroup Thanks Technut -- 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: PayPal Subscriptions
Hey Ryan,
How *exactly* did you locally do the build? If you had done the
install of your altered lift-paypal then you would certainly get a
compile error because the signature has changed. The new syntax should
be:
object MyIPN extends PaypalIPN {
def actions = {
case (Full(CompletedPayment), info, req) = // do something
}
}
The only exclusion would be if you had a implicit conversion to Box
PaypalTransactionStatus types that were unboxed.
Cheers, Tim
On Oct 9, 3:46 pm, Ryan Donahue donahu...@gmail.com wrote:
Tim,
I locally changed the PaypalIPN.actions method return type to
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Apparently this does not cause any compilation errors for user
implementing their own IPN handler as follows
object MyIPN extends PaypalIPN {
import PaypalTransactionStatus._
def actions = {
case (CompletedPayment, info, req) = // do something
}
}
This is not good since I assume the result is that the case won't
match anymore but we won't have a compilation error to tell us to
change our code. Maybe I missed something, I am a scala newbie :)
-Ryan
On Oct 8, 3:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Ok cool, I'll take a look at this tomrrow all being well.
Thanks for the feedback
Cheers, Tim
Sent from my iPhone
On 8 Oct 2009, at 20:43, Ryan Donahue donahu...@gmail.com wrote:
I created the ticket:http://github.com/dpp/liftweb/issues/#issue/88
I do receive the payment_status field for PDT. I bet in practice
you will never receive a payment_status value other than Completed,
because if the payment was not completed PayPal would not redirect
the user's browser back to your PDT URL. However, I have not
verified this and do check the payment status in my PDT code anyway
(how could I verify that it will never happen?). So I would prefer
that both were consistent, but just boxing the IPN payment status
will be fine too :)
On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett timo...@getintheloop.eu
wrote:
Im not married to the current API, so breaking changes are OK as
there are only a handful of people using this code right now.
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it since
the beginning but just never got round to it and lack of general
demand.
Just about why they have a different signature... if memory serves
that would be because PaypalTransactionStatus is not supplied for
PDT. So whilst I see your point about them being consistent, im not
sure there is value in having a Box parameter that would always be
Empty? For IPN however, boxing sounds good to me.
Should just be a case of:
Box !! info.paymentStatus
Would you be happy with that? If you could raise a ticket for this
issue i'll patch it tomorrow and commit the code on a branch related
to that ticket. One the code goes through review then it will make
it into the master branch all being well.
Cheers, Tim
On 8 Oct 2009, at 18:52, Ryan Donahue wrote:
Yeah, I noticed my email got mangled.
It would make sense to me if PaypalIPN.actions and
PaypalPDT.pdtResponse were consistent.
trait PaypalPDT {
def pdtResponse: PartialFunction[(PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(PayPalInfo, Req), Unit]
}
If matching the status is just too convenient to lose, then how
about this.
trait PaypalPDT {
def pdtResponse: PartialFunction[(Box
[PaypalTransactionStatus.Value], PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Either would be an API breaking change for the paypal module, but
at least it'd be caught be the compiler. What do you think?
On Thu, Oct 8, 2009 at 1:33 PM, Timothy Perrett timo...@getintheloop.eu
wrote:
The parameters were pretty mangled in your email... Which one would
you propose is more generic that the current status one we have?
Alternatively, it sounds to me like we might need to add some kind of
special case match statement.
Thoughts?
Cheers, tim
On 8 Oct 2009, at 13:14, Ryan Donahue wrote:
Hi Tim,
Looking at Table 2. Summary of subscription variables of the page
you reference, payment_status is not included for messages with a
txn_type of subscr_ signup, subscr_ cancel, subscr_ modify, or
subscr_eot.
This matches the results I see in testing with PayPal Sandbox.
Neither subscr_signup or subscr_cancel include the payment_status.
Below are the parameters from two messages I have received (they
contain fake user info generated by PayPal Sandbox, so no security/
privacy concerns).
[Lift] Re: java.lang.OutOfMemoryError: PermGen space, Could't start SessionMaster ping
A colleague of mine found these interesting articles regarding PerGen issues : http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded ~Rob --~--~-~--~~~---~--~~ 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
Well, I am a scala newb, but I know maven all too well. I ran mvn clean
install from the lift-paypal dir to install lift-paypal-1.1-SNAPSHOT.jar to
my local repo.
To be sure, I changed the signature as follows which does cause errors:
def actions: PartialFunction[(PayPalInfo, Req), Unit]
Change back to def actions:
PartialFunction[(Box[PaypalTransactionStatus.value], PayPalInfo, Req), Unit]
and no errors.
On Fri, Oct 9, 2009 at 12:35 PM, Timothy Perrett timo...@getintheloop.euwrote:
Hey Ryan,
How *exactly* did you locally do the build? If you had done the
install of your altered lift-paypal then you would certainly get a
compile error because the signature has changed. The new syntax should
be:
object MyIPN extends PaypalIPN {
def actions = {
case (Full(CompletedPayment), info, req) = // do something
}
}
The only exclusion would be if you had a implicit conversion to Box
PaypalTransactionStatus types that were unboxed.
Cheers, Tim
On Oct 9, 3:46 pm, Ryan Donahue donahu...@gmail.com wrote:
Tim,
I locally changed the PaypalIPN.actions method return type to
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Apparently this does not cause any compilation errors for user
implementing their own IPN handler as follows
object MyIPN extends PaypalIPN {
import PaypalTransactionStatus._
def actions = {
case (CompletedPayment, info, req) = // do something
}
}
This is not good since I assume the result is that the case won't
match anymore but we won't have a compilation error to tell us to
change our code. Maybe I missed something, I am a scala newbie :)
-Ryan
On Oct 8, 3:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Ok cool, I'll take a look at this tomrrow all being well.
Thanks for the feedback
Cheers, Tim
Sent from my iPhone
On 8 Oct 2009, at 20:43, Ryan Donahue donahu...@gmail.com wrote:
I created the ticket:http://github.com/dpp/liftweb/issues/#issue/88
I do receive the payment_status field for PDT. I bet in practice
you will never receive a payment_status value other than Completed,
because if the payment was not completed PayPal would not redirect
the user's browser back to your PDT URL. However, I have not
verified this and do check the payment status in my PDT code anyway
(how could I verify that it will never happen?). So I would prefer
that both were consistent, but just boxing the IPN payment status
will be fine too :)
On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett
timo...@getintheloop.eu
wrote:
Im not married to the current API, so breaking changes are OK as
there are only a handful of people using this code right now.
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it since
the beginning but just never got round to it and lack of general
demand.
Just about why they have a different signature... if memory serves
that would be because PaypalTransactionStatus is not supplied for
PDT. So whilst I see your point about them being consistent, im not
sure there is value in having a Box parameter that would always be
Empty? For IPN however, boxing sounds good to me.
Should just be a case of:
Box !! info.paymentStatus
Would you be happy with that? If you could raise a ticket for this
issue i'll patch it tomorrow and commit the code on a branch related
to that ticket. One the code goes through review then it will make
it into the master branch all being well.
Cheers, Tim
On 8 Oct 2009, at 18:52, Ryan Donahue wrote:
Yeah, I noticed my email got mangled.
It would make sense to me if PaypalIPN.actions and
PaypalPDT.pdtResponse were consistent.
trait PaypalPDT {
def pdtResponse: PartialFunction[(PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(PayPalInfo, Req), Unit]
}
If matching the status is just too convenient to lose, then how
about this.
trait PaypalPDT {
def pdtResponse: PartialFunction[(Box
[PaypalTransactionStatus.Value], PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Either would be an API breaking change for the paypal module, but
at least it'd be caught be the compiler. What do you think?
On Thu, Oct 8, 2009 at 1:33 PM, Timothy Perrett
timo...@getintheloop.eu
wrote:
The parameters were pretty mangled in your email... Which one would
you propose is more generic that the current status one we have?
Alternatively, it sounds to me like we might need to add some kind
of
special case match statement.
Thoughts?
Cheers, tim
On 8
[Lift] Re: PayPal Subscriptions
Here's a diff showing the changes I made. Notice I added a case to the
SimplePaypal.actions method that I'd think would fail compilation but does
not.
On Fri, Oct 9, 2009 at 1:08 PM, Ryan Donahue donahu...@gmail.com wrote:
Well, I am a scala newb, but I know maven all too well. I ran mvn clean
install from the lift-paypal dir to install lift-paypal-1.1-SNAPSHOT.jar to
my local repo.
To be sure, I changed the signature as follows which does cause errors:
def actions: PartialFunction[(PayPalInfo, Req), Unit]
Change back to def actions:
PartialFunction[(Box[PaypalTransactionStatus.value], PayPalInfo, Req), Unit]
and no errors.
On Fri, Oct 9, 2009 at 12:35 PM, Timothy Perrett
timo...@getintheloop.euwrote:
Hey Ryan,
How *exactly* did you locally do the build? If you had done the
install of your altered lift-paypal then you would certainly get a
compile error because the signature has changed. The new syntax should
be:
object MyIPN extends PaypalIPN {
def actions = {
case (Full(CompletedPayment), info, req) = // do something
}
}
The only exclusion would be if you had a implicit conversion to Box
PaypalTransactionStatus types that were unboxed.
Cheers, Tim
On Oct 9, 3:46 pm, Ryan Donahue donahu...@gmail.com wrote:
Tim,
I locally changed the PaypalIPN.actions method return type to
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Apparently this does not cause any compilation errors for user
implementing their own IPN handler as follows
object MyIPN extends PaypalIPN {
import PaypalTransactionStatus._
def actions = {
case (CompletedPayment, info, req) = // do something
}
}
This is not good since I assume the result is that the case won't
match anymore but we won't have a compilation error to tell us to
change our code. Maybe I missed something, I am a scala newbie :)
-Ryan
On Oct 8, 3:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Ok cool, I'll take a look at this tomrrow all being well.
Thanks for the feedback
Cheers, Tim
Sent from my iPhone
On 8 Oct 2009, at 20:43, Ryan Donahue donahu...@gmail.com wrote:
I created the ticket:http://github.com/dpp/liftweb/issues/#issue/88
I do receive the payment_status field for PDT. I bet in practice
you will never receive a payment_status value other than Completed,
because if the payment was not completed PayPal would not redirect
the user's browser back to your PDT URL. However, I have not
verified this and do check the payment status in my PDT code anyway
(how could I verify that it will never happen?). So I would prefer
that both were consistent, but just boxing the IPN payment status
will be fine too :)
On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett
timo...@getintheloop.eu
wrote:
Im not married to the current API, so breaking changes are OK as
there are only a handful of people using this code right now.
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it since
the beginning but just never got round to it and lack of general
demand.
Just about why they have a different signature... if memory serves
that would be because PaypalTransactionStatus is not supplied for
PDT. So whilst I see your point about them being consistent, im not
sure there is value in having a Box parameter that would always be
Empty? For IPN however, boxing sounds good to me.
Should just be a case of:
Box !! info.paymentStatus
Would you be happy with that? If you could raise a ticket for this
issue i'll patch it tomorrow and commit the code on a branch related
to that ticket. One the code goes through review then it will make
it into the master branch all being well.
Cheers, Tim
On 8 Oct 2009, at 18:52, Ryan Donahue wrote:
Yeah, I noticed my email got mangled.
It would make sense to me if PaypalIPN.actions and
PaypalPDT.pdtResponse were consistent.
trait PaypalPDT {
def pdtResponse: PartialFunction[(PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(PayPalInfo, Req), Unit]
}
If matching the status is just too convenient to lose, then how
about this.
trait PaypalPDT {
def pdtResponse: PartialFunction[(Box
[PaypalTransactionStatus.Value], PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Either would be an API breaking change for the paypal module, but
at least it'd be caught be the compiler. What do you think?
On Thu, Oct 8, 2009 at 1:33 PM, Timothy Perrett
timo...@getintheloop.eu
wrote:
The parameters were pretty mangled in your
[Lift] Re: Binding a snippet in a comet actor?
This is a defect. I've opened a ticket:
http://github.com/dpp/liftweb/issues#issue/93
I'll have a fix checked in later today
On Fri, Oct 9, 2009 at 1:02 AM, Somindra Bhattacharya
somind...@gmail.comwrote:
David,
Thanks for responding.
I have hosted the example at http://174.129.214.150:8080/
The code is at http://174.129.214.150:8080/dynamicForm.tar.gz
Here are the steps to reproduce the issue:
1. Open http://174.129.214.150:8080/ in a browser window. This starts
a comet actor which listens for messages. There is no form present on
this page.
2. Open http://174.129.214.150:8080/testdriver in another browser
window. Juxtapose these two windows.
3. Click on the Click here button in the window opened in (2).
Submitting this form results into a lift:Snippet block being sent to
the actor on the index page. This makes the index page show a form
that was not previously present.
4. Click on the button that has appeared on the index page. This does
not result into calling the handler at the server end.
Please let me know if you need more information.
Thanks again...
Regards,
Som
On Oct 8, 9:40 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
The chat example in demo.liftweb.net (source in examples/example) has a
form
that is presented after the initial form is rendered. It works just
fine.
Please put together a small example of the failure so I can see the
running
code.
On Wed, Oct 7, 2009 at 9:13 PM, Somindra Bhattacharya
somind...@gmail.comwrote:
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 somind...@gmail.com
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 naftoli...@gmail.com wrote:
What about an Ajax form?
On Tue, Oct 6, 2009 at 9:52 AM, Somindra Bhattacharya
somind...@gmail.com wrote:
Hi Everyone,
I have a comet actor that binds XHTML. The XHTML corresponds to a
snippet:
XHTML for comet actor -
lift:comet type=RCActor
Act:act /
/lift:comet
When the comet actor receives a certain message, the render
method of
the comet actor binds the following XHTML -
lift:Discuss.invite form=post
elem:submit /
/lift:Discuss.invite
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
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--
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: Using plain usernames for authentication
I suggest copying/pasting the MegaProtoUser stuff and then changing what you want. Sorry that this is less than perfectly OO. On Thu, Oct 1, 2009 at 8:27 PM, tommycli tommy...@ucla.edu wrote: Looking through the book and source for MegaProtoUser, it looks like the email address is used as the primary identifier for users in the built-in user system. What if you want to use plain usernames instead of emails? What do other people do - do they write their own user system from scratch? -- 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: Having trouble with form submission when using JavaScript to fetch the template
Can you put together a simple reproduceable case for this?
On Wed, Oct 7, 2009 at 9:12 AM, glenn gl...@exmbly.com 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) =
form
{item.toForm(Full(Save), { _.save })}
/form
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
--
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] Dynamic SiteMap
Hi, I'm something new to Scala and Lift is freshmeat for me. At the moment I am trying to find a best practice possibility to setSiteMap with a SiteMap which includes Menus and Locs which might change during application runtime. Let me say... each user should get his own, unique SiteMap after login. The SiteMap should be generated based on class construction and method calls during runtime. I've the problem to find a solution without putting setSiteMap-call nearly everywhere in my code just to update it. Uumh. Yes. Any tips are welcome... Best regards, Markus --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Question about the Getting Started Guide
I was getting the same problem last week. Now this week i am getting something similar that i am wondering if it is because of a proxy: 17:26:40 atkinso...@atkinsonos-laptop:~/personal/hg/lift-experiment2$ mvn jetty:run [INFO] Scanning for projects... Downloading: http://mvn.onemodel.org:8082/nexus/content/groups/dev/org/mortbay/jetty/maven-jetty-plugin/7.0.0.pre5/maven-jetty-plugin-7.0.0.pre5.jar [INFO] Unable to find resource 'org.mortbay.jetty:maven-jetty- plugin:maven-plugin:7.0.0.pre5' in repository scala-tools.org (http:// scala-tools.org/repo-releases) Downloading: http://mvn.onemodel.org:8082/nexus/content/groups/dev/org/mortbay/jetty/maven-jetty-plugin/7.0.0.pre5/maven-jetty-plugin-7.0.0.pre5.jar [INFO] Unable to find resource 'org.mortbay.jetty:maven-jetty- plugin:maven-plugin:7.0.0.pre5' in repository central (http:// repo1.maven.org/maven2) [INFO] Cannot find mojo descriptor for: 'jetty:run' - Treating as non- aggregator. [INFO] [INFO] Building lift-experiment2 [INFO]task-segment: [jetty:run] [INFO] Downloading: http://mvn.onemodel.org:8082/nexus/content/groups/dev/org/mortbay/jetty/maven-jetty-plugin/7.0.0.pre5/maven-jetty-plugin-7.0.0.pre5.jar [INFO] Unable to find resource 'org.mortbay.jetty:maven-jetty- plugin:maven-plugin:7.0.0.pre5' in repository scala-tools.org (http:// scala-tools.org/repo-releases) Downloading: http://mvn.onemodel.org:8082/nexus/content/groups/dev/org/mortbay/jetty/maven-jetty-plugin/7.0.0.pre5/maven-jetty-plugin-7.0.0.pre5.jar [INFO] Unable to find resource 'org.mortbay.jetty:maven-jetty- plugin:maven-plugin:7.0.0.pre5' in repository central (http:// repo1.maven.org/maven2) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.mortbay.jetty - DartifactId=maven-jetty-plugin -Dversion=7.0.0.pre5 -Dpackaging=maven- plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.mortbay.jetty - DartifactId=maven-jetty-plugin -Dversion=7.0.0.pre5 -Dpackaging=maven- plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0.pre5 from the specified remote repositories: fch (http://mvn.onemodel.org:8082/nexus/content/groups/dev) org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0.pre5 from the specified remote repositories: fch (http://mvn.onemodel.org:8082/nexus/content/groups/dev) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Fri Oct 09 17:33:49 MDT 2009 [INFO] Final Memory: 3M/17M [INFO] 17:33:49 atkinso...@atkinsonos-laptop:~/personal/hg/lift-experiment2$ On Sep 29, 11:49 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote: Jack, maven-jetty-plugin belongs to the group org.mortbay.jetty, not org.apache.maven.plugins. This makes me suspect that your jetty plugin isn't configured properly. A minimal jetty plugin configuration would look like this: plugin groupIdorg.mortbay.jetty/groupId artifactIdmaven-jetty-plugin/artifactId configuration contextPath//contextPath /configuration /plugin Could you please ensure this config under build - plugin section in your pom.xml and retry? Cheers, Indrajit On 30/09/09 10:09 AM, jlist9 wrote: I just tried it on another computer and got exactly the same error when running (below). I think something is broken. I checked the mvn output in the first run to create helloworld project and didn't see any mentioning of jetty... D:\Java\liftweb\workmvn jetty:run [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'jetty'. [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking for updates from central [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does not exist or no valid version c ould be found [INFO]
[Lift] Re: Started integrating lift in a scala+spring project. Feedback?
I'm sorry for the late question but have you looked at Scalaffinity? http://sourceforge.net/projects/scalaffinity/ It might give you an idea or two... On Oct 1, 8:14 pm, rintcius rintc...@gmail.com wrote: Hi, I have started integrating Lift in a Scala +Springexample project (seehttp://code.google.com/p/scala-spring). This first integration just has a single template and snippet for now but should give an idea how Lift can be integrated. Before I go further with this I would like some Lift experts to review the code I have written so far. Anybody? The changeset that adds lift integration is inhttp://code.google.com/p/scala-spring/source/detail?r=18 Thanks, Rintcius --~--~-~--~~~---~--~~ 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,
Looking at it, the strange thing is actually why it compiles now, not
why it doesn't compile with the change you suggested.
Given:
for (info - buildInfo(resp, r);
// stat is going to be a Box[PaypalTransactionStatus.Value] anyway
// because of L489.
stat - info.paymentStatus) yield {
actions((stat, info, r))
true
}
So, it appears that adding the Box[] to the partial function
definition would just make the type exactly right. Im starting to
write some mock tests etc as this is going to need testing
programatically.
More to come soon.
Cheers, Tim
On Oct 9, 7:03 pm, Ryan Donahue donahu...@gmail.com wrote:
Here's a diff showing the changes I made. Notice I added a case to the
SimplePaypal.actions method that I'd think would fail compilation but does
not.
On Fri, Oct 9, 2009 at 1:08 PM, Ryan Donahue donahu...@gmail.com wrote:
Well, I am a scala newb, but I know maven all too well. I ran mvn clean
install from the lift-paypal dir to install lift-paypal-1.1-SNAPSHOT.jar to
my local repo.
To be sure, I changed the signature as follows which does cause errors:
def actions: PartialFunction[(PayPalInfo, Req), Unit]
Change back to def actions:
PartialFunction[(Box[PaypalTransactionStatus.value], PayPalInfo, Req), Unit]
and no errors.
On Fri, Oct 9, 2009 at 12:35 PM, Timothy Perrett
timo...@getintheloop.euwrote:
Hey Ryan,
How *exactly* did you locally do the build? If you had done the
install of your altered lift-paypal then you would certainly get a
compile error because the signature has changed. The new syntax should
be:
object MyIPN extends PaypalIPN {
def actions = {
case (Full(CompletedPayment), info, req) = // do something
}
}
The only exclusion would be if you had a implicit conversion to Box
PaypalTransactionStatus types that were unboxed.
Cheers, Tim
On Oct 9, 3:46 pm, Ryan Donahue donahu...@gmail.com wrote:
Tim,
I locally changed the PaypalIPN.actions method return type to
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Apparently this does not cause any compilation errors for user
implementing their own IPN handler as follows
object MyIPN extends PaypalIPN {
import PaypalTransactionStatus._
def actions = {
case (CompletedPayment, info, req) = // do something
}
}
This is not good since I assume the result is that the case won't
match anymore but we won't have a compilation error to tell us to
change our code. Maybe I missed something, I am a scala newbie :)
-Ryan
On Oct 8, 3:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Ok cool, I'll take a look at this tomrrow all being well.
Thanks for the feedback
Cheers, Tim
Sent from my iPhone
On 8 Oct 2009, at 20:43, Ryan Donahue donahu...@gmail.com wrote:
I created the ticket:http://github.com/dpp/liftweb/issues/#issue/88
I do receive the payment_status field for PDT. I bet in practice
you will never receive a payment_status value other than Completed,
because if the payment was not completed PayPal would not redirect
the user's browser back to your PDT URL. However, I have not
verified this and do check the payment status in my PDT code anyway
(how could I verify that it will never happen?). So I would prefer
that both were consistent, but just boxing the IPN payment status
will be fine too :)
On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett
timo...@getintheloop.eu
wrote:
Im not married to the current API, so breaking changes are OK as
there are only a handful of people using this code right now.
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it since
the beginning but just never got round to it and lack of general
demand.
Just about why they have a different signature... if memory serves
that would be because PaypalTransactionStatus is not supplied for
PDT. So whilst I see your point about them being consistent, im not
sure there is value in having a Box parameter that would always be
Empty? For IPN however, boxing sounds good to me.
Should just be a case of:
Box !! info.paymentStatus
Would you be happy with that? If you could raise a ticket for this
issue i'll patch it tomorrow and commit the code on a branch related
to that ticket. One the code goes through review then it will make
it into the master branch all being well.
Cheers, Tim
On 8 Oct 2009, at 18:52, Ryan Donahue wrote:
Yeah, I noticed my email got mangled.
It would make sense to me if PaypalIPN.actions and
PaypalPDT.pdtResponse were consistent.
trait PaypalPDT {
def pdtResponse: PartialFunction[(PayPalInfo, Req), LiftResponse]
}
trait PaypalIPN {
def
[Lift] Re: PayPal Subscriptions
Ryan,
Ignore my last email please - i've just tested the change using the
IPN simulator and it now handles the Cancel message properly by
passing Empty.
The change is on my branch here:
http://github.com/dpp/liftweb/commit/451dd3cb97e562a063da5cfe046badf1f9d8ad4c
Cheers, Tim
On Oct 10, 1:05 am, Timothy Perrett timo...@getintheloop.eu wrote:
Ryan,
Looking at it, the strange thing is actually why it compiles now, not
why it doesn't compile with the change you suggested.
Given:
for (info - buildInfo(resp, r);
// stat is going to be a Box[PaypalTransactionStatus.Value] anyway
// because of L489.
stat - info.paymentStatus) yield {
actions((stat, info, r))
true
}
So, it appears that adding the Box[] to the partial function
definition would just make the type exactly right. Im starting to
write some mock tests etc as this is going to need testing
programatically.
More to come soon.
Cheers, Tim
On Oct 9, 7:03 pm, Ryan Donahue donahu...@gmail.com wrote:
Here's a diff showing the changes I made. Notice I added a case to the
SimplePaypal.actions method that I'd think would fail compilation but does
not.
On Fri, Oct 9, 2009 at 1:08 PM, Ryan Donahue donahu...@gmail.com wrote:
Well, I am a scala newb, but I know maven all too well. I ran mvn clean
install from the lift-paypal dir to install lift-paypal-1.1-SNAPSHOT.jar
to
my local repo.
To be sure, I changed the signature as follows which does cause errors:
def actions: PartialFunction[(PayPalInfo, Req), Unit]
Change back to def actions:
PartialFunction[(Box[PaypalTransactionStatus.value], PayPalInfo, Req),
Unit]
and no errors.
On Fri, Oct 9, 2009 at 12:35 PM, Timothy Perrett
timo...@getintheloop.euwrote:
Hey Ryan,
How *exactly* did you locally do the build? If you had done the
install of your altered lift-paypal then you would certainly get a
compile error because the signature has changed. The new syntax should
be:
object MyIPN extends PaypalIPN {
def actions = {
case (Full(CompletedPayment), info, req) = // do something
}
}
The only exclusion would be if you had a implicit conversion to Box
PaypalTransactionStatus types that were unboxed.
Cheers, Tim
On Oct 9, 3:46 pm, Ryan Donahue donahu...@gmail.com wrote:
Tim,
I locally changed the PaypalIPN.actions method return type to
trait PaypalIPN {
def actions: PartialFunction[(Box[PaypalTransactionStatus.Value],
PayPalInfo, Req), Unit]
}
Apparently this does not cause any compilation errors for user
implementing their own IPN handler as follows
object MyIPN extends PaypalIPN {
import PaypalTransactionStatus._
def actions = {
case (CompletedPayment, info, req) = // do something
}
}
This is not good since I assume the result is that the case won't
match anymore but we won't have a compilation error to tell us to
change our code. Maybe I missed something, I am a scala newbie :)
-Ryan
On Oct 8, 3:57 pm, Timothy Perrett timo...@getintheloop.eu wrote:
Ok cool, I'll take a look at this tomrrow all being well.
Thanks for the feedback
Cheers, Tim
Sent from my iPhone
On 8 Oct 2009, at 20:43, Ryan Donahue donahu...@gmail.com wrote:
I created the ticket:http://github.com/dpp/liftweb/issues/#issue/88
I do receive the payment_status field for PDT. I bet in practice
you will never receive a payment_status value other than Completed,
because if the payment was not completed PayPal would not redirect
the user's browser back to your PDT URL. However, I have not
verified this and do check the payment status in my PDT code anyway
(how could I verify that it will never happen?). So I would prefer
that both were consistent, but just boxing the IPN payment status
will be fine too :)
On Thu, Oct 8, 2009 at 2:49 PM, Timothy Perrett
timo...@getintheloop.eu
wrote:
Im not married to the current API, so breaking changes are OK as
there are only a handful of people using this code right now.
To be honest, this whole situation just underlines the need for
mocking in this module of lift... i've been meaning to do it since
the beginning but just never got round to it and lack of general
demand.
Just about why they have a different signature... if memory serves
that would be because PaypalTransactionStatus is not supplied for
PDT. So whilst I see your point about them being consistent, im not
sure there is value in having a Box parameter that would always be
Empty? For IPN however, boxing sounds good to me.
Should just be a case of:
Box !! info.paymentStatus
Would you be happy with that? If you could raise a ticket for this
issue i'll patch it tomorrow and commit the code on a branch
related
to
[Lift] Re: Binding a snippet in a comet actor?
Thanks David!
On Oct 10, 12:17 am, David Pollak feeder.of.the.be...@gmail.com
wrote:
This is a defect. I've opened a
ticket:http://github.com/dpp/liftweb/issues#issue/93
I'll have a fix checked in later today
On Fri, Oct 9, 2009 at 1:02 AM, Somindra Bhattacharya
somind...@gmail.comwrote:
David,
Thanks for responding.
I have hosted the example athttp://174.129.214.150:8080/
The code is athttp://174.129.214.150:8080/dynamicForm.tar.gz
Here are the steps to reproduce the issue:
1. Openhttp://174.129.214.150:8080/in a browser window. This starts
a comet actor which listens for messages. There is no form present on
this page.
2. Openhttp://174.129.214.150:8080/testdriverin another browser
window. Juxtapose these two windows.
3. Click on the Click here button in the window opened in (2).
Submitting this form results into a lift:Snippet block being sent to
the actor on the index page. This makes the index page show a form
that was not previously present.
4. Click on the button that has appeared on the index page. This does
not result into calling the handler at the server end.
Please let me know if you need more information.
Thanks again...
Regards,
Som
On Oct 8, 9:40 pm, David Pollak feeder.of.the.be...@gmail.com wrote:
The chat example in demo.liftweb.net (source in examples/example) has a
form
that is presented after the initial form is rendered. It works just
fine.
Please put together a small example of the failure so I can see the
running
code.
On Wed, Oct 7, 2009 at 9:13 PM, Somindra Bhattacharya
somind...@gmail.comwrote:
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 somind...@gmail.com
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 naftoli...@gmail.com wrote:
What about an Ajax form?
On Tue, Oct 6, 2009 at 9:52 AM, Somindra Bhattacharya
somind...@gmail.com wrote:
Hi Everyone,
I have a comet actor that binds XHTML. The XHTML corresponds to a
snippet:
XHTML for comet actor -
lift:comet type=RCActor
Act:act /
/lift:comet
When the comet actor receives a certain message, the render
method of
the comet actor binds the following XHTML -
lift:Discuss.invite form=post
elem:submit /
/lift:Discuss.invite
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
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://www.apress.com/book/view/1430219890
Follow me:http://twitter.com/dpp
Surf the harmonics
--
Lift, the simply functional web frameworkhttp://liftweb.net
Beginning Scalahttp://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
