PDA

View Full Version : Transfer widget values to model instance - conceptual question



TheBerliner
21 Sep 2009, 12:39 AM
Hello Ext experts,

coming from the pure o-o MVC paradigm, I am currently implementing the transfer of widget values to my model objets in my first Ext JS project.

It seems that in Ext JS the transfer of a value entered by the user in some widget happens only via one some event and the function, which is bound to this event (like: change: or blur: etc).

Obviously, it would make sense to have this handled by one central and generic dispatcher function, which receives the call upon the event and transfers to widget's value to the related model instance.

So far so bad, because how should this one central and generic function determine the model instance? I don't see a good chance for that, especially if there are several instances of the same model class.

My question:

Is it possible to bind some model attribute (instance variable) directly to some widget so that they communicate any change bi-directionally and automatically, i.e. a change to the model changes the view and change in the view [= entry] changes the model.

This is what nornally happens in MVC systems and it's most convenient, because there is no need to write explicit transfer code for every widget and instVar (which will become very big and cumbersome). Also, the instVar setter method then does the value validation for the widget, which keeps the app logic where it belongs and that is in the model.

Please note that in my second release there will be plenty of danamically generated widgets representing insrVars from many instances of several model classes. This makes a direct MVC-like binding even more desirable.

I found no such subject in the doc or in the turorials.

Thank you for your comments and hints

danh2000
21 Sep 2009, 1:03 AM
So what is your model? a subclass of Observable? a Record?

TheBerliner
21 Sep 2009, 1:43 AM
So what is your model? a subclass of Observable? a Record?
Oh no! Observables, widgets etc are views (in MVC terms). A widget is never a model!

There are model classes like page, catalog, user, order, product etc. each of which has or can have several or many instances. Often, selecting one model instance transfers its values to the views (widgets) and changing the widget(s) transfers the entered values to the related model instance.

This is why in a MVC system instance and widget are normally bound to one another (often through some special intermediate instance but that is an implementation detail).

I know that Ext is not an MVC system but it would still make sense for me to be able to implement this welll-proven paradigm as closely as possible and to avoid much useless and redundant code.

danh2000
21 Sep 2009, 3:03 PM
So you don't want help then!

TheBerliner
22 Sep 2009, 1:16 AM
So you don't want help then!
Could you please let me know what gave you this false impression?

danh2000
22 Sep 2009, 4:03 AM
Could you please let me know what gave you this false impression?

The following response gave me that impression, you asked for help then ranted on as if you knew it all:


Oh no! Observables, widgets etc are views (in MVC terms). A widget is never a model!

There are model classes like page, catalog, user, order, product etc. each of which has or can have several or many instances. Often, selecting one model instance transfers its values to the views (widgets) and changing the widget(s) transfers the entered values to the related model instance.

This is why in a MVC system instance and widget are normally bound to one another (often through some special intermediate instance but that is an implementation detail).

I know that Ext is not an MVC system but it would still make sense for me to be able to implement this welll-proven paradigm as closely as possible and to avoid much useless and redundant code.

You mistakenly think that Record and Observable are widgets? They are not.

I'm well aware of what a model is in terms of the design pattern, I was enquiring as to what your models were implemented as so I could offer some advice, but like on every one of your posts you take a 'know it all attitude'.

That's where I got the false impression.

I wasn't subscrived to this thread, I saw you reference it again from another post (you know the one), so to put this into context and to re-iterate what I said in the other post:


I asked if your models were Records or subclasses of Observable - neither of which can be considered widgets.

A widget is an element of a GUI - it's part of the interface.

Both Record and Observable subclass JavaScript's native Object - they are lightweight and ideal for encapsulating domain data.

In MVC, M stands for model - models encapsulate domain data.

Lesson over - I will not waste my time educating you further.

TheBerliner
22 Sep 2009, 4:13 AM
Just to inform the other readers:

Danh2000 published a private message from me to him without my consent. See this very unpleasent thread (http://www.extjs.com/forum/showthread.php?p=389024#post389024). Because of this and his permanent personal allegations I put him on my ignore list (as the first ever).

However, he is not giving any explanations, only excuses, as he obviously does not understand the MVC paradigm (see his question above if Observables, super class of most views, widgets and forms, were models, that is ridiculous).

Still, I'd be very interested if anybody could explain how to bind Ext views to model instances.

hendricd
22 Sep 2009, 5:10 AM
@TheBerliner --

Clearly, you have a seasoned grasp of the concepts relating to 'MVC'. Why brow-beat yourself (and other Forum contributors) over the head with that fact?

Take the bits and pieces from the community you think apply to your still-evolving understanding of the Ext framework and press-on, without unnecessary reflection.

Armed with that, write us all an M-V-binding you are proud of. :-?

Rant out of the way now, understand that Ext lives in a purely event-based engine (browser, AIR, etc). util.Observable (in conjunction with the DOM event system) is a mere acknowledgement of that fact -- which is why it is a popular base class for both Data and UI classes.

Thus, Observable (or a well-designed subclass) might be an ideal candidate for the binding you seek.

There have been some recent enhancements to Observable (ie. class-level listeners) that may prove interesting from a binding standpoint. (Search the Forums for more chatter on that).

Your statement, as it relates to Ext's design:

This is what nornally happens in MVC systems and it's most convenient, because there is no need to write explicit transfer code for every widget and instVar (which will become very big and cumbersome). Also, the instVar setter method then does the value validation for the widget, which keeps the app logic where it belongs and that is in the model.puzzles me somewhat (the role of Controller vs Model for App logic may create some head-scratching for you), but I will not debate what is clearly your choice.

But know that data.Record and data.Store (collectively, the model) and eg. GridView (a View) are packed with all the necessary Observable events and already perform the traditional Model-View binding (for that scenario).

What you might want to reconsider are the merits of Record->Form->posting vs Edit-Record->Store->CRUD. As of Ext 3, (thanks to the data.Writer and Ext.Direct), I've completely abandonded the Form posting 'BS' and now let the Store handle all (full CRUD) the server-side interaction. In the end (IMO), that approach makes your final MVC design extensible, and its behavior more predictable.

Enuf said, for now. Good Luck.

TheBerliner
22 Sep 2009, 6:20 AM
First of all, Doug, thank you very much for your very valuable comments and thoughts. I am grateful although or rather because you have raised more questions than answered. That is perfectly fine.

Second, let me state that I can't see any difference or dispute between "event driven" and MVC. The 'Cs' in the MVC tools that I have been using were all listening to events from the 'Vs' to process data to the 'Ms' and vice versa. So I can't see any reason why this shouldn't be possible with Ext either, but, of course, being still new to Ext JS I can well be wrong and this is why I made this post.

On the other side, what seems the general practise (again, I can well be wrong) of handling this via explicit handlers and listerners seems quite cumbersome to me, it seems not or little generic and thus causing plenty of redundant code. And this is what I always try to avoid.

Just a few comments.


Why brow-beat yourself (and other Forum contributors) over the head with that fact?
Does that mean blaming me for answering the question what MVC means?


Take the bits and pieces from the community you think apply to your still-evolving understanding of the Ext framework and press-on, without unnecessary reflection.
Well, my life experiance told me to first switch on my brain before implementing some first unreflected ideas. Not always good, but mostly.


Rant out of the way now, understand that Ext lives in a purely event-based engine
Sure, but see above, where and why should this mean any hindrance? I can't see it. "Event driven" is one feature of (not only) an o-o design but not per se an alternative, in my view.


But know that data.Record and data.Store (collectively, the model) and eg. GridView (a View) are packed with all the necessary Observable events and already perform the traditional Model-View binding (for that scenario).
If that is the case, then this is the central answer to my post. Thank you for now but please allow me to be still sceptical although this can be the case, because I don't yet clearly see the whole picture and also because I wouln't call Record or Store to be "real" models. At best, they are value holders to feed to 'Vs'. Definetely they don't have and shouldn't have either any app domain knowledge and that is the primary role of the 'Ms' in life.

Somehow I am missing the 'Cs', which are primarily in charge of administrating the UI and its behaviour on a broader scale.


...Record->Form->posting....I...now let the Store handle all (full CRUD) the server-side interaction
If I understand this correctly, this means that data flows essentially from the widgets (raw entry) via the Store directly into the DB bypassing any domain model, which are not involved any more and which could check the syntactical and semantical correctness of the data?

Well, this may work for some apps with simple or little data but I doubt that this can be a solution in data-heavy apps, especially since the Ext widgets essentially lack any detailed value checking inside the UI, except via separate validation functions but this is and should remain the home-turf of the 'Ms' and this should not lead to distributed logic.

Perhaps my concerns become more understanble if I mention that all of my domain models (in Smalltalk) are purely data driven and can therefore vary substantially depending on version, configuration and admin/user selections. This should or rather must be reflected, of course, by the related Ext UI or rather by the Ext UI, which should be generated (in a 2nd or 3rd release) from these domain model data definitions. I don't see the two worlds isolated fron one another also because Smalltalk will generate the Ext UI from its data and domain knowledge.

Ok, I will think about this with your input and, if successful, perhaps add some thoughts and comments later on.

hendricd
22 Sep 2009, 7:19 AM
Does that mean blaming me for answering the question what MVC means?
Not blaming you. Just don't see anywhere that anyone actually asked you that question. Just chalk it up to 'cultural differences' I suppose. ;)



Well, my life experiance told me to first switch on my brain before implementing some first unreflected ideas. Not always good, but mostly.
The intent there was to remind you just how unproductive all this 'SmallTalkOO vs Javascript-prototype-inheritance' bashing (from other Berliner threads) actually is in the grand scheme of things. Let's just acknowledge the differences and move on.



If that is the case, then this is the central answer to my post. Thank you for now but please allow me to be still sceptical although this can be the case, because I don't yet clearly see the whole picture and also because I wouln't call Record or Store to be "real" models. At best, they are value holders to feed to 'Vs'. Definetely they don't have and shouldn't have either any app domain knowledge and that is the primary role of the 'Ms' in life.

Somehow I am missing the 'Cs', which are primarily in charge of administrating the UI and its behaviour on a broader scale.

If I understand this correctly, this means that data flows essentially from the widgets (raw entry) via the Store directly into the DB bypassing any domain model, which are not involved any more and which could check the syntactical and semantical correctness of the data?


I believe, there lies the mixup in interpretation of Ext's overall class design. The lines are not clearly drawn.
As you may have noticed, there is no formal (even abstract) class heirarchy that implies M vs V vs C. The best I could attempt in delineating two examples of them for Ext:

M = Record/Store
V = GridView/RowEditor/Forms, etc

But, C is something that you (using the myriad events and callbacks from the M & V) must derive on your own, including a domain-model of your choosing. Ext already uses that 'pattern' for what you could call M<->V internally (including those 'separate validation functions' you are now aware of). Making a 'formal C' - is your job using the same approach.

Longer-term, you'll need to decide whether it's best to handle 'Model-integrity' (IMO currently View-weighted by Ext) by your Controller or the Model itself (using the provided Record/Store events/callbacks as well) or just let the rear-end do it all/some (likely needs to anyhow).

You have much flexibility, and Observables provide the necessary plumbing for success. :>

TheBerliner
22 Sep 2009, 7:58 AM
Doug,

again thank you very much for essentially confirming my thoughts that I learned from your last post and while replying to it.

Actually, my impression and opinion of the Ext design seems to be a bit better that what you stated:

I believe, there lies the mixup in interpretation of Ext's overall class design. The lines are not clearly drawn.
As you may have noticed, there is no formal (even abstract) class heirarchy that implies M vs V vs C.
because I think that under the given circumstances (no real o-o language, not even a minimal basic class lib, no extendable Object class) the Ext people have done an excellent design job (as far as I can judge with my still quite "infantile" JS knowledge).


But, C is something that you ....must derive on your own
That is the core message! And again thank you very much for confirming this, because this really answers my original question in two aspects:
a) Yes, it does make sense to implement Cs
b) There is nothing else already in use that I overlooked, which usually does play this role in bigger Ext apps

Before telling my next thought, I have first to state that my Smalltalk class lib (over 30 men years) consists of a fairly well-designed and implemented and quite big tree of controller classes, which automatically communicate with the domain-models and with the views. They even generate major parts of the views from the domain models (or rather their data definitions).

Now this is my idea and question to you as an (obviously) Ext expert with solid architectural knowledge: Would you consider it reasonable and promising to try to develop such a general controller class tree in close co-operation with a few other experianced Ext users in order to have several influences, ideas, experiences etc contributed to it?

And would you expect to find a good one or two handful of people who were interested in such an undertaking?

(My impression has been so far that "software architects" and o-o developers are rather a small minority among Ext user, and I still hope to be proven wrong).

I think it would make a lot more sense to develop this as a generic project in parallel to Ext rather than completely on my own. Of course, this is more a long term project and no simple job either but I think the availability of such controller classes is a prerequisite for larger and data-heavy Ext apps in general. If I had my Smalltalk to JS translation plans already working, I could quickly contribute a lot but that is not yet the case and it will most likely take another year or so till it's really ready for production use.

hendricd
23 Sep 2009, 5:03 AM
...Would you consider it reasonable and promising to try to develop such a general controller class tree in close co-operation with a few other experianced Ext users in order to have several influences, ideas, experiences etc contributed to it?

And would you expect to find a good one or two handful of people who were interested in such an undertaking?

(My impression has been so far that "software architects" and o-o developers are rather a small minority among Ext user, and I still hope to be proven wrong).

I think it would make a lot more sense to develop this as a generic project in parallel to Ext rather than completely on my own. Of course, this is more a long term project and no simple job either but I think the availability of such controller classes is a prerequisite for larger and data-heavy Ext apps in general....

Hmm.. :-?
Sounds like a candidate for something 'Designer-like' in nature (but with extensive modeling capabilities). Let's chew on that notion a bit more....

TheBerliner
23 Sep 2009, 5:38 AM
Hmm.. :-?
Sounds like a candidate for something 'Designer-like' in nature (but with extensive modeling capabilities). Let's chew on that notion a bit more....
No, not really designer-like, because the Smalltalk apps won't provide generic interface building capabilities. Instead, the generated UI merely complements the desk-top products whose data the JS app brings onto the Internet as kind of a second Internet view.

Only in the long-run I intend to enhance my database-publishing software, which is currently focussed on DTP/paper, to also generate JS and AS3 interfaces, but this will be focussed on publishing database content rather than providing typical UI building capabilities (only menus and actions bound to content).

And good appetite when chewing...:))

hendricd
23 Sep 2009, 5:41 AM
Who said it had to be based on a Smalltalk framework ? ;)

TheBerliner
23 Sep 2009, 5:54 AM
Who said it had to be based on a Smalltalk framework ? ;)
Not the JS controllers, of course, I meant the JS code that my apps are to generate just to show that this is different from what the Ext designer project will do (AFAIK).

TheBerliner
21 Nov 2009, 10:51 PM
Doug,

to keep you posted:

I just started to develop my first little set of controller classes in JS for Ext similar to what was done in Smalltalk. I am using Joose as this seems the only way to develop an o-o system in JS and anything else is Spaghetti or Maccaroni at best and both are not for me (except on a plate :)).

Seems that there is no interest in controller classes within the JS community. There is with me and thus I just started to go this presumably quite long way.

I am curious about the experiances ahead of me and I will occaisionally report them.

Regards