Xavi Ramirez | 1 Jun 01:59 2009
Picon

[Lift] Re: JavaScript interface to Comet

Thanks for pointing me into the right direction.  I've created a
simple example (see attachment).  In my example, the user can drag a
div around the screen.  Every time the div moves, the browser sends a
json object with the x and y coordinates to the comet steam.
Unfortunately I've ran into a couple of usability and performance
problems.

Assume the following set up: two browses are open (browser A and B)
are all listening to comet stream K.  Comet stream K broadcasts
commands that update the position of a div.

It seems that whenever browser A notifies comet stream K about an
update to the div's position, stream K broadcasts the message to all
its listeners, including browser A.  In other words, browser A
essentially hears its own echo.  For the user of browser A, this
causes the div to constantly jump between where the user actually
dragged it and the position that comet stream K is currently
broadcasting.

Also there does not seem to be any throttling mechanism for
client-side comet calls.  In my attached example, even a very simple
drag action creates dozens of ajax calls at once.  Firefox does not
handle this well.

I'd greatly appreciate any tips or suggestions.

Thanks,
Xavi

P.S. Random question: Is there a CometActor instance for every browser
(Continue reading)

David Pollak | 1 Jun 06:02 2009
Picon

[Lift] Re: lift views

Folks,

There's nothing that Lift does magically with <lift:surround/> or <lift:embed/>  They just replace XML nodes.

If you want to structure your apps to not have surround or embed, that's fine.  If you want to surround or embed at different points in your files, totally cool.  Do it however you want.  It makes no difference to Lift.  Lift's templating is just an XML substitution system.  Substitute or don't at your pleasure.  Do what works best for you.  It makes no difference to Lift.

Thanks,

David

On Sun, May 31, 2009 at 11:31 AM, Yoryos <valotas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

No! I didn't missed that part. Like Xavi said the benefit is a valid
html page. It would be much more intresting having something like

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:lift="http://
liftweb.net/">
<head><!-- I don't not if it's valid to just not even have a head tag
when we don't want to --></head>
<body lift:layout="default" lift:name="content">
 <h2>Welcome to your project!</h2>
 <p><lift:helloWorld.howdy /></p>
</body>
</html>

witch has less boilerplate (than my first example) and is very easy
IMHO to understand and read.

I'm very new to lift and I just think that telling something that
would look easier to me, would also look easier to any newby. At the
other hand, being newby also means that I don't have a good overview
of the framework and it's design. It is better thought to say
something event if it is wrong before you get used to it, because then
you'll just get used to it!!

Yoryos

On May 31, 1:53 am, "Charles F. Munat" <c...-QXwrqIsfxigAvxtiuMwx3w@public.gmane.org> wrote:
> Yoryos,
>
> You probably missed the part where you can add a head element inside the
> surround tags and it will replace the default element:
>
> <lift:surround with="default2" at="content">
>    <head>
>      <title>A better title than the one in default.html</title>
>    </head>
>    <h2>Welcome to your project!</h2>
>    <p><lift:helloWorld.howdy /></p>
> </lift:surround>
>
> I don't see that duplicating the html and body tags unnecessarily makes
> it any better. Just adds clutter, IMO. The fewer tags I have to deal
> with, the easier it is to read.
>
> Chas.
>
> valotas wrote:
> > Hi all!
> > Just a proposal: wouldn't be better to have the views look like more
> > an html page. I mean for the basic project created, instead of having
> > an index.html look like
>
> > <lift:surround with="default2" at="content">
> >   <h2>Welcome to your project!</h2>
> >   <p><lift:helloWorld.howdy /></p>
> > </lift:surround>
>
> > have something like:
>
> > <html>
> > <lift:surround with="default2" at="content">
> > <head>
> >   <title>A better title than the one in default.html</title>
> > </head>
> > <body>
> >   <h2>Welcome to your project!</h2>
> >   <p><lift:helloWorld.howdy /></p>
> > </body>
> > </lift:surround>
> > </html>
>
> > Yes we have more boilerplate code but with that way it would be much
> > more easier the edditing of the page.
>
> > Yoryos





--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb <at> googlegroups.com
To unsubscribe from this group, send email to liftweb+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

David Pollak | 1 Jun 06:10 2009
Picon

[Lift] Re: Showing a Box or Redirecting?

class SomeSnippet {
  implicit def boxOpener(in: Box[NodeSeq]): NodeSeq = in openOr {S.error("Inactive"); S.redirectTo(S.referer openOr "/")}

  def showA(xhtml: NodeSeq): NodeSeq =
   for {
     id <- S.param("id")
     info <- session1.get(id)
   } yield bind("foo", xhtml, "thing" -> info.x)
}

The implicit makes the Box[NodeSeq] turn into a NodeSeq or redirects the user.

Thanks,

David

On Sat, May 30, 2009 at 6:12 PM, Bryan <germish-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

If Foo has 5 methods that I need to show in a Snippet (scattered
throughout the template), what's a good way to S.error("inactive");
S.redirectTo("/") whenever Box[Foo] cannot be opened because it is not
Full, without having to write a bunch of boiler plate code for each of
the show methods I have defined below.

class SomeSnippet {
 val foo: Box[Foo] = tryo(session1.get(S.param("id").getOrElse("")))

 def showA(xhtml: NodeSeq): NodeSeq = ...
 def showB(xhtml: NodeSeq): NodeSeq = ...
 def showC(xhtml: NodeSeq): NodeSeq = ...
 def showD(xhtml: NodeSeq): NodeSeq = ...
 def showE(xhtml: NodeSeq): NodeSeq = ...
}

Thanks,
Bryan




--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb <at> googlegroups.com
To unsubscribe from this group, send email to liftweb+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Viktor Klang | 1 Jun 09:25 2009
Picon

[Lift] Re: lift views



On Sun, May 31, 2009 at 7:05 PM, Timothy Perrett <timothy-0nUveC4DNz0XzJSMcliFkw@public.gmane.org> wrote:


Now you mention it though, it might well work quite nicely. Talk to me
Viktor - what are you thinking?

Just create an XSLT template to convert the lift templates to a a more "readable" form?

Should be possible?
 


Cheers, Tim

On 31/05/2009 14:10, "Viktor Klang" <viktor.klang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Couldn't they just define an XSLT template to view the lift templates with?







--
Viktor Klang
Rockstar Developer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb <at> googlegroups.com
To unsubscribe from this group, send email to liftweb+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

marius d. | 1 Jun 09:42 2009
Picon

[Lift] Re: JavaScript interface to Comet


On Jun 1, 2:59 am, Xavi Ramirez <xavi....@...> wrote:
> Thanks for pointing me into the right direction.  I've created a
> simple example (see attachment).  In my example, the user can drag a
> div around the screen.  Every time the div moves, the browser sends a
> json object with the x and y coordinates to the comet steam.
> Unfortunately I've ran into a couple of usability and performance
> problems.
>
> Assume the following set up: two browses are open (browser A and B)
> are all listening to comet stream K.  Comet stream K broadcasts
> commands that update the position of a div.
>
> It seems that whenever browser A notifies comet stream K about an
> update to the div's position, stream K broadcasts the message to all
> its listeners, including browser A.  In other words, browser A
> essentially hears its own echo.  For the user of browser A, this
> causes the div to constantly jump between where the user actually
> dragged it and the position that comet stream K is currently
> broadcasting.

This is something your app must handle. Your ShapeTracker actor is
notified by all CometActor with AddListener hence your ShapeActor is
sending messages to all running actors. Your app needs to discriminate
the actors such that to not send the Comet response back if the
notification request pertains to the same session.

BTW Lift has ListenerManager trait such as:

class ShapeDisplay extends CometActor with CometListenee {

   override def registerWith = ShapeTracker
  ...
}

object ShapeTracked extends Actor with ListenerManager {
  var msg: MoveShape = _

  override def createUpdate = msg

  override lowPriority = {

  }
}

>
> Also there does not seem to be any throttling mechanism for
> client-side comet calls.  In my attached example, even a very simple
> drag action creates dozens of ajax calls at once.  Firefox does not
> handle this well.

This is an on purpose Lift mechanism that avoids Ajax connections
starvation. For instance I assume that you opened 2 firefox instances
and tried it out. Well there is not difference between opening a new
browser tab or a new browser window and Ajax parallel connections are
shared among all instances. If you open one FF instance and oen IE
instance you will not see this behavior anymore.

>
> I'd greatly appreciate any tips or suggestions.
>
> Thanks,
> Xavi
>
> P.S. Random question: Is there a CometActor instance for every browser
> viewing a comet stream?
>
> P.P.S.S.  I feel there's some utility in a JsCometActor.  If you all
> are amenable, I'd love to write up a proposal and maybe even lend a
> hand with implementing it.
>
> On Sun, May 31, 2009 at 4:07 AM, marius d. <marius.dan...@...> wrote:
>
> > Yes looks like this is exactly what you would need. Please see
> > partialUpdate from CometActor. As an example you can see sites/example/
> > src/main/scala/net/liftweb/example/comet/Clock.scala. partialUPdate
> > function returns a JsCmd but there are of course implicit conversions
> > between JsExp and JsCmd.
>
> > What you're trying to do seems like an interesting thing for a Lift
> > demo app in the sense that it would provide an interesting visual
> > effect through CometActor.
>
> > Br's,
> > Marius
>
> > On May 31, 4:46 am, Xavi Ramirez <xavi....@...> wrote:
> >> I'm trying add some comet features to an existing JS app. Essentially,
> >> I want to drag/drop a widget and have my movements reflected on other
> >> user's browsers.
>
> >> You mentioned that a CometActor can cause JsExp to be executed.  This
> >> might be what I'm looking for.  How does that work?
>
> >> Thanks,
> >> Xavi
>
> >> On Sat, May 30, 2009 at 5:02 PM, marius d.
<marius.dan...@...> wrote:
>
> >> > Lift generates the JavaScript for Comet so you essentially don't have
> >> > to worry about it. From a CometActor you just provide the markup that
> >> > you need to render asynchronously or just the JsExp to be executed by
> >> > browser.
>
> >> > However could you please provide an overview of what you're trying to
> >> > achieve?
>
> >> > P.S.
> >> > By default Lift's Ajax/Comet support works against JavaScript content
> >> > type responses and not JSON. However you can use JSON as well.
>
> >> > Br's,
> >> > Marius
>
> >> > On May 30, 3:12 pm, Xavi Ramirez <xavi....@...> wrote:
> >> >> Hello,
>
> >> >> I was wondering if Lift provides a javascript interface to comet?
> >> >> Ideally it would look something like this:
>
> >> >> lift.getComet("comet-name").addListener(callback); // callback takes a
> >> >> json object
> >> >> lift.getComet("comet-name").postMessage(jsonObj);
>
> >> >> Thanks,
> >> >> Xavi
>
>
>
>  cometmove.zip
> 64KViewDownload
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

marius d. | 1 Jun 09:53 2009
Picon

[Lift] Re: JavaScript interface to Comet


Sorry hit send too soon ... continuation below

On Jun 1, 10:42 am, "marius d." <marius.dan...@...> wrote:
> On Jun 1, 2:59 am, Xavi Ramirez <xavi....@...> wrote:
>
>
>
> > Thanks for pointing me into the right direction.  I've created a
> > simple example (see attachment).  In my example, the user can drag a
> > div around the screen.  Every time the div moves, the browser sends a
> > json object with the x and y coordinates to the comet steam.
> > Unfortunately I've ran into a couple of usability and performance
> > problems.
>
> > Assume the following set up: two browses are open (browser A and B)
> > are all listening to comet stream K.  Comet stream K broadcasts
> > commands that update the position of a div.
>
> > It seems that whenever browser A notifies comet stream K about an
> > update to the div's position, stream K broadcasts the message to all
> > its listeners, including browser A.  In other words, browser A
> > essentially hears its own echo.  For the user of browser A, this
> > causes the div to constantly jump between where the user actually
> > dragged it and the position that comet stream K is currently
> > broadcasting.
>
> This is something your app must handle. Your ShapeTracker actor is
> notified by all CometActor with AddListener hence your ShapeActor is
> sending messages to all running actors. Your app needs to discriminate
> the actors such that to not send the Comet response back if the
> notification request pertains to the same session.
>
> BTW Lift has ListenerManager trait such as:

 class ShapeDisplay extends CometActor with CometListenee {

   override def registerWith = ShapeTracker
   ...

 }

 object ShapeTracked extends Actor with ListenerManager {
   var msg: MoveShape = _

   override def createUpdate = msg

   override lowPriority = {
    case m  <at>  MoveShape(x, y) => msg = chat; updateListeners
 }

    ...

 }

This is just a mechanism for your actor to interract with CometActors
but you still need to determine to which actor you don't want to send
the message. You could probably use a SessionVar to set some value
before notifying the CometActors and in CometActor you could probably
check if this SessionVar has the right value. If it does it would mean
that the CometActor pertains to the same session and you wont send
down any message back to the client. You would nee to unset this value
once you determined that. There are probably better ways to do it ...
but I'm thinking now that maybe we should do something inside
ListenerManager to allow the users to send messages only to
CometActors pertaining to other sessions only.

I'll look more into this and see if/how we can provide something out
of the box.

>
> > Also there does not seem to be any throttling mechanism for
> > client-side comet calls.  In my attached example, even a very simple
> > drag action creates dozens of ajax calls at once.  Firefox does not
> > handle this well.
>
> This is an on purpose Lift mechanism that avoids Ajax connections
> starvation. For instance I assume that you opened 2 firefox instances
> and tried it out. Well there is not difference between opening a new
> browser tab or a new browser window and Ajax parallel connections are
> shared among all instances. If you open one FF instance and oen IE
> instance you will not see this behavior anymore.
>
>
>
> > I'd greatly appreciate any tips or suggestions.
>
> > Thanks,
> > Xavi
>
> > P.S. Random question: Is there a CometActor instance for every browser
> > viewing a comet stream?
>
> > P.P.S.S.  I feel there's some utility in a JsCometActor.  If you all
> > are amenable, I'd love to write up a proposal and maybe even lend a
> > hand with implementing it.
>
> > On Sun, May 31, 2009 at 4:07 AM, marius d. <marius.dan...@...> wrote:
>
> > > Yes looks like this is exactly what you would need. Please see
> > > partialUpdate from CometActor. As an example you can see sites/example/
> > > src/main/scala/net/liftweb/example/comet/Clock.scala. partialUPdate
> > > function returns a JsCmd but there are of course implicit conversions
> > > between JsExp and JsCmd.
>
> > > What you're trying to do seems like an interesting thing for a Lift
> > > demo app in the sense that it would provide an interesting visual
> > > effect through CometActor.
>
> > > Br's,
> > > Marius
>
> > > On May 31, 4:46 am, Xavi Ramirez <xavi....@...> wrote:
> > >> I'm trying add some comet features to an existing JS app. Essentially,
> > >> I want to drag/drop a widget and have my movements reflected on other
> > >> user's browsers.
>
> > >> You mentioned that a CometActor can cause JsExp to be executed.  This
> > >> might be what I'm looking for.  How does that work?
>
> > >> Thanks,
> > >> Xavi
>
> > >> On Sat, May 30, 2009 at 5:02 PM, marius d.
<marius.dan...@...> wrote:
>
> > >> > Lift generates the JavaScript for Comet so you essentially don't have
> > >> > to worry about it. From a CometActor you just provide the markup that
> > >> > you need to render asynchronously or just the JsExp to be executed by
> > >> > browser.
>
> > >> > However could you please provide an overview of what you're trying to
> > >> > achieve?
>
> > >> > P.S.
> > >> > By default Lift's Ajax/Comet support works against JavaScript content
> > >> > type responses and not JSON. However you can use JSON as well.
>
> > >> > Br's,
> > >> > Marius
>
> > >> > On May 30, 3:12 pm, Xavi Ramirez <xavi....@...> wrote:
> > >> >> Hello,
>
> > >> >> I was wondering if Lift provides a javascript interface to comet?
> > >> >> Ideally it would look something like this:
>
> > >> >> lift.getComet("comet-name").addListener(callback); // callback takes a
> > >> >> json object
> > >> >> lift.getComet("comet-name").postMessage(jsonObj);
>
> > >> >> Thanks,
> > >> >> Xavi
>
> >  cometmove.zip
> > 64KViewDownload
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Timothy Perrett | 1 Jun 11:05 2009
Picon

[Lift] Re: lift views


> Just create an XSLT template to convert the lift templates to a a more
> "readable" form?
>
> Should be possible?

Your thinking just have an XSLT just for preview purposes? That would
be pretty sweet.

Perhaps we can do something with this:

http://mojo.codehaus.org/xslt-maven-plugin/transform-mojo.html

Cheers, Tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Marius Danciu | 1 Jun 11:16 2009
Picon

[Lift] JavaScript interface to Comet

Xavi,

I took the liebrty of doing some little changes to your code so that you won't get the echo. It is just an example (no elaborated design). It works for me, but let me know if this is suitable for you.


Oh BTW, I've noticed that IE complains about some JS code.

Br's,
Marius

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb <at> googlegroups.com
To unsubscribe from this group, send email to liftweb+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Attachment (cometmove.zip): application/zip, 67 KiB
Viktor Klang | 1 Jun 11:52 2009
Picon

[Lift] Re: lift views



On Mon, Jun 1, 2009 at 11:05 AM, Timothy Perrett <timothy-0nUveC4DNz0XzJSMcliFkw@public.gmane.org> wrote:


> Just create an XSLT template to convert the lift templates to a a more
> "readable" form?
>
> Should be possible?

Your thinking just have an XSLT just for preview purposes? That would
be pretty sweet.

Yes, my point exactly! :)
 


Perhaps we can do something with this:

http://mojo.codehaus.org/xslt-maven-plugin/transform-mojo.html

Cheers, Tim




--
Viktor Klang
Rockstar Developer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb <at> googlegroups.com
To unsubscribe from this group, send email to liftweb+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Timothy Perrett | 1 Jun 12:15 2009
Picon

[Lift] Re: lift views

Don't worry I'm just being slow as per normal viktor! 

Do you want to try setting this up or shall I?

Cheers, Tim

Sent from my iPhone

On 1 Jun 2009, at 10:52, Viktor Klang <viktor.klang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:



On Mon, Jun 1, 2009 at 11:05 AM, Timothy Perrett <timothy-0nUveC4DNz0XzJSMcliFkw@public.gmane.org> wrote:


> Just create an XSLT template to convert the lift templates to a a more
> "readable" form?
>
> Should be possible?

Your thinking just have an XSLT just for preview purposes? That would
be pretty sweet.

Yes, my point exactly! :)
 


Perhaps we can do something with this:

http://mojo.codehaus.org/xslt-maven-plugin/transform-mojo.html

Cheers, Tim




--
Viktor Klang
Rockstar Developer



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb <at> googlegroups.com
To unsubscribe from this group, send email to liftweb+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---


Gmane