[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 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 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
> wrote:
>
>
>
>
>
> > 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
>
> --
> 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 ... etc so, install, and jetty:run are goals in maven terminology. Cheers, Tim On Oct 9, 5:13 am, jon 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 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 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 0 to the > > > "org.mortbay.jetty" > > > > 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 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 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 mo
[Lift] Re: YUI Compressor plugin for SBT
Looks pretty sweet Jon, kudos. Cheers, Tim On Oct 9, 2:21 am, jon wrote: > Hi all, > > I've created a plugin hosted here:http://github.com/hoffrocket/sbt-yui > > Thank you to David Bernard for paving the way with his maven version > and to Mark Harrah for creating sbt and providing guidance. > > I'm working on getting this up on the scala-tools repo, but until then > you can build from source. > > Thanks, > > Jon --~--~-~--~~~---~--~~ 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: LongKeyedMapper object where I can set the id
Hi Harry,
I think you also need to set override def dbAutogenerated_? = false
I've used dbAutogenerated_? and writePermission_? with
MappedStringIndex but I also had to redefine dirty_?, which hopefully
you won't have to do. If you do a search through this group you can
find my thread on it. However, my solution isn't complete, as Mapper
always tries to INSERT a row instead of UPDATE, the exact inverse of
your problem!
Peter
On Oct 8, 11:28 pm, harryh wrote:
> LongKeyedMapper object where I can set the id.
>
> I want a database object where I set the primary key myself (rather
> than having it be sequentially by the database). I thought I could do
> this:
>
> class Tombstone extends LongKeyedMapper[Tombstone] {
> def getSingleton = Tombstone
>
> def primaryKeyField = id
> object id extends MappedLongIndex(this) {
> override def writePermission_? = true
> }
>
> }
>
> object Tombstone extends Tombstone with LongKeyedMetaMapper[Tombstone]
> {
> override def dbTableName = "tombstones"
>
> }
>
> But when I do Tombstone.create.id(12).save it does an UPDATE instead
> of an INSERT. Is there any good way to do what I want here?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Missing i18n in Lift?
On Thu, Oct 8, 2009 at 6:26 PM, Heiko Seeberger 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 > > 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 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 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 > > wrote: > > > > On Sat, Aug 29, 2009 at 11:14 AM, Josh Suereth > > > wrote: > > > > > 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 > > > > 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: LongKeyedMapper object where I can set the id
On Fri, Oct 9, 2009 at 1:17 AM, Peter Robinett wrote:
>
> Hi Harry,
>
> I think you also need to set override def dbAutogenerated_? = false
>
> I've used dbAutogenerated_? and writePermission_? with
> MappedStringIndex but I also had to redefine dirty_?, which hopefully
> you won't have to do. If you do a search through this group you can
> find my thread on it. However, my solution isn't complete, as Mapper
> always tries to INSERT a row instead of UPDATE, the exact inverse of
> your problem!
>
>
See ticket #90 http://github.com/dpp/liftweb/issues#issue/90 There's a
patch on dpp_wip_issue_90
> Peter
>
> On Oct 8, 11:28 pm, harryh wrote:
> > LongKeyedMapper object where I can set the id.
> >
> > I want a database object where I set the primary key myself (rather
> > than having it be sequentially by the database). I thought I could do
> > this:
> >
> > class Tombstone extends LongKeyedMapper[Tombstone] {
> > def getSingleton = Tombstone
> >
> > def primaryKeyField = id
> > object id extends MappedLongIndex(this) {
> > override def writePermission_? = true
> > }
> >
> > }
> >
> > object Tombstone extends Tombstone with LongKeyedMetaMapper[Tombstone]
> > {
> > override def dbTableName = "tombstones"
> >
> > }
> >
> > But when I do Tombstone.create.id(12).save it does an UPDATE instead
> > of an INSERT. Is there any good way to do what I want here?
> >
>
--
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: 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 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 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 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 > > 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 >> > 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),
> >
[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 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 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 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 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 > > > 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 > >> > 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 subsc
[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 wrote:
>
> 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 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 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 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
> > > > > 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
> > > >> > wrote:
> >
> > > >> The parameters were pretty mangled in
[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 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
> wrote:
>
>>
>> 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 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 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 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
>> > > > > > 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: Parti
[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
wrote:
>
> 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 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 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
> > wrote:
> >
> >
> >
> >
> >
> > > 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
> >
> > --
> > 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
[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 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 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
>
> >
>
--
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 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: > > > org.mortbay.jetty > maven-jetty-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\work>mvn jetty:run > > [INFO] Scanning for projects... > > [INFO] Searching repository for plugin with prefix: 'jetty'. > > [INFO] artifact org.apache.maven.plugins:maven-jetty-plugin: checking > > for updates from central > > [INFO] > > > > [ERROR] BUILD ERROR > > [INFO] > > > > [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does > > not exist or no valid version c > > ould be found > > [INFO] > > > > [INFO] For more information, run Maven with
[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 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 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 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
> > wrote:
>
> >> 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 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 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 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
> >> >> > > > > 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 emai
[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 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 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 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
> > > wrote:
>
> > >> 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 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 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 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
> > >> > >> > > > > 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
[Lift] Re: Binding a snippet in a comet actor?
Thanks David!
On Oct 10, 12:17 am, David Pollak
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
> wrote:
>
>
>
>
>
> > 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 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 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
> > > wrote:
>
> > > > 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
>
> > > --
> > > 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 Go
