Re: [gwt-contrib] PlaceHistoryManager
I am familiar with SecurityProvider but it's used from the server, not place history. SecurityProvider works on the server to determine if an operation is allowed, which is just checking for the @Service annotation right now. I am talking about the new methods in RequestFactory that provide support for bookmarble locations based on Records. So for UserAccountRecord, requestFactory.getToken(record); will produce a string com.yourcompany.records.UserAccountRecord-id which is big On Sun, Aug 22, 2010 at 12:37 AM, Ray Cromwell cromwell...@gmail.com wrote: On Sat, Aug 21, 2010 at 11:13 AM, Patrick Julien pjul...@gmail.com wrote: 1. The tokens are big, they include the full path to the class, so all packages and the name of the class. It's a lot. In our case, it also exposes the name of the contractor to the user of the application. This is only temporarily, if you look, there's a class called SecurityProvider, eventually, all tokens will be mapped through this supporting arbitrary schemes. I believe we are looking at payload compression/minification for M4 or M5. I'll let Ray Ryan answer the others. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] PlaceHistoryManager
Right, it's not implemented now, but planned. In M4+, all of these tokens will change from getClass().getName() to an obfuscated identifier (e.g. getToken(Foo.class) - xW). The security provider implementation on the server will know how to decode these. I realize that, like pretty and short URLs, it would be nice go have compact history encoding, as well as options to control the look and feel if you want 'pretty/readable' tokens. I think Ray Ryan's currently designed encoding is just a place holder. -Ray On Sun, Aug 22, 2010 at 5:56 AM, Patrick Julien pjul...@gmail.com wrote: I am familiar with SecurityProvider but it's used from the server, not place history. SecurityProvider works on the server to determine if an operation is allowed, which is just checking for the @Service annotation right now. I am talking about the new methods in RequestFactory that provide support for bookmarble locations based on Records. So for UserAccountRecord, requestFactory.getToken(record); will produce a string com.yourcompany.records.UserAccountRecord-id which is big On Sun, Aug 22, 2010 at 12:37 AM, Ray Cromwell cromwell...@gmail.com wrote: On Sat, Aug 21, 2010 at 11:13 AM, Patrick Julien pjul...@gmail.com wrote: 1. The tokens are big, they include the full path to the class, so all packages and the name of the class. It's a lot. In our case, it also exposes the name of the contractor to the user of the application. This is only temporarily, if you look, there's a class called SecurityProvider, eventually, all tokens will be mapped through this supporting arbitrary schemes. I believe we are looking at payload compression/minification for M4 or M5. I'll let Ray Ryan answer the others. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] PlaceHistoryManager
I've been experimenting with PlaceHistoryManager and company. So far, I have the following comments: 1. The tokens are big, they include the full path to the class, so all packages and the name of the class. It's a lot. In our case, it also exposes the name of the contractor to the user of the application. 2. Tokens in RequestFactory only work with Record based classes. I think that's a shame. Will another facility supplement this? Because if tokens from gwt will only support Record, why even bother with ProxyPlace? Just make a goTo method in PlaceController that takes a record. I would prefer to have tokens for a place directly. I think that can be accomplished by having multiple place tokenizers however, one per place. 3. Ultimately, I don't think the assumption that a record type is 1:1 to an activity. The mapper stuff allows for this but is yet more code. 4. It's a lot harder than it seems to always have a record ready to go. Especially coming from gwt-presenter were we always try to just keep a numeric id. 5. I think the Place class getting support for a collection of arguments, i.e., setArgument(String, String); String getArgument(String); clearArguments(); and more importantly, parseArguments(String s); so that we can pass in a string from the PlaceTokenizer.getPlace() after we've removed the prefix would be most helpful and be applicable to most. thank you, -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] PlaceHistoryManager
On Sat, Aug 21, 2010 at 11:13 AM, Patrick Julien pjul...@gmail.com wrote: 1. The tokens are big, they include the full path to the class, so all packages and the name of the class. It's a lot. In our case, it also exposes the name of the contractor to the user of the application. This is only temporarily, if you look, there's a class called SecurityProvider, eventually, all tokens will be mapped through this supporting arbitrary schemes. I believe we are looking at payload compression/minification for M4 or M5. I'll let Ray Ryan answer the others. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
