is there a framework above Actitivies,places,editors and RequestFactory

[Elhanan]

there is a plethora of new api's starting from gwt 2.1 however there
seem to be low level like, and i was wondering if anyone managed to
develop a pattern from them yet..

[Thomas Broyer]

We built a micro-framework on top of Activities, specialized in a few places for editors and/or RF, but it was only to enforce best practices because the team was new to GWT, new to MVP, new dependency injection, new to many things.

For instance, we're using singleton views with disposable presenters (and our presenters are our activities; or, our activities are presenters, depending on how you look at it ;-) ), so we built a subclass of AbstractActivity that enforces that the view is only used between start() and onCancel/onStop, and that the AcceptsOneWidget passed to the start() method is never called back after onCancel/onStop, and a few others things like that. It's a very prescriptive and restrictive API, that helped everyone getting on board, but as someone who knows what I'm supposed to do, it feels overly restrictive for me, and I sometimes regret to have built it.

I don't think there's a need for such "framework", what's needed is only a set of best practices (and then, if possible, a set of tools to check that they are followed). But those best practices are probably not the same for everyone: should the activities be presenters (in the MVP pattern)? should they be disposable or singleton? should views be singletons?

The main missing tool IMO is one to help generate ActivityMappers (similar to how PlaceHistoryMappers can be generated too).

[Elhanan Maayan]

actually i think there should be no code activity mapper as the place itself should contain the logic on what activity it should be refferred, for each new place activity combo i have to go though lots of boiler plate code which is really redudent..

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/8dSTKTOy6QwJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

The place cannot (and shouldn't!) contain anything more than an immutable representation of "some state", "some place". As soon as you start having several ActivityManagers, you can no longer ask you Place to know which Activity should go in which display region.

See, in our app, we have 18 activity mappers! (a bunch of them return 'null' except in a couple of cases, to build a "dynamic toolbar"). You might think we somehow "abused" them, but even if we try to have as few as possible, we'd still have at least 3 of them (one main area, a "north" one and an "east" region).

Just recently, we added a new one, and we're in the process of adding yet another; that'd give us 20 activitymappers, or 5 of the if you want ot look at the "stripped down" potential version.

Clearly, it's not the place's concern to give us the activity (not to mention that one place has half a dozen "parameters", and several of them condition which activity will be used, with each activity mapper using them differently). To give an idea, we have 124 different activity classes, and only 10 Place classes or so. Among our 124 activities, 12 of them are for the "east" area, and 12 for the "north" area; leaving 100 distinct activities for the "main region" (and yes, our activity mappers are hardly readable).

Another advantage of separating those concerns is that of "multimodal" applications, where the same place means a distinct set of activities depending on the device running the app. You can see this in action in the "mobilewebapp" sample, which comes in 3 versions (phone, tablet, desktop/laptop) mostly by swiping the "shell" (definitions of the screen "areas") and activity mappers (and a few activities too, but there's no reason some activities couldn't be reused in a few or all "modes"), allowing you to share most of the code base.

[Jens]

Am Montag, 20. Juni 2011 14:50:00 UTC+2 schrieb Elhanan:

actually i think there should be no code activity mapper as the place itself should contain the logic on what activity it should be refferred, for each new place activity combo i have to go though lots of boiler plate code which is really redudent..

Hm if you want to define the activity by the place I think you can simply do it. Create an AbstractPlace that contains an abstract method like getActivity() that returns new activities for that place. Your ActivityMapper would then be more or less a three liner. If you have more than one display area you would need more than one method, e.g. getMainActivity, getSideActivity.

[Elhanan Maayan]

actually that's EXACTLY what i did, only on in the place itself as thomas thinks i did, there is only ONE place class which contains as single token string.

the reasons for this is override gwt's type system for the places where each place class  is by default a new place, which goes against oo principals which say that you only extend a class is it has additional  functionality
i then created one place tokenizer class, which is actually the place's factory so to speak, this is the class i'm actually subclassing for new places, but the new functionality here is the abstract method getActivity where each  tokenizer implements with their own activity, thus the activity mapper is really just a 3 liner , and as each places holds a reference to it's creator it's simple go map them all thus i'm avoid all the annotations specifications required for tokenizers

by implementing activity mapper's get place with the only the parameter place, you allready "bound" and tried to place for activities relationships.

what's more if even if have different activity mapper which influcence on the decision, then they should be included as a parameter and supply a generic method for each mapper to implement which will assist in decision.

the way i look at it, the same place where you define a .. "place" (not necessarily INSIDE the place, but logically)  should also provide for way to know what activities to use, other wise you have to run around difference ..places to maintain your code.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/8UhwpTWBmhgJ.