Help

Controls

PermLinkWikiLink

Built with Seam

You can find the full source code for this website in the Seam package in the directory /examples/wiki. It is licensed under the LGPL.

Forum: Seam Users Forum ListTopic List
16. Aug 2008, 01:52 CET | Link

Hi! I have to admit am a little shocked (and disappointed) with the limitations imposed by Seam Remoting (I was trying to port from DWR in to Seam Remoting, but I think I found a showstopper):

As there is no native support for Maps within Javascript, a simple Map implementation is provided with the Seam Remoting framework. To create a Map which can be used as a parameter to a remote call, create a new Seam.Remoting.Map object: 

var map = new Seam.Remoting.Map();

Why is that needed? I mean, in DWR, to achieve the same effect (send a datastructure) from JavaScript in to a Java service, all I have to do is: 


  var object = new Object();

If I need to send, for example, name and age all I have to do is: 


  var person = new Object();
  person.name = "John Smith";
  person.age = 16;

Compare that with what seam requires: 


  var person = new Seam.Remoting.Map();
  person.put("name","John Smith");
  person.put("age",16);

IMHO having to use Seam.Remoting.Map is unnecessarily intrusive...

What do I have to do to customize Seam Remoting to support this?

In DWR, I can set a converter:

For a bean: 


<dwr:convert class="somePackage.SomeClass" type="bean"/>

For a map: 


<dwr:convert class="java.util.Map" type="map"/>

What is the equivalent mechanism for Seam Remoting?

 
Please don't forget to rate

I believe that imagination is stronger than knowledge -- myth is more potent than history -- dreams are more powerful than facts -- hope always triumphs over experience -- laughter is the cure for grief -- love is stronger than death.

3 Replies:
16. Aug 2008, 02:04 CET | Link

The goal of Seam Remoting is to provide a JavaScript interface that's (as much as possible) API-compatible with its Java counterpart. However having said that, there's no reason why it couldn't support using an associative array for Map values. Any Map values returned by a remote method would still however be an instance of Seam.Remoting.Map, however it wouldn't be hard to add a toObject() convenience method that would return the Map as an associate array.

If this sounds like it would address your concerns, then please raise a feature request in JIRA.
18. Aug 2008, 17:52 CET | Link

Hi!

Shane Bryzak wrote on Aug 16, 2008 02:04:
The goal of Seam Remoting is to provide a JavaScript interface that's (as much as possible) API-compatible with its Java counterpart.
Mmmm, I think that is fine, it should be comfortable for Java coders, but not at the price of making it uncomfortable for JavaScript coders. It should strive to provide a use of Java services as transparent as possible for the JavaScript side. (The goal should be: Easy for Java coders in the java side, easy for JavaScript coders in the JavaScript side)
However having said that, there's no reason why it couldn't support using an associative array for Map values.
Exactly, and I think associative array should be the default way to deal with both Maps an POJOs (or at least it should provide a transparent way to deal with them)
Any Map values returned by a remote method would still however be an instance of Seam.Remoting.Map, however it wouldn't be hard to add a toObject() convenience method that would return the Map as an associate array.
I like that idea, but it would be even better if something could be configured to deal with associative arrays transparently (perhaps a configuration option in components.xml?)
If this sounds like it would address your concerns, then please raise a feature request in JIRA.

I like the idea of the toObject() in Seam.Remoting.Map, but I think Seam Remoting should also offer:

  1. A complementary method to go from an associative array into a Seam.Remoting.Map easily (perhaps as a parameter in the constructor of Seam.Remoting.Map?)
  2. An alternative to seam/remoting/interface.js (other url like seam/remoting/idiomatic_interface.js, perhaps enabled by a components.xml option) that transparently receives associative arrays and returns associative arrays when the @WebRemote returns (or has a parameter of type) java.util.Map or a POJO (like DWR does). This would be specially helful for porting ajax enable applations built with other remoting techmologies, but also to make it easier for those coders that prefer JavaScript to Java to feel comforable (and dot put objections) to the use of Seam Remoting vs other options to do ajax/remoting.
  3. Give us choice, expose an API to customize Seam Remoting, so that if for some reason this never makes it in to Seam trunk, at least it becomes real easy to create some sort of plug-in to do it.

Thanks

Regards,

P.S. Should I create 3 JIRA entries, one for each of the 3 extra things I think Seam Remoting should offer?

 
Please don't forget to rate

I believe that imagination is stronger than knowledge -- myth is more potent than history -- dreams are more powerful than facts -- hope always triumphs over experience -- laughter is the cure for grief -- love is stronger than death.

18. Aug 2008, 21:22 CET | Link

Created them: JBSEAM-3280, JBSEAM-3281, JBSEAM-3282

 
Please don't forget to rate

I believe that imagination is stronger than knowledge -- myth is more potent than history -- dreams are more powerful than facts -- hope always triumphs over experience -- laughter is the cure for grief -- love is stronger than death.