You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Martin Kersten <ma...@gmail.com> on 2013/08/16 07:09:02 UTC
Best way to communicate with JS using Tapestry as BackEnd
Hi there,
back in the old days I used to use GWT alot in conjunction with
Tapestry. Nowadays it would be fine to develop using JS at the Client side
and I want to use Tapestry at the backend.
I would love to use something like socket.IO directly within the
JS-client-code so I investigated the Atmosphere (github) package. Saidly
there is no direct implementation nor support for the Tapestry world. And
it looks like I would loose a whole weekend trying without a guarantee that
I come up with something good.
Currently implementing Atmosphere I would go for a
HttpServletRequestHandler, warp the Tapestry servlet or even alter it
directly (so I can use the default Atmosphere servlet based on the accessed
page and so on. The way I used to implement GWT by creating a Page writing
http directly using a MarkupWriter seams not to be that feasable since
Atmosphere has a bunch of things to do, I dont understand right now.
So I would love to know what is the current preferred way to use something
like the socket.io lib in conjunction with Tapestry as the serving backend?
Thanks for reading,
Martin (Kersten),
Germany
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Dmitry Gusev <dm...@gmail.com>.
Yes, but you mentioned it here first ;)
On Fri, Aug 16, 2013 at 3:37 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Fri, 16 Aug 2013 07:55:54 -0300, Dmitry Gusev <dm...@gmail.com>
> wrote:
>
> +1 for Thiago's approach -- it is also widely used, especially if you
>> want to render markup or update some zones in response.
>>
>
> It's not my approach, it's the one used by Tapestry itself in its
> AJAX-powered components. :)
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 16 Aug 2013 07:55:54 -0300, Dmitry Gusev <dm...@gmail.com>
wrote:
> +1 for Thiago's approach -- it is also widely used, especially if you
> want to render markup or update some zones in response.
It's not my approach, it's the one used by Tapestry itself in its
AJAX-powered components. :)
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Martin Kersten <ma...@gmail.com>.
I am restricted to Java at the backend. I might have evaluated something
like node.js+redis for the socket.io. That would be good. And before
switching to node.js I would also evaluate the PlayFramework since they
have session.io support out of the box and also allow me to stick to the
Java way. But I am restricted to Tapestry 5 (existing project) and Java
only. Also the database is MySql (MariaDB).
2013/8/16 Alejandro Scandroli <al...@gmail.com>
> Hi Martin
>
> Are you restricted to a Java application server? can you use things
> like NodeJS or Redis?
> A couple of years ago, I used Tapestry+NodeJS+Redis to push location
> information to a mobile webapp.
> As a starting point I used this example by Robin Komiwes:
>
> http://spreadthesource.com/2010/11/bringing-realtime-to-your-java-applications-with-websockets-nodejs-redis-tapestry-5/
>
> The article is old but still relevant and you even have access to the
> source code.
>
> Cheers.
> Alejandro.
>
>
>
>
>
> On Fri, Aug 16, 2013 at 4:43 PM, Lance Java <la...@googlemail.com>
> wrote:
> > Currently, the only integrated push is tapestry-cometd. Howard has
> > mentioned a few times that he'd like to include a push implementation in
> > tapestry core but that hasn't happened yet.
> >
> > As has been mentioned, there's nothing stopping you from using Atmosphere
> > and Tapestry side by side.
> >
> > If you declare the Atmosphere servlet (filter?) outside of tapestry (ie
> in
> > web. xml) you will need to tell tapestry to ignore atmosphere URL's
> >
> http://tapestry.apache.org/configuration.html#Configuration-ConfiguringIgnoredPaths
> >
> > Or, you can have tapestry manage the atmosphere servlet in the same way
> as
> > I mentioned tapestry-cometd does.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Alejandro Scandroli <al...@gmail.com>.
Hi Martin
Are you restricted to a Java application server? can you use things
like NodeJS or Redis?
A couple of years ago, I used Tapestry+NodeJS+Redis to push location
information to a mobile webapp.
As a starting point I used this example by Robin Komiwes:
http://spreadthesource.com/2010/11/bringing-realtime-to-your-java-applications-with-websockets-nodejs-redis-tapestry-5/
The article is old but still relevant and you even have access to the
source code.
Cheers.
Alejandro.
On Fri, Aug 16, 2013 at 4:43 PM, Lance Java <la...@googlemail.com> wrote:
> Currently, the only integrated push is tapestry-cometd. Howard has
> mentioned a few times that he'd like to include a push implementation in
> tapestry core but that hasn't happened yet.
>
> As has been mentioned, there's nothing stopping you from using Atmosphere
> and Tapestry side by side.
>
> If you declare the Atmosphere servlet (filter?) outside of tapestry (ie in
> web. xml) you will need to tell tapestry to ignore atmosphere URL's
> http://tapestry.apache.org/configuration.html#Configuration-ConfiguringIgnoredPaths
>
> Or, you can have tapestry manage the atmosphere servlet in the same way as
> I mentioned tapestry-cometd does.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
As I've said, I wouldn't extend TapestryFilter, you should do one of the
following:
1. Configure AtmosphereServlet in web.xml and tell tapestry to ignore the
atmosphere URL
2. Contribute a HttpServletRequestFilter via tapestry IOC. The filter
delegates through to a AtmosphereServlet instance
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Martin Kersten <ma...@gmail.com>.
Right noticed that. The TapestryFilter is all about final methods. I
currently use a request handler and borrow ideas from cometd implementation
:)
2013/8/16 Thiago H de Paula Figueiredo <th...@gmail.com>
> On Fri, 16 Aug 2013 12:22:57 -0300, Martin Kersten <
> martin.kersten.mk@gmail.com> wrote:
>
> Lance currently I go with extending the TapestryFilter and bend it
>> together with AtmosphereServlet30. If I get some results I post it here. If
>> it is
>> working I will make a blog post and donate the code. Maybe we find a more
>> transparent way, then. Fingers crossed.
>>
>
> I suggest you to implement it as Tapestry HttpServletRequestFilter filter
> instead. This way, you can use all the existing Tapestry infrastructure and
> you don't need to juggle Tapestry-controlled and non-Tapestry-controlled
> stuff.
>
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 16 Aug 2013 12:22:57 -0300, Martin Kersten
<ma...@gmail.com> wrote:
> Lance currently I go with extending the TapestryFilter and bend it
> together with AtmosphereServlet30. If I get some results I post it here.
> If it is
> working I will make a blog post and donate the code. Maybe we find a more
> transparent way, then. Fingers crossed.
I suggest you to implement it as Tapestry HttpServletRequestFilter filter
instead. This way, you can use all the existing Tapestry infrastructure
and you don't need to juggle Tapestry-controlled and
non-Tapestry-controlled stuff.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Martin Kersten <ma...@gmail.com>.
Lance you are right. Also I noticed that you are still maintaining the
cometd implementation. Nice work. I failed using the tapestry filter.
Obviously this isnt the Tapestry way I was trying to do things. I will
mimic the way you did with cometd.
Thanks for your help,
Cheers,
Martin (Kersten)
2013/8/16 Martin Kersten <ma...@gmail.com>
> Lance currently I go with extending the TapestryFilter and bend it
> together with AtmosphereServlet30. If I get some results I post it here. If
> it is working I will make a blog post and donate the code. Maybe we find a
> more transparent way, then. Fingers crossed.
>
>
> 2013/8/16 Lance Java <la...@googlemail.com>
>
>> Currently, the only integrated push is tapestry-cometd. Howard has
>> mentioned a few times that he'd like to include a push implementation in
>> tapestry core but that hasn't happened yet.
>>
>> As has been mentioned, there's nothing stopping you from using Atmosphere
>> and Tapestry side by side.
>>
>> If you declare the Atmosphere servlet (filter?) outside of tapestry (ie in
>> web. xml) you will need to tell tapestry to ignore atmosphere URL's
>>
>> http://tapestry.apache.org/configuration.html#Configuration-ConfiguringIgnoredPaths
>>
>> Or, you can have tapestry manage the atmosphere servlet in the same way as
>> I mentioned tapestry-cometd does.
>>
>
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Martin Kersten <ma...@gmail.com>.
Lance currently I go with extending the TapestryFilter and bend it together
with AtmosphereServlet30. If I get some results I post it here. If it is
working I will make a blog post and donate the code. Maybe we find a more
transparent way, then. Fingers crossed.
2013/8/16 Lance Java <la...@googlemail.com>
> Currently, the only integrated push is tapestry-cometd. Howard has
> mentioned a few times that he'd like to include a push implementation in
> tapestry core but that hasn't happened yet.
>
> As has been mentioned, there's nothing stopping you from using Atmosphere
> and Tapestry side by side.
>
> If you declare the Atmosphere servlet (filter?) outside of tapestry (ie in
> web. xml) you will need to tell tapestry to ignore atmosphere URL's
>
> http://tapestry.apache.org/configuration.html#Configuration-ConfiguringIgnoredPaths
>
> Or, you can have tapestry manage the atmosphere servlet in the same way as
> I mentioned tapestry-cometd does.
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
Currently, the only integrated push is tapestry-cometd. Howard has
mentioned a few times that he'd like to include a push implementation in
tapestry core but that hasn't happened yet.
As has been mentioned, there's nothing stopping you from using Atmosphere
and Tapestry side by side.
If you declare the Atmosphere servlet (filter?) outside of tapestry (ie in
web. xml) you will need to tell tapestry to ignore atmosphere URL's
http://tapestry.apache.org/configuration.html#Configuration-ConfiguringIgnoredPaths
Or, you can have tapestry manage the atmosphere servlet in the same way as
I mentioned tapestry-cometd does.
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Martin Kersten <ma...@gmail.com>.
That is very useful. Sadly my task at hand needs some server push data.
What you suggested is like a lazy init. So after the page loaded go and get
some content. (If I understood you correctly)
I am comming form the GWT world and there is a need to drop GWT for this
project. So I need to learn it the JS + Tapestry way.
Passing Link information is quite an interesting idea. One could also use
something like comments. Back in the old days (08) we stored information in
comment blocks and used GWT/JS to read those configurations. The
configurations where actually components using there own markup writer
instead of templates. Works wonders but might be a bit odd.
So currently i would like to have some sort of server push. How is the
tapestry way of doing server push functionality? On autocomplete you just
issue http requests right? Maybe I should study the Tapestry documentation
on this one... .
2013/8/16 Lance Java <la...@googlemail.com>
> I agree it's not easy, but just wanted to put it up for discussion.
>
> I think that having a clientside function could simplify many components.
> Generating a serverside link then passing it through as javascript
> initializer on the client adds extra code each time. I've done this many
> times in many components. I've often thought it would be nice to generate
> the link clientside instead.
> On 16 Aug 2013 14:14, "Thiago H de Paula Figueiredo" <th...@gmail.com>
> wrote:
>
> > On Fri, 16 Aug 2013 09:01:37 -0300, Lance Java <
> lance.java@googlemail.com>
> > wrote:
> >
> > It would be nice to have a javascript function to generate event URL's.
> >>>>
> >>>
> >> That would need a JavaScript implementation of UrlEncoder, which is an
> >>>
> >> overridable service.
> >>
> >> Validators have both a clientside and a serverside implementation.
> Perhaps
> >> UrlEncoders could do the same?
> >>
> >
> > I guess so. Since @RequestParameter, I'm not sure if it's worth to be
> > implemented, as even after that we'd still need to take care on how to
> add
> > the event activation context without messing up with other stuff,
> specially
> > the t:ac query parameter which contains the page activation context.
> >
> > --
> > Thiago H. de Paula Figueiredo
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<
> users-unsubscribe@tapestry.apache.org>
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
I agree it's not easy, but just wanted to put it up for discussion.
I think that having a clientside function could simplify many components.
Generating a serverside link then passing it through as javascript
initializer on the client adds extra code each time. I've done this many
times in many components. I've often thought it would be nice to generate
the link clientside instead.
On 16 Aug 2013 14:14, "Thiago H de Paula Figueiredo" <th...@gmail.com>
wrote:
> On Fri, 16 Aug 2013 09:01:37 -0300, Lance Java <la...@googlemail.com>
> wrote:
>
> It would be nice to have a javascript function to generate event URL's.
>>>>
>>>
>> That would need a JavaScript implementation of UrlEncoder, which is an
>>>
>> overridable service.
>>
>> Validators have both a clientside and a serverside implementation. Perhaps
>> UrlEncoders could do the same?
>>
>
> I guess so. Since @RequestParameter, I'm not sure if it's worth to be
> implemented, as even after that we'd still need to take care on how to add
> the event activation context without messing up with other stuff, specially
> the t:ac query parameter which contains the page activation context.
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 16 Aug 2013 09:01:37 -0300, Lance Java <la...@googlemail.com>
wrote:
>>> It would be nice to have a javascript function to generate event URL's.
>
>> That would need a JavaScript implementation of UrlEncoder, which is an
> overridable service.
>
> Validators have both a clientside and a serverside implementation.
> Perhaps
> UrlEncoders could do the same?
I guess so. Since @RequestParameter, I'm not sure if it's worth to be
implemented, as even after that we'd still need to take care on how to add
the event activation context without messing up with other stuff,
specially the t:ac query parameter which contains the page activation
context.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
>> It would be nice to have a javascript function to generate event URL's.
> That would need a JavaScript implementation of UrlEncoder, which is an
overridable service.
Validators have both a clientside and a serverside implementation. Perhaps
UrlEncoders could do the same?
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 16 Aug 2013 08:04:44 -0300, Lance Java <la...@googlemail.com>
wrote:
> Thiago's approach works well when the event context is known on the
> server when the Link is generated. When you want to pass dynamic
> clientside values (mouse location, field values etc) you either need to
> use request
> parameters or do some token replacement on the URL generated serverside.
I explicitly said to use query parameters to pass data. ;) In addition,
since Tapestry 5.2, you can use the @RequestParameter annotation in event
handler events instead of using Request.getParameter() and do
conversions/coercions yourself. Example:
onSomeEventName(@RequestParameter("id") User user, ...) { ... },
supposing the 'id' query parameter passed from the AJAX request is an user
id and there's a ValueEncoder registered for the User class.
Notice that the same coercions and assumptions used in normal,
non-annotated context parameters are used for @RequestParameter.
> It would be nice to have a javascript function to generate event URL's.
That would need a JavaScript implementation of UrlEncoder, which is an
overridable service.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
Thiago's approach works well when the event context is known on the server
when the Link is generated. When you want to pass dynamic clientside values
(mouse location, field values etc) you either need to use request
parameters or do some token replacement on the URL generated serverside.
It would be nice to have a javascript function to generate event URL's.
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Dmitry Gusev <dm...@gmail.com>.
+1 for Thiago's approach -- it is also widely used, especially if you want
to render markup or update some zones in response.
On Fri, Aug 16, 2013 at 2:52 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Fri, 16 Aug 2013 06:46:28 -0300, Martin Kersten <
> martin.kersten.mk@gmail.com> wrote:
>
> I investigated the cometd yesterday and today. The maven repository was
>> broken for this one. Since the last commit is half a year old, I think it
>> is not maintained anymore. I currently at the moment try to do the same
>> but
>> using atmosphere instead if this is not working I will try to redo the
>> cometd implementation myself.
>>
>> Are their other (more tapestry like) ways to talk to your js components
>> directly?
>>
>
> 1) Create a Link (which is basically an URL) for your own event by
> @Inject'ing ComponentResources and using its createEventLink() method.
> Let's suppose your event name is XXX, so componentResources.**
> createEventLink("XXX");
>
> 2) Create an event handler for it: JSONObject onXXX() {...}. The return
> value will depend on what you want to be done after the event was handled.
> JSONObject is a Java representation of a JavaScript object in JSON
> notation. @Inject Request and request.getParameter("name") for getting
> query parameters.
>
> 3) Pass the link created in step 2 to your JavaScript code. The easier way
> is @Inject'ing JavaScriptSupport and using its addScript() method, which
> can be invoked, for example, in an afterRender() method (beforeRender() or
> setupRender() also works).
>
> 4) In your JavaScript code, use the link (URL) above as the target of an
> AJAX request and pass any information you need as query parameters.
>
> --
> Thiago H. de Paula Figueiredo
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 16 Aug 2013 06:46:28 -0300, Martin Kersten
<ma...@gmail.com> wrote:
> I investigated the cometd yesterday and today. The maven repository was
> broken for this one. Since the last commit is half a year old, I think it
> is not maintained anymore. I currently at the moment try to do the same
> but
> using atmosphere instead if this is not working I will try to redo the
> cometd implementation myself.
>
> Are their other (more tapestry like) ways to talk to your js components
> directly?
1) Create a Link (which is basically an URL) for your own event by
@Inject'ing ComponentResources and using its createEventLink() method.
Let's suppose your event name is XXX, so
componentResources.createEventLink("XXX");
2) Create an event handler for it: JSONObject onXXX() {...}. The return
value will depend on what you want to be done after the event was handled.
JSONObject is a Java representation of a JavaScript object in JSON
notation. @Inject Request and request.getParameter("name") for getting
query parameters.
3) Pass the link created in step 2 to your JavaScript code. The easier way
is @Inject'ing JavaScriptSupport and using its addScript() method, which
can be invoked, for example, in an afterRender() method (beforeRender() or
setupRender() also works).
4) In your JavaScript code, use the link (URL) above as the target of an
AJAX request and pass any information you need as query parameters.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Martin Kersten <ma...@gmail.com>.
I investigated the cometd yesterday and today. The maven repository was
broken for this one. Since the last commit is half a year old, I think it
is not maintained anymore. I currently at the moment try to do the same but
using atmosphere instead if this is not working I will try to redo the
cometd implementation myself.
Are their other (more tapestry like) ways to talk to your js components
directly?
2013/8/16 Lance Java <la...@googlemail.com>
> FYI, there's no need to wrap the tapestry servlet (it's actually a filter).
>
> tapestry-cometd works by contributing a HttpServletRequestFilter to
> tapestry. The filter instantiates / delegates through to a CometdServlet
> instance.
>
> http://tapestry.apache.org/request-processing.html
>
> https://github.com/uklance/tapestry-cometd/blob/master/src/main/java/org/lazan/t5/cometd/services/internal/CometdHttpServletRequestFilterImpl.java
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
FYI, there's no need to wrap the tapestry servlet (it's actually a filter).
tapestry-cometd works by contributing a HttpServletRequestFilter to
tapestry. The filter instantiates / delegates through to a CometdServlet
instance.
http://tapestry.apache.org/request-processing.html
https://github.com/uklance/tapestry-cometd/blob/master/src/main/java/org/lazan/t5/cometd/services/internal/CometdHttpServletRequestFilterImpl.java
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
Take a look at tapestry-cometd. It's built on top of Atmosphere's CometD
support
https://github.com/uklance/tapestry-cometd
On 16 Aug 2013 06:09, "Martin Kersten" <ma...@gmail.com> wrote:
> Hi there,
>
> back in the old days I used to use GWT alot in conjunction with
> Tapestry. Nowadays it would be fine to develop using JS at the Client side
> and I want to use Tapestry at the backend.
>
> I would love to use something like socket.IO directly within the
> JS-client-code so I investigated the Atmosphere (github) package. Saidly
> there is no direct implementation nor support for the Tapestry world. And
> it looks like I would loose a whole weekend trying without a guarantee that
> I come up with something good.
>
> Currently implementing Atmosphere I would go for a
> HttpServletRequestHandler, warp the Tapestry servlet or even alter it
> directly (so I can use the default Atmosphere servlet based on the accessed
> page and so on. The way I used to implement GWT by creating a Page writing
> http directly using a MarkupWriter seams not to be that feasable since
> Atmosphere has a bunch of things to do, I dont understand right now.
>
> So I would love to know what is the current preferred way to use something
> like the socket.io lib in conjunction with Tapestry as the serving
> backend?
>
>
> Thanks for reading,
>
> Martin (Kersten),
> Germany
>
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Lance Java <la...@googlemail.com>.
I really like DWR's approach to AJAX where it creates a clientside
representation of your serverside services and marshals between javascript
and java. DWR has built in spring integration but it wouldn't be difficult
to create a TapestryCreator (using SpringCreator as a reference) to lookup
services from the tapestry registry.
http://directwebremoting.org/dwr/index.html
http://directwebremoting.org/dwr/documentation/server/integration/spring.html#springCreator
http://grepcode.com/file_/repo1.maven.org/maven2/dwr/dwr/1.1.3/uk/ltd/getahead/dwr/create/SpringCreator.java/?v=source
http://grepcode.com/file_/repo1.maven.org/maven2/dwr/dwr/1.1.3/uk/ltd/getahead/dwr/Creator.java/?v=source
DWR has push support (aka ReverseAjax) but I'm not sure it's bullet proof
as Atmosphere.
http://directwebremoting.org/dwr/documentation/reverse-ajax/index.html
Re: Best way to communicate with JS using Tapestry as BackEnd
Posted by Dmitry Gusev <dm...@gmail.com>.
I've successfully used Atmosphere with tapestry, though I remember that
setup wasn't trivial, but once you do it -- it works well.
Atmosphere provides access to its broadcasters using static factory
methods, so you can get them from whenever you need.
Also I used atmosphere requests interceptors by contributing to tapestry
MasterDispatcher to pass tapestry context (like current authenticated
principal, or tapestry registry instance) to atmosphere through the request
attributes.
Things may changed with Atmosphere because it evolved a lot after I used it.
But when I simply need to call tapestry services from client-side
javascript I prefer using tynamo-resteasy.
Of course in this case you don't get web sockets support.
On Fri, Aug 16, 2013 at 9:09 AM, Martin Kersten <martin.kersten.mk@gmail.com
> wrote:
> Hi there,
>
> back in the old days I used to use GWT alot in conjunction with
> Tapestry. Nowadays it would be fine to develop using JS at the Client side
> and I want to use Tapestry at the backend.
>
> I would love to use something like socket.IO directly within the
> JS-client-code so I investigated the Atmosphere (github) package. Saidly
> there is no direct implementation nor support for the Tapestry world. And
> it looks like I would loose a whole weekend trying without a guarantee that
> I come up with something good.
>
> Currently implementing Atmosphere I would go for a
> HttpServletRequestHandler, warp the Tapestry servlet or even alter it
> directly (so I can use the default Atmosphere servlet based on the accessed
> page and so on. The way I used to implement GWT by creating a Page writing
> http directly using a MarkupWriter seams not to be that feasable since
> Atmosphere has a bunch of things to do, I dont understand right now.
>
> So I would love to know what is the current preferred way to use something
> like the socket.io lib in conjunction with Tapestry as the serving
> backend?
>
>
> Thanks for reading,
>
> Martin (Kersten),
> Germany
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com