Thomas Broyer blog posts on places in GWT 2.1
PhilBeaudoin
http://tbroyer.posterous.com/gwt-21-places
http://tbroyer.posterous.com/gwt-21-places-part-ii
It looks like GWT 2.1 places has much in common with GWTP. Here's a
very quick comparison:
- GWT 2.1 allows places without name tokens. This concept doesn't
exist directly in GWTP although it's very easy to do with a custom
@ProxyEvent.
- GWT 2.1 doesn't seem to allow for hierarchical places.
- Both allow user confirmation upon navigation.
- GWT 2.1 uses the event bus for user confirmation. (A bit more
flexible, a bit harder to track.)
- GWTP couples the various good practices (event bus, places, history
management) where GWT 2.1 keeps them separated.
Unfortunately, there are no complete code examples to see how simple/
hard it is to use the GWT 2.1 places, but it definitely looks like an
interesting API.
Thomas Broyer
On 29 août, 02:17, PhilBeaudoin <philippe.beaud...@gmail.com> wrote:
> An interesting read:
> http://tbroyer.posterous.com/gwt-21-places
> http://tbroyer.posterous.com/gwt-21-places-part-ii
>
> It looks like GWT 2.1 places has much in common with GWTP. Here's a
> very quick comparison:
> - GWT 2.1 allows places without name tokens. This concept doesn't
> exist directly in GWTP although it's very easy to do with a custom
> @ProxyEvent.
PlaceHistoryHandler, all places should map to tokens.
Having places without associated PlaceTokenizer (or a PlaceTokenizer
returning null) would work with the current implementation (will log a
warning, and create an history entry with an empty token, which is
probably not what you'd expect) but I believe it's not a goal. I'd add
that it'd be a design mistake: if you have something to show that
doesn't map to an history token, then it's probably more "(temporary)
application state" than a place.
> - GWT 2.1 doesn't seem to allow for hierarchical places.
doesn't place any constraint on places and history tokens; and
probably "hierarchical places" are expected to be made on top of the
current API (that's why I believe GWT 2.1 places and activities won't
replace frameworks like GWTP).
> - Both allow user confirmation upon navigation.
> - GWT 2.1 uses the event bus for user confirmation. (A bit more
> flexible, a bit harder to track.)
to manage in your code than handing PlaceChangeRequestEvent.
> - GWTP couples the various good practices (event bus, places, history
> management) where GWT 2.1 keeps them separated.
>
> Unfortunately, there are no complete code examples to see how simple/
> hard it is to use the GWT 2.1 places, but it definitely looks like an
> interesting API.
Spring Roo is expected to generate (or maybe it's actually an app
generated by Spring Roo, I don't know), and it uses places and
activities.
Christian Goudreau
I don't know what "hierarchical places" mean in GWTP
Christian Goudreau
Philippe Beaudoin
>
> That's not entirely true actually: as soon as you use the
> PlaceHistoryHandler, all places should map to tokens.
> Having places without associated PlaceTokenizer (or a PlaceTokenizer
> returning null) would work with the current implementation (will log a
> warning, and create an history entry with an empty token, which is
> probably not what you'd expect) but I believe it's not a goal. I'd add
> that it'd be a design mistake: if you have something to show that
> doesn't map to an history token, then it's probably more "(temporary)
> application state" than a place.
Good to know. And I agree with you, places without name token would be
kind of weird.
>> - GWT 2.1 doesn't seem to allow for hierarchical places.
>
> I don't know what "hierarchical places" mean in GWTP, but GWT 2.1
> doesn't place any constraint on places and history tokens; and
> probably "hierarchical places" are expected to be made on top of the
> current API (that's why I believe GWT 2.1 places and activities won't
> replace frameworks like GWTP).
There seemed to be the notion of "prefix" in the history token, which
is some kind of constraint, no? In GWTP each history token should have
a number of components:
a) An ordered list of "history tokens" (the hierarchy), of size 1 if
you don't use the feature
For each history token:
b) A name token (typically the prefix) that let's you identify the
requested place
c) A parameter list to pass to the requested place
The tokenizer is expected to be able to distinguish between these. The
default implementation accepts hash parameters like:
#nameToken1;param1=value1/nameToken2;param1=value1;param2=value2
This will display the place with "nameToken2", but the since the place
manager knows about the hierarchy it lets you do a couple of things:
- Navigate back to the "logical" places you visited before, even if
there are many ways to reach "nameToken2"
- Display breadcrumbs
> Have you looked at the "scaffold" samples in bikeshed? That's what
> Spring Roo is expected to generate (or maybe it's actually an app
> generated by Spring Roo, I don't know), and it uses places and
> activities.
I haven't had the time to look at GWT 2.1 new classes and examples,
unfortunately. That's why I was glad to see you started a series of
blog post summarizing it. My comment was merely about the fact that,
from you posts, it was hard for me to evaluate the amount of work
needed to setup these places.
Thanks a lot for your answer, Thomas,
Philippe
Thomas Broyer
> On Sun, Aug 29, 2010 at 3:03 AM, Thomas Broyer wrote:
>>
>> I don't know what "hierarchical places" mean in GWTP, but GWT 2.1
>> doesn't place any constraint on places and history tokens; and
>> probably "hierarchical places" are expected to be made on top of the
>> current API (that's why I believe GWT 2.1 places and activities won't
>> replace frameworks like GWTP).
>
> There seemed to be the notion of "prefix" in the history token, which
> is some kind of constraint, no?
Yes, you're right. I opened an issue a few days ago to kind of "relax"
the constraint (actually just make it possible to bypass or complement
the built-in token-to-PlaceTokenizer with a
catch-all/fallback/prefix-less PlaceTokenizer):
https://jira.springsource.org/browse/ROO-1276
> In GWTP each history token should have a number of components:
> a) An ordered list of "history tokens" (the hierarchy), of size 1 if
> you don't use the feature
> For each history token:
> b) A name token (typically the prefix) that let's you identify the
> requested place
> c) A parameter list to pass to the requested place
>
> The tokenizer is expected to be able to distinguish between these. The
> default implementation accepts hash parameters like:
>
> #nameToken1;param1=value1/nameToken2;param1=value1;param2=value2
>
> This will display the place with "nameToken2", but the since the place
> manager knows about the hierarchy it lets you do a couple of things:
> - Navigate back to the "logical" places you visited before, even if
> there are many ways to reach "nameToken2"
> - Display breadcrumbs
That's what I discovered a few hours after responding, and I think
such hierarchical places are not a goal for GWT (I haven't seen any
public discussion from Google about this), but making it possible to
be implemented on top of the provided API probably is.
>> Have you looked at the "scaffold" samples in bikeshed? That's what
>> Spring Roo is expected to generate (or maybe it's actually an app
>> generated by Spring Roo, I don't know), and it uses places and
>> activities.
>
> I haven't had the time to look at GWT 2.1 new classes and examples,
> unfortunately. That's why I was glad to see you started a series of
> blog post summarizing it. My comment was merely about the fact that,
> from you posts, it was hard for me to evaluate the amount of work
> needed to setup these places.
OK, then wait a bit for the "GWT 2.1 Activities" article ;-)
... and I'll probably port the SimpleNestedSample to GWT 2.1 (if you
have a "better" sample, or one that you'd prefer I look at rather than
nestedsample, tell me, I haven't started anything, just looked at the
sample's code and wiki page for now), showing at the same time that
you don't need "nested presenters" for such a simple case.
Philippe Beaudoin
> OK, then wait a bit for the "GWT 2.1 Activities" article ;-)
> ... and I'll probably port the SimpleNestedSample to GWT 2.1 (if you
> have a "better" sample, or one that you'd prefer I look at rather than
> nestedsample, tell me, I haven't started anything, just looked at the
> sample's code and wiki page for now), showing at the same time that
> you don't need "nested presenters" for such a simple case.
You are right that nested presenters are not needed for such a simple
case. The doc could probably be made clearer on this, indicating that
the same could be done via other, simpler ways. For example, from
simpler to more complex:
- inject a helper class to populate the link menu
- use a custom link widget
- inject a PresenterWidget for the navigation menu
The goal of this sample, however, is not to show WHEN to use nested
presenters, but HOW to use them.
As to WHEN they are useful: in many cases you will have a page
containing unrelated views onto the same (or different) pieces of
information. Nested presenters are a very convenient mechanism to do
that as they decouple these various views. If you think there is
always a better approach, I would be happy to hear it. Personally,
however, I find nested presenters to be very convenient.
On a related note, I think the problem with many frameworks is that
they show how to do simple stuff simply. Often, however, these
approaches don't scale to the needs of a real production app. That's
why, in the nested sample, we decided to show how to do something
simple (for clarity) the way a production app would like to organize
their more complex scenarios.
In conclusion, the SimpleNestedSample is probably a good candidate for
simplicity, but if you want to take a stab at the usefulness of nested
presenters please consider a more complex case.
Cheers,
Philippe
Thomas Broyer
> On Sun, Aug 29, 2010 at 9:16 AM, Thomas Broyer wrote:
>> OK, then wait a bit for the "GWT 2.1 Activities" article ;-)
>> ... and I'll probably port the SimpleNestedSample to GWT 2.1 (if you
>> have a "better" sample, or one that you'd prefer I look at rather than
>> nestedsample, tell me, I haven't started anything, just looked at the
>> sample's code and wiki page for now), showing at the same time that
>> you don't need "nested presenters" for such a simple case.
>
> You are right that nested presenters are not needed for such a simple
> case. The doc could probably be made clearer on this, indicating that
> the same could be done via other, simpler ways. For example, from
> simpler to more complex:
> - inject a helper class to populate the link menu
> - use a custom link widget
> - inject a PresenterWidget for the navigation menu
In GWT 2.1, you wouldn't have an activity at the top-level, so there
would be a single "level" and no need for nesting at all.
> The goal of this sample, however, is not to show WHEN to use nested
> presenters, but HOW to use them.
Oh, OK then.
> As to WHEN they are useful: in many cases you will have a page
> containing unrelated views onto the same (or different) pieces of
> information. Nested presenters are a very convenient mechanism to do
> that as they decouple these various views. If you think there is
> always a better approach, I would be happy to hear it. Personally,
> however, I find nested presenters to be very convenient.
Sure, I do think nested activities are the way to go in these cases. I
haven't yet looked at how nested presenters work exactly in
gwt-platform (I didn't intend to look at gwt-platform initially, just
describe how GWT 2.1 is/will be, not compare it with existing
frameworks), but I think nested ActivityManagers would be how you'd do
it in GWT 2.1; the main difference being that GWTP reveals them
"automatically" from bottom to top (map a place to a "leaf" presenter,
using the "slot" information to reveal the container presenters) where
as in GWT 2.1 you'd actually manage the whole thing, and they would be
revealed from top to bottom. But there might be a way to do it the
GWTP way with GWT 2.1, i.e. with less coding.
Currently, GWT 2.1 activities are unfortunately not well-suited for
nested activities:
https://jira.springsource.org/browse/ROO-1309
https://jira.springsource.org/browse/ROO-1310
but the API is still in flux; and it currently requires many
dispatching code that could be generated (I made a proposal in the
design Wave https://wave.google.com/wave/waveref/googlewave.com/w+eva-sERfA
)
We're prototyping a "real production app" with GWT 2.1 and are facing
these issues; we're currently trying to find the best way(s) to handle
them, and will give feedback (and ask advice) to the GWT team.
> On a related note, I think the problem with many frameworks is that
> they show how to do simple stuff simply. Often, however, these
> approaches don't scale to the needs of a real production app. That's
> why, in the nested sample, we decided to show how to do something
> simple (for clarity) the way a production app would like to organize
> their more complex scenarios.
>
> In conclusion, the SimpleNestedSample is probably a good candidate for
> simplicity, but if you want to take a stab at the usefulness of nested
> presenters please consider a more complex case.
Do anyone have such a case somewhere that I could look at? (would be
best with the code so people could compare a "with GWTP" and "with GWT
2.1", but a real-world app, ideally made with GWTP, but more
importantly that anyone could "play" with, could be enough)
brendan
http://gwtp-breadcrumbs.appspot.com/
On Aug 30, 1:13 am, Christian Goudreau <goudreau.christ...@gmail.com>
wrote: