>From your first message(s), I had the impression you wanted the GWT 2.1 places to look more like gwt-presenter than what they currently are. When I said gwt-presenter doesn't "get" the concept of places, maybe I should have said it doesn't have the same definition of what is a "place", or at least that the Place object in gwt-presenter doesn't represent the same thing as the Place objects in GWT 2.1.
> >> >> 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. > > >> > I don't understand. Of course RequestFactory only deals with Records, > >> > but that's totally independent from Places and History tokens (well, > > >> Why "of course"? RequestFactory means a factory of "requests", not a > >> factory of "records". You can use RequestFactory to fire requests > >> that don't have any records, e.g., > > >> RequestObject<Long> getMeALongNotUsingARecord(Long param1, Long param2); > > >> no [record] here. > > > Yes, you can, but (correct me if I'm wrong): > > 1. anything more complex than a primitive type or its wrapper class, a > > Date, or a String has to be a Record > > I would use a Record yes but it doesn't have to be. As far as I can tell, it *has* to be: Return type (both client-side and server-side, here's client-side; enforced at compile-time): http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.0-ms3/user/src/com/google/gwt/requestfactory/rebind/RequestFactoryGenerator.java#551 return type, server-side: Parameter types (only enforced on the server-side though; will use .toString() on the client-side when sending the request): http://code.google.com/p/google-web-toolkit/source/browse/tags/2.1.0-ms3/user/src/com/google/gwt/requestfactory/server/JsonRequestProcessor.java#533 > > 2. you'd have to make your own Place and PlaceTokenizer for those, so > > why bother asking RequestFactory for a token? (have I said I do think > > getToken/getProxy are really "just" helpers for > > ProxyPlace.Tokenizer? ;-) ) > > But why should they be limited to ProxyPlace? You understand this is > a toolkit and it's trying to do work that we would otherwise need to > do? If they are are helpers only for Proxy*Place and only > Proxy*Place, why make them so visible by having them in > RequestFactory? Because only RequestFactory knows all record types, and they have to be public API for Proxy*Place to be able to call them (well, Proxy*Place could also cast the RequestFactory to RequestFactoryJsonImpl and getToken/getProxy only be defined there and not on the RequestFactory interface) > > I'd add that having a PlaceTokenizer *per place* is by-design; this is > > very different from gwt-presenter which has a single PlaceFormatter to > > handle all places. > > A place tokenizer per place is a lot of boiler plate code. Even if > you try to minimize the impact. Again, it's clear to me that the goal > of 2.1 is developer productivity. Hence, I don't think this follows > the spirit of it. I came to the same approach of a PlaceTokenizer per Place for my own implementation (well, actually it's less restricted, but you generally end up doing just that: writing a PlaceTokenizer per place), because each Place needed specific code. If all your places can share the same parsing/serialization code, you should (as in "GWT should let you do that") be able to use a single PlaceTokenizer to process them all. If you want to see where I'm coming from, I have a Google Docs that explains what I did (with the details of each iteration in the design process) that I can share with you (it's a draft for a blogpost that I started a while ago and never finished, so I'm reluctant to making it public). (looking at the code more closely, I'm not 100% OK with how it's done: tokens are necessarily of the form <prefix>:<tokenizer-specific-data>, and you cannot have a tokenizer called for the "no prefix found" case; fortunately, the code is rather small, so if you don't want to live with these limitations, you can easily switch the PlaceHistoryHandler generator for your own) > >> > I haven't seen any limitation in PlaceHistoryHandler forbidding its > >> > use with places other the the provided Proxy{,List}Place; of course, > >> > for those places, you'd have to provide your own PlaceTokenizer. > > >> That's what I am currently doing. > > > have you tried using ProxyPlace (provided what it represents –an > > "operation" on a particular record– suits your needs) with a custom > > PlaceTokenizer? > > I did and failed. ProxyPlace means assuming 1:1 between record and > activity. We have a user record. So edit on a user record means > either my preferences, other user or patient. Again, before you > repeat what I said before in a different way, I did state this and > stated how you could accomplish this using ProxyPlace and > ActivityMapper. The feedback was that it's too cumbersome to do it > this way hence we continued to use multiple places. Oh, yes, as I explained, ProxyPlace represents "an operation on a record" with a limited set of possible operations, so if you need more operations than "create record", "see record details" and "edit record" (such as "edit some part of the record" and "edit some other part of the record") then ProxyPlace isn't for you. > >> The other reason why that assumption is made is that > >> AbstractRecordEditActivity requires a record now. Currently, there is > >> no way to build a proxy record, i.e., a record where all fields are > >> stale but the id, in code. > > > Yes you can: use requestFactory.create() > >http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/... > > This produces a record who's id is set to a future from the future id > generator. You have no way of setting the value of the id of the > newly created record. Oh, yes, right. Maybe there should be a RequestFactory.getProxy(Class<? extends Record>, Object id) (FYI, the ID was a String in M1 and M2 and is now a Long in M3, but is expected to be of any type you want in the final release) > >> To address your comment that this is the role of PlaceTokenizer, it > >> is, but currently, there is no standard PlaceTokenizer that handles > >> standard query parameters. > > > And I don't think there should be. Though I think it should be easy to > > build one, and "frameworks" like gwt-presenter would probably given > > one to you. > > Again, you do understand that GWT is a framework? We've written one, > the feedback is that I believe it should be provided, feel free to > disagree. GWT isn't a framework, it's a toolkit. Frameworks like gwt-presenter and gwt-platform will, I believe, continue to exist, based on the new Place/Activity or not. > >> > It may sound a bit harsh but you've IMO been very badly influenced by > >> > gwt-presenter. > > >> Is that really necessary? We're building out a real, big application > >> and giving back feedback. > > > I'm sorry, this was more directed to gwt-presenter than to you > > personnaly. As I said, I really dislike how gwt-presenter deals with > > places, and I think it doesn't "get" the concept of places. > > The reason I'm supporting GWT's approach is that the one I developed a > > year ago for our own apps is very similar (minus the notion of > > activities, but at the lower-level of Place, PlaceController, > > PlaceChangeEvent, and now PlaceTokenizer, there are many things in > > common). > > So that makes it OK to ridicule the hard work that the gwt-presenter > maintainer did? He stepped up after Google I/O 2009 and that's a lot > more than most people can say and just for the sake of full > disclosure, I do not know him. Uh! ridicule?! I think I expressed my opinions about gwt-presenter, and "places" in general, publicly, a year ago, so its maintainer knows what I think about it, which is that I really don't like the way it's done (and to begin with, that there's no need of a "framework" to go MVP, and that "places" are orthogonal to MVP, but that's another debate). That being said, gwt-presenter's approach is *very* different from the one in GWT 2.1, and all I keep saying is that you shouldn't try to compare them. In particular, (I think) one shouldn't ask "I did this that way with project X, please add the same to GWT proper", he should rather say either "I have a particular need Y that doesn't fit in GWT 2.1's approach, could GWT be enhanced to answer my need?" (you can have a look to the RequestFactory wave to see how the design changed in response to such feedback) or "I have a need Y that I can code with GWT 2.1 but it's overly complicated, could GWT be enhanced so it's easier? for reference, it was much easier with project X, where I did blah blah blah..." -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
