Example:
---------------------------------------------------------------
| username logout|
------------------------------------------------------------------
| aside | add, delete, other action |
| menu | ----------------------------------------------------|
| | filter by a, b, c |
| | ----------------------------------------------------|
| | maincontent (ie: celltable) |
| | |
| | |
| | |
| | |
| | |
-------------------------------------------------------------------
Aside Menu will be created after the user logins and remains during
the entire session.
The same for the header.
Now, my doubt is about the main content area (actions panel, filters
panel and main content panel).
What I did to get this layout working is:
1. I created two widgets, MainDisplayFilters and MainDisplayActions.
2. I created an AppLayout and injected those widgets.
3. In every one of my views, for example UsersListView, I inject
MainDisplayFilters and MainDisplayActions, clear the widgets, and add
to the widgets the buttons for the actions and the filters that I need
in the current activity.
I really DONT like this approach :) but I can't figure how can I do it
in a better way. Should I create an ActionsActivityMapper and a
FiltersActivityMapper, and diferent activities / views for this panels
for every place that the user goes? For example, if the user goes to
UserListPlace, load the UserListActionsActvity (with it owns view) and
the UserListFiltersActivity? It doesn't make many sense, I think.
I was reading about Thomas Broyer post http://tbroyer.posterous.com/gwt-21-activities-nesting-yagni
but actions panels and filters panels are in someway connected to the
maincontent activity, that's why I believe that I don't need more than
one ActivityMapper.
I neither don't like the idea to have the actions panel + the filters
panel + content panel all in one view, beacause if in the future I
want to change something in the layout (for example add a pagination
control on the right of my actions panel), I would have to do it in
every view.
Wich one would be the best way to handle a layout like this?
On Dec 3, 9:53 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> If your 3 parts are tightly linked (you have different actions and
> different filters for each different "main content"), given that they're
> displayed next to each other, then you only need one activity.
>
> I'd however try to code them as three distinct "components" (widgets)
> linked only through events (true events with event-handlers using
> addHandler, or simply using callbacks).
So, for example I will have to create with (or without) UIBinder a
widget for every actions menu or filters menu that I need (dispite of
reusing anyone when I could). For example UsersListActions widget and
UsersListsFilter widget.
On more doubt. Wich one would be the way to communicate between this
widgets (actions and filters panels) and the current presenter (in my
case, the current activity)?
That should make it easier maintain
> the whole thing (otherwise your "main content with actions and filters"
> could grow and become unmaintainable) but more importantly, if you think
> you could visually separate them later, that would make it easier (in that
> event, route the events through the event bus and "you're done"). It would
> make it possible/easier to reuse one part in different views (e.g. if
> most/all lists have the same set of actions).
>
> I'm afraid there's no "one size fits all" approach; it (in part) depends
> how you imagine your app will evolve. The whole idea of activities are to
> decouple things, it doesn't make sense for things that are tightly coupled
> (unless they're separated visually into non-adjacent areas). The idea is
> that, for instance, a "main menu", a "list of things" and "details about
> one thing" could all appear on the screen at the same time on a desktop,
> but appear as "sequential screens" on a smart phone (and using MVP within
> an activity, you can in addition decouple the view –wide on a desktop,
> narrower on a smartphone– from the behavior)
>
> To me, however, your current design is clearly not the best (or i
> misunderstood it): why use MainDisplayFilters and MainDisplayActions as
> singletons that you clear/populate each time instead of simply using
> distinct instances in each view?
I did it in this way because I don't know how can I tell to my
presenter from some widget to perform some action (ie: delete some
users) or how to communicate to the vie.
For example, on the start method of UserListActivity I make a rpc to
load the users and populate my UsersListViewImpl. IE: How can I tell
to my UsersListsActions widget that there are n users? Or how can I
know from my UsersListsActions widget how many rows are selected in my
UsersListViewImpl? How can I tell from my UsersListsActions to my
UserListPresenter to delete some users?
Please sorry if I am asking some dumb question because my low level of
knowlegde :)
I was reading and reading GWT & MVP but I am just a little dizzy.
On Dec 3, 9:53 pm, Thomas Broyer <t.br...@gmail.com> wrote:
> If your 3 parts are tightly linked (you have different actions and
> different filters for each different "main content"), given that they're
> displayed next to each other, then you only need one activity.
>
> I'd however try to code them as three distinct "components" (widgets)
> linked only through events (true events with event-handlers using
> addHandler, or simply using callbacks).So, for example I will have to create with (or without) UIBinder a
widget for every actions menu or filters menu that I need (dispite of
reusing anyone when I could). For example UsersListActions widget and
UsersListsFilter widget.
On more doubt. Wich one would be the way to communicate between this
widgets (actions and filters panels) and the current presenter (in my
case, the current activity)?