You really have to treat qooxdoo apps like you would a Swing, GTK+ or
Qt application. Application.main() isn't exactly a controller, rather
the entry point into your long-running application. It allows you to
bootstrap any data/configuration your application is going to need.
When you're asking about a view factory to hide the details of
view/controller instantiation, I hope you don't mean controllers/views
are short-lived (ala, traditional web mvc apps...??)
Here is how I approach qooxdoo architecture. It is not an
end-all-be-all for everyone or every situation, but for most cases it
works for me.
/** THE VIEW **/
A single 'View' will be a composite of many controller/view
components. This whole system of components let's call a Screen.
Your Screen controller should be one class that handles all of the
async data collecting/validating, and then passing data to/from the
Screen view, for example: a class that extends Window. Inside the
view, you'll find the specific GUI components, as well as the specific
component controllers (say, an instance of qx.data.controller.Form)
This whole system of controllers, views, and models make up a single
Screen. Your application's navigation system (Application Controller)
need to be able to be able to route to a specific Screen based of some
routing system rule, fired by some event (mouse click, session
timeout, etc...) This whole Screen system could be considered 'the
view'.
/** THE MODEL **/
IO is pulled out to its own class(es) and abstracted for various uses.
On top of these, I employ data repositories; one for each entity
type. These use the IO classes to collect/generate data, and map to
their specific entity types. The data repos themselves are not aware
of the other repos, nor are the controllers directly aware of the
repos. Rather, there is a data service bus, which allows any class to
query for any type of object asynchronously. This cleanly separates
the data from the the rest of the application.
/** THE CONTROLLER **/
The controller should the application's evented navigation system.
This should be instantiated and executed from Application.main() It
should know what events to respond to, how to respond to them and
which [sub] Screens to render at which times. (NOTE:, Screens
controllers are themselves the perfect place to handle events that are
specific to itself.)
Anyway, this is how I generally architect GUI applications (in all
widget toolkits.) Hope this helps... If not, I'd be glad to
elaborate further on specifics (This is a pretty short explanation.)
TL;DR
Application Controller(1)
Screen(1..N)
Screen Controller (1)
Screen View (1)
View Controller (0..N)
View Models (0..N)
Data Service Bus (1)
DataRepo (0..N)
IO (0..N)
On Wed, Jul 11, 2012 at 1:20 AM, totty <webdesignpo...@gmail.com> wrote:
> >From the turorials I've seen in the qooxdoo website I come to this
> conclusion:
>
> The main *Application.js* file is like a controller (in MVC) but also a
> view: *controller because listen on the view and "model"* (in this case a
> service) | and a *view because adds widgets to the screen*.
> (https://github.com/qooxdoo/qooxdoo/blob/release_2_0_1/component/tutorials/twitter/step3/source/class/twitter/Application.js)
>
> Now I'm seeing myself doing this wrong because I don't really know how to
> separate things in a reusable, scalable and testable way. A good view should
> contain?:
>
> * *Validation*? Currently I have a "view" that has both qx.ui.form.Form()
> and qx.ui.form.validation.Manager().
> The question arises because one of the validation is async. As the *async
> validation uses a service* therefore I need to use a server callback, which
> is a service or a model in MVC. Then all this becomes more coupled than
> separated.
> Maybe I should be *firing an event* and do the *server call outside the
> view*? (in it's controller?)
>
> * *Tables*... I also have a view that contains a table, *instances a model
> and have a listener on the model*. (It's a remote model,
> qx.ui.table.model.Remote). In this case I don't really have a solution.
>
> Maybe I should have a *custom controller for each view*? therefore I would
> be tempted to use a factory in order to create each view so I could abstract
> away the view-controller at instancing.
>
> I also found myself of using a *"main manager" to act quite like a
> controller but on multiple views* because one change in a view have an
> impact on the other. This *act quite like Application.js but it's not a
> graphical item*, just a simple class that get as input 4-5 views and based
> on their events acts on them.
>
> I would really appreciate your help and suggestion in how to improve my
> code.
> *Thanks (:*
>
> --
> View this message in context:
> http://qooxdoo.678.n2.nabble.com/MVC-Qooxdoo-apps-question-tp7580606.html
> Sent from the qooxdoo mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> qooxdoo-devel mailing list
> qooxdoo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
