Re: Managing SerializationPolicy...?
I described what I am doing with the serialization in greater detail in this blog post: http://www.techhui.com/profiles/blogs/simpler-and-speedier-gwt-with thanks, Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
I described what I'm doing with the serialization in great detail here in a blog posting, just in case anyone is interested: http://www.techhui.com/profiles/blog/show?id=1702911%3ABlogPost%3A31619&page=1#comment-1702911_Comment_31745 thanks, Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
The Google IO talk that introduced the topic is here: http://sites.google.com/site/io/resource-bundles-and-linkers-in-google-web-toolkit The public APIs are just not very convenient to use at this point. thanks, Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
I see. Interesting. In that case the easiest way I can think of would be to forget the strong name, name the RPC file some arbitrary name that you copy the generated file to after the GWT compile, and then use that name with SerializationPolicyLoader to get your policy instance. But yeah, like you said, there are a lot of ways you can do it, including implementing your own policy. I've never heard of doing this before so I can't really comment on best practice. Maybe someone else can help you out more. On Feb 3, 1:50 pm, "patnieme...@gmail.com" wrote: > Just to clarify - I'm doing this as part of a regular page request > that bootstraps part of my application, not in response to a GWT RPC > call. So, for example, the client goes to the Foo page and my app > returns the Foo GWT gadget in the page along with all of the data it > needs to start up. > > So there would be no client request to parse for the strong name. I > guess I could catch the strong name when it's sent from as part of the > nocache request and put it into the session or something... but that > is a bit ugly. > > What I was hoping for is a way to get the strong name statically from > some compiled code or some clean way to find the file as part of my > build process. > > I can think of many hacks to fix it... or maybe building a linker, but > all seem wrong. > > thanks, > Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
Just to clarify - I'm doing this as part of a regular page request that bootstraps part of my application, not in response to a GWT RPC call. So, for example, the client goes to the Foo page and my app returns the Foo GWT gadget in the page along with all of the data it needs to start up. So there would be no client request to parse for the strong name. I guess I could catch the strong name when it's sent from as part of the nocache request and put it into the session or something... but that is a bit ugly. What I was hoping for is a way to get the strong name statically from some compiled code or some clean way to find the file as part of my build process. I can think of many hacks to fix it... or maybe building a linker, but all seem wrong. thanks, Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
On Feb 2, 8:27 pm, Dan Ox wrote: > When the GWT RPC client sends a request, the 5th field is the strong > name. If you are creating your own encoded message on the server, then > you can put whatever string you want in there and, presuming you name > the RPC file with the same string, it should automatically get read in > by the code I mentioned above. Thanks. I am not parsing the client request (though from what you said maybe that is the answer) nor am I constructing one explicitly. I am only using the RPC.encodeResultForSuccess() method to take the result of a server side GWT call and serialize it a page in my application. On the server side I place this serialized data into a javascript variable in the HTML page. The GWT code executing on the client then pulls this out, deserializes it, and uses it. The purpose is to save a round trip to the server and to simplify the startup logic. My GWT client comes down with all of its data, type safe, ready to go and does not have to make a remote RPC call. I have wrapped this process with some generic methods to make it easier to use and I'm using it extensively in my app. I read about this capability in one of the google code talks (can't remember the name). But my problem remains that in order to use the RPC.encodeResultForSuccess() method from my server side presentation layer I have to either a) know the strong name or b) manually copy the file into a known location in my build. Again, I may be missing something obvious here. But I'm not sure how to do this properly. thanks, Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
When the GWT RPC client sends a request, the 5th field is the strong name. If you are creating your own encoded message on the server, then you can put whatever string you want in there and, presuming you name the RPC file with the same string, it should automatically get read in by the code I mentioned above. The other alternative I can think of is that you could just generate your own RPC file on application startup. I'm kind of guessing here because I'm not sure why you are encoding your own RPC call on the server. Can you give me some background as to how this all fits together and why? On Feb 3, 1:16 pm, "patnieme...@gmail.com" wrote: > On Feb 2, 7:45 pm, Dan Ox wrote: > > > Are you decoding the request by hand? > > No. I'm simply encoding an object on the server side and stuffing it > into the page using RPC.encodeResponseForSuccess(). Then on the > client side I am pulling it out and decoding it with a > SerializationStreamFactory. (Strictly Server->Client) > > > The SerializationPolicyProvider implementation defines the method: > > getSerializationPolicy(String, String); > > > this provides both the module name and the strong name which you can > > then easily use to read in the rpc file and create a > > StandardSerialisationPolicy. > > Yes, but that is my problem. I do not know the strong name. So I > have been manually copying the compiled .gwt.rpc file to a known name > and then loading it with SerializationPolicyLoader in order to use the > encode API. > > Maybe I'm missing something terribly obvious here. Is there some > procedural way to determine the strong name at run time? And if so > are you suggesting that I then send that name to the server with each > request as part of my API? > > thanks, > Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
On Feb 2, 7:45 pm, Dan Ox wrote: > Are you decoding the request by hand? No. I'm simply encoding an object on the server side and stuffing it into the page using RPC.encodeResponseForSuccess(). Then on the client side I am pulling it out and decoding it with a SerializationStreamFactory. (Strictly Server->Client) > The SerializationPolicyProvider implementation defines the method: > getSerializationPolicy(String, String); > > this provides both the module name and the strong name which you can > then easily use to read in the rpc file and create a > StandardSerialisationPolicy. Yes, but that is my problem. I do not know the strong name. So I have been manually copying the compiled .gwt.rpc file to a known name and then loading it with SerializationPolicyLoader in order to use the encode API. Maybe I'm missing something terribly obvious here. Is there some procedural way to determine the strong name at run time? And if so are you suggesting that I then send that name to the server with each request as part of my API? thanks, Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Managing SerializationPolicy...?
Are you decoding the request by hand? I'm currently using: RPC.decodeRequest(String, Class, SerializationPolicyProvider) The SerializationPolicyProvider implementation defines the method: getSerializationPolicy(String, String); this provides both the module name and the strong name which you can then easily use to read in the rpc file and create a StandardSerialisationPolicy. If not, the strong name should be included in the reqest string. If you are decoding by hand (not sure why you would, but whatever floats your boat) you should be able to pull it out of that. So the above RPC will use your SerializationPolicyProvider to generate the policy. it returns an RPCRequest which you can then call getSerializationPolicy() on and pass the policy instance through to encodeResponseForSuccess(Method, Object, SerializationPolicy) Hope that helps. On Feb 3, 11:11 am, "patnieme...@gmail.com" wrote: > We are using RPC.encodeResponseForSuccess() in our code to serialize > GWT objects and include them in the page (avoiding an extra round trip > and simplifying startup logic in some cases). > > This is a bit awkward as this (the only public) API requires passing a > serialization policy, which changes every time our API changes. > > We can load the generated policy ".gwt.rpc" file with > SerializationPolicyLoader.loadFromStream() easily enough, however this > file has a strong hash name and therefore we cannot automate this step > in our build. > > Now, I'm aware that we could probably create a linker to accomplish > this. But I'm wondering what I'm missing here. The docs imply that > we don't need a policy if we use IsSerializable, but I thought that > this was being deprecated. Or we could create a no-op policy that > accepts everything, but I am not sure of all of the security > implications of that. > > Can anyone tell me how they manage this issue? > > thanks, > Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Managing SerializationPolicy...?
We are using RPC.encodeResponseForSuccess() in our code to serialize GWT objects and include them in the page (avoiding an extra round trip and simplifying startup logic in some cases). This is a bit awkward as this (the only public) API requires passing a serialization policy, which changes every time our API changes. We can load the generated policy ".gwt.rpc" file with SerializationPolicyLoader.loadFromStream() easily enough, however this file has a strong hash name and therefore we cannot automate this step in our build. Now, I'm aware that we could probably create a linker to accomplish this. But I'm wondering what I'm missing here. The docs imply that we don't need a policy if we use IsSerializable, but I thought that this was being deprecated. Or we could create a no-op policy that accepts everything, but I am not sure of all of the security implications of that. Can anyone tell me how they manage this issue? thanks, Pat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
