GXT MVC Design Q - Dialogs....

[jadrake75]

My application has a series of MVC controllers and views for the main "structure" of the application's viewport (typical split pane, border like layout components...). I have a series of dialogs which you can think of as a windows which "show up" on top of the viewport to do some more detailed editing of some of my models.

I have a RestfulModelController which is hooked up to recieve "Submit" or "Remove" events and hands all the AJAX request stuff to save (or update) or delete a model. This emits a persistentEvent of Created, Updated or Deleted which will be captured by the controllers that have stores (or other constructs) that can get updated based on the result of changes made within the ModelController. This all works fine.

My conundrum is this. Does my dialog/panel need to be controlled by a view?
If I have three launch points (right-click on an item, a top-level menu and a toolbar somewhere) all can have an onClick listener to call:

AlbumActions.create( )

or

Dispatcher.dispatchEvent( new AppEvent( StampEvents.Create, Album.class ) );

My point is.... what would be the benefit of creating a View for the my dialog (ie. I would have a view, that upon receiving a Create event, would initialize the dialog and show it) rather than simply having a helper actions class call "show( )" after constructing the window?

In a JSP application where the View is a JSP, and it is tied to the action this makes a little more sense, but in this case it almost seems like a level of indirection without a lot of benefit. The only benefit I see, is that because my view was provided a controller when created (in this case the RestfulModelController), upon clicking "Ok" I can call that controller with the Events.Submit event type occurred rather than bubble it up to the EventDispatcher and have it bubble down through the controller heirachy to the controller who knows how to handle that model type. For the show/hide case I don't see a lot of value here.

What are people's thoughts on this?

-Jason

[FireGlow]

If you have a view you can register the dialogs and stuff with it.

For example if you have an asynccallback to add data to your application. What happens if it is successful? You need to "destroy" your window/dialog. But how you do that?

You can use again the dispatcher, firing an event DATA_IMPORT_SUCCESSFUL which can you forward to the view, that can destroy again your window/dialog and shows a message that it was successful.

And how you handle for example if a callback didn't work, for example because an attribute of your data already exists in your database? You can again yous for example DATA_IMPORT_FAILED and give it to your view, that knows how to mark (e.g.) a field or giving suggestions for other names...

That are examples where I think that if you register your dialogs/windows/form to a view , you can handle it better.

[jadrake75]

As I thought on this another benefit to tying the dialog to the controller directly (as opposed to the Dispatcher) aside from the handling or errors (and coding the error handling into the dialog) which FireGlow points out is the addition of future events to be monitored by both. The "contract" between them is such that it would be rather trivial to handle additional events without having to worry about the broadcast/cascade handling them correctly.

[karacutey]

bundling view stuff in your "brains of your app" or other data structures is generally considered sloppy coding, as your not completing the fully MVC. During testing putting in various view components for testing events or data structures is fine, but when you start scaling your app, having view stuff not specifically defined becomes more trouble then what you save by excluding it. You have to fine the right balance between time to deliver and elegant coding. gxt i have found makes that easier then the rest. IMHO

for example we use xml data structures with gxt to handle the view and jsp to handle controlling, this all fits togethers extremely nicely with little work. Sometimes i have the jsp or xml create tags or other triggers which fire events within gxt. 9/10 times this is for code that is under dev, or for error or debug reporting. cluttering up your data structures or smarts of your app with dependent view components or view controllers is a nightmare.

kAra