Disapointed in latest release, why no url encoding for asyncPost() ?

[Mr. Monster]

I was looking forward to this release expecting that asyncPost() would
allow for url encoding style of passing parameters. This has been
discused in the past and I made number of requests to get this option
implemented.

I realize gwt is written in java but not everyone in the world is using
Java as their server backend, have you guys heard of the little thing
called PHP ?

The current asyncPostImpl() makes asyncPost() calls to a PHP server
totally useless since it doesn't understand the Java RPC stuff.

Is there a reason you guys are trying to avoid this? It would be such
an easy addition and would make life easier for the rest of us.

Thank you.

[bruciadmin]

I feel for you - having to use PHP, what a drag.

Just kidding dude - couldn't help put in some light hearted jostling: )

Hmmm, I haven't looked too deep into the RPC serialisation code, but I
would say that there is a fair investment in there with Java as the
backend. I'm not sure Google would be willing (at least at this stage)
to double that investment effort for PHP. However, I think as long as
they make it possible to implement your own serialisation then other
people can add support for other server back ends as required.
Otherwise, Google risk having to keep adding on a new serialisation
module everytime someone asks for support of a new server side
technology - which from a business perspective is kinda suicide.

In the interim, have you considered using a Java facade over your PHP
service on the server side? The server logic would be pretty simple and
would just turn the Java object passed in to some kind of PHP friendly
XML and reroute it. Then again, this is your bread and butter, so
you've probably thought about this from many different angles and have
an existing workaround already implemented.

[Fred Drake]

Unless I'm misunderstanding you, there are a few courses of action you can take if you are wanting to use RPC through a PHP back end:

1) Use the new JSON libraries that were introduced (officially, anyways) in GWT 1.1 .  You can find a good JSON library for PHP here:  http://mike.teczno.com/json.html

2) Use my XMLRPC library here: http://fredhat.com/xmlrpc-gwt/   I need to refactor the XML calls to use the officially supported libraries in 1.1 but it seems to work just fine on both versions.

If you know that your server side code will only be called from your GWT client code (or other Javascript), i'd go with JSON since it's officially supported and not have to rely on a third party library (even if that third party is me).  But if you are wanting server side compatability with other technologies using the same back end (.NET, Java, whatever), go with XMLRPC.

Hope this helps,

-Fred

--
Fred Drake

"All my friends became Cardinal fans and grew up happy and liberal. I became a Cub fan and grew up imbittered and conservative." -- George Will

[bruciadmin]

Discard what I said about a Java facade - Fred's answer is much better:
P

[Mr. Monster]

The solution is a lot simpler, basically all is required is 1
additional parameter to asyncPost() that lets us specify the encoding
of the post data.

So the extra paramter would either make the asyncpost use

xmlHttp.setRequestHeader("Content-Type", "text/plain; charset=utf-8");
// as it does currently by default which works with Java RPC

or

xmlHttp.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded"); // this allows for regular POST
data to be sent to the server

I don't see why this couldn't have been included, it's so simple to
implement.

[Mr. Monster]

By regular post data i mean you can send "myvar=123&myfoo=456"
string as post parameter and these would end up on the server as POST

[Fred Drake]

I understand.  All in due time, I suppose.  As a workaround, I suggest using the code given here:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/8f40e437c5697f27/eaf572faee9347d7?lnk=gst&q=gmargalit&rnum=2#eaf572faee9347d7

It is basically the async call via JSNI, which sets the request header to whichever you want.  I have this in my XMLRPC library because certain implementations require that the incoming POST message be of the type text/xml.

-Fred

On 8/14/06, Mr. Monster <kpl...@gmail.com> wrote:

[Fred Drake]

Oh whoops, I see you've already been aware of that thread.  Well, it's served my purpose well anyways.

-Fred

--
Fred Drake

"All my friends became Cardinal fans and grew up happy and liberal. I became a Cub fan and grew up imbittered and conservative." -- George Will

[Scott Blum]

Hi Mr. Monster,

I understand your frustration, considering that this feature has been
specifically requested. Unfortunately, we just had to draw the line
somewhere in order to get a new release out, and not everything we
wanted to do could make it in. I don't consider this to be a great
answer, but I would suggest you simply copy your own version of
HTTPRequest into your application and add the parameter you need. I
agree it should be there, but we had to prioritize the features that
are difficult (or impossible) for someone to implement themselves.

Scott

[Mr. Monster]

Thanks for the reply Scott

Maybe in the next release perhaps?

[hoosie]

This may be a stupid question, but I really have to ask since I've seen
this complaint a few times.

What is all this about the lack of url encoded POST requests? In
version 1.0.21 I was completely successful sending the following style
of post to a backend php script (which parsed it using the php://input
stream)

HTTPRequest.asyncPost(
"http://69.55.12.155/blarg.php?action=DoSomethingCool",
"name=pickles&notes=artichoke&description=muffin",
new ClickResponder()
)
class ClickResponder implements ResponseTextHandler {
public void onCompletion(String responseText)
{
Label label = new Label(responseText);
RootPanel.get().add(label);
}

and now in version 1.1.0 I simply use the FormPanel which achieves
exactly the same goal. Both ways result in proper post requests being
received by the server, and both receive responses. What abilities
exactly would the feature requested in this thread provide?

[hoosie]

After reading some more, I am wondering if the only difference is the
parsing of post data. My php code does this:

$data = file_get_contents('php://input');
parse_str($data, $postData);

perhaps this is the only difference? that the POST data is not
automatically ending up in $_POST? If that's the case, then this is an
easy 2 line workaround to the problem...

[Mr. Monster]

That could do the trick, will look into it thanks!