1. #1
    Ext User TheBerliner's Avatar
    Join Date
    Apr 2009
    Posts
    226
    Vote Rating
    0
    TheBerliner is on a distinguished road

      0  

    Default Transfer widget values to model instance - conceptual question

    Transfer widget values to model instance - conceptual question


    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
     

  2. #2
    Ext JS Premium Member
    Join Date
    May 2007
    Posts
    698
    Vote Rating
    3
    danh2000 is on a distinguished road

      0  

    Default


    So what is your model? a subclass of Observable? a Record?

  3. #3
    Ext User TheBerliner's Avatar
    Join Date
    Apr 2009
    Posts
    226
    Vote Rating
    0
    TheBerliner is on a distinguished road

      0  

    Default


    Quote Originally Posted by danh2000 View Post
    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.
     

  4. #4
    Ext JS Premium Member
    Join Date
    May 2007
    Posts
    698
    Vote Rating
    3
    danh2000 is on a distinguished road

      0  

    Default


    So you don't want help then!

  5. #5
    Ext User TheBerliner's Avatar
    Join Date
    Apr 2009
    Posts
    226
    Vote Rating
    0
    TheBerliner is on a distinguished road

      0  

    Default


    Quote Originally Posted by danh2000 View Post
    So you don't want help then!
    Could you please let me know what gave you this false impression?
     

  6. #6
    Ext JS Premium Member
    Join Date
    May 2007
    Posts
    698
    Vote Rating
    3
    danh2000 is on a distinguished road

      0  

    Default


    Quote Originally Posted by TheBerliner View Post
    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:

    Quote Originally Posted by TheBerliner View Post
    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.

  7. #7
    Ext User TheBerliner's Avatar
    Join Date
    Apr 2009
    Posts
    226
    Vote Rating
    0
    TheBerliner is on a distinguished road

      0  

    Default


    Just to inform the other readers:

    Danh2000 published a private message from me to him without my consent. See this very unpleasent thread. 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.
     

  8. #8
    Sencha - Community Support Team hendricd's Avatar
    Join Date
    Aug 2007
    Location
    Long Island, NY USA
    Posts
    5,963
    Vote Rating
    10
    hendricd will become famous soon enough hendricd will become famous soon enough

      0  

    Default


    @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.
    "be dom-ready..."
    Doug Hendricks

    Maintaining ux: ManagedIFrame, MIF2 (FAQ, Wiki), ux.Media/Flash, AudioEvents, ux.Chart[Fusion,OFC,amChart], ext-basex.js/$JIT, Documentation Site.


    Got Sencha licensing questions? Find out more here.


  9. #9
    Ext User TheBerliner's Avatar
    Join Date
    Apr 2009
    Posts
    226
    Vote Rating
    0
    TheBerliner is on a distinguished road

      0  

    Default


    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.

    Quote Originally Posted by hendricd View Post
    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?

    Quote Originally Posted by hendricd View Post
    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.

    Quote Originally Posted by hendricd View Post
    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.

    Quote Originally Posted by hendricd View Post
    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.

    Quote Originally Posted by hendricd View Post
    ...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.
     

  10. #10
    Sencha - Community Support Team hendricd's Avatar
    Join Date
    Aug 2007
    Location
    Long Island, NY USA
    Posts
    5,963
    Vote Rating
    10
    hendricd will become famous soon enough hendricd will become famous soon enough

      0  

    Default


    Quote Originally Posted by TheBerliner View Post
    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.

    Quote Originally Posted by TheBerliner View Post
    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.

    Quote Originally Posted by TheBerliner View Post
    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.
    "be dom-ready..."
    Doug Hendricks

    Maintaining ux: ManagedIFrame, MIF2 (FAQ, Wiki), ux.Media/Flash, AudioEvents, ux.Chart[Fusion,OFC,amChart], ext-basex.js/$JIT, Documentation Site.


    Got Sencha licensing questions? Find out more here.


Thread Participants: 2