Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: How to successfuly implement views on MVC application

  1. #1

    Default How to successfuly implement views on MVC application

    Hi all,

    I have a question regarding Views in MVC application.

    According to documentation i have declared the principal views on the app.js file, and when I want to push a new view I use Ext.create('my.view.Class').

    Everything is ok at that moment, but when I want to involve the Controller in the functionality everything behaves weird.

    In my Controller i am capturing references of my view's items, either by id '#' , by xtype or by a query that retrieves my component.

    The problem comes when I glue all of this in a navigator view, where my views are popped and pushed constantly. The controller references seem to refer to the first instance of my view items (the first time they get pushed), and any new created views doesn't get refered (after i pop and push again the same view class object). This becomes a huge problem specially on forms retaining old view values instead of the actual ones, or on dynamic logic on my views from the controller.

    I can somewhat overcome this by saving the view on a controller property, and then reusing the component. However I believe this retains the object memory and should be avoided.

    Am I doing things wrong? Any comment will be appreciated

    I am pushing views as this:

    Code:
    var loginScreen = Ext.create('app.view.streaming.Login');
            this.getMainNav().push(loginScreen);

  2. #2
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,379
    Answers
    3997

    Default

    The ref should be emptied when the associated view gets destroyed. Remember, the events are fired with a view usually as the first argument and navigating up or down to get a view you actually want is a possibility, this would be flexible.
    Mitchell Simoens @LikelyMitch

    Check out my GitHub:
    https://github.com/mitchellsimoens

    Posts are my own, not any current, past or future employer's.

  3. #3

    Default

    Thanks,

    But how can I empty the reference so that it 'catches' the new view reference?

  4. #4
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,379
    Answers
    3997

    Default

    When the view cache in the ref is destroyed, it should remove the ref automatically.
    Mitchell Simoens @LikelyMitch

    Check out my GitHub:
    https://github.com/mitchellsimoens

    Posts are my own, not any current, past or future employer's.

  5. #5

    Thumbs up

    Oh ok, my problem was that i was overriding the destroy() method without calling the parent.

    Thank you for your help

  6. #6

    Exclamation

    Well it seems that my problem is not solved at all.

    I have one controller with a reference by id, which has an event based on 'painted':

    Code:
    config: {
            refs: {
                mainNav: '#mainNav',
                            
                videoPanel: '#videoPanel',
            },
            
            control: {
                videoPanel: {
                    painted: 'onShowVideo'
                }
            }
        },
    As I described before, the event is being called succesfully the first time a view instance is created, but on further creations the painted event is not called.

    I don't understand if the reference by Id works different. I tried using Ext.destroy without success on the views destroy method.

    I also tried using a query to make a reference to my panel but i can't find a way to do so without the #id. I've tried:

    by xtype: 'v-videoview panel'
    by name (adding a name on panel) 'v-videoview panel[name='videoPanel']
    using selectors, etc

    The painted event is never fired unless I use #id tag.

    What can I do?

  7. #7

    Default

    The same problem. In controller I use:
    Code:
    control: {
         '#id_of_main_component_of_some.View': {
             painted: 'onPaint'
         },
         '#id_of_main_component_of_some.View list': {
             itemtap: 'onItemTap'
         }
    }
    The following code
    Code:
         nav.push( Ext.create('some.View') );
         nav.pop();
         nav.push( Ext.create('some.View') );
    fires onPaint only first time. The same if I bind to 'activate' or 'initialize' events. If I bind to these within the View itself - they are fired correctly, however controller doesn't rebind to them in case if view is reinstantiated. onItemTap fires well though

  8. #8
    Sencha User
    Join Date
    Oct 2011
    Location
    Vancouver, Canada
    Posts
    157
    Answers
    5

    Default

    In real MVP (Sencha uses MVP-Supervising Controller but calls in MVC), there is one Controller instance per View instance.

    Sencha bizarrely* uses one Controller instance of a given type, and you can have many View instances that it listens to.

    It is possible, though a bit of a PITA to make it work correctly. It is probably worthwhile for a bigger app, that can have multiple instances of views of the same type.

    Basically, you avoid using application.getController(), and you create and destroy a controller from its view. You can still use .control() to listen to the view, but need to declare it differently to listen to a particular view instance and not all views of that type.


    * I have found four major flaws in ExtJS4 so far:

    1. trying to say datafield.convert() is a getter, when it is really a setter that returns a value (bizarro). why not just provide getters?
    2. having Ext.History fire change event when you call add - this f's up navigation and is the opposite of what HTML5 history.pushState() does.
    3. having a field call change event when you call setValue() - it shouldn't. This f's up 2-way form data binding. This behavior was not in javascript/dom for a reason.
    4. having single-instance controllers, when they should be one instance per view.

  9. #9
    Sencha Premium User bluehipy's Avatar
    Join Date
    Mar 2010
    Location
    Romania
    Posts
    628
    Answers
    67

    Default

    @el_chief Maybe there are places where you missed sencha's architects intentions. There are no "should be" 's, I guess.

    Ext.app.History is a private utility and was meant to be used as they needed it:
    "Manages the stack of Ext.app.Action instances that have been decoded, pushes new urls into the browser's location object and listens for changes in url, firing the change event when a change is detected.This is tied to an Application instance. The Application performs all of the interactions with the History object, no additional integration should be required.". For navigation from one chapter to another just use the framework tool: routing, don't use directly the private history utility.


    For a Ext.field.Field instance, 'value' is just another property on an Ext.Evented object, so it obeys the same rules as the rest of the properties. Changing its value will trigger a 'change' event. However if oyu want to change a value of any property without raising a change event you can suspendEvents and resumeEvents.


    Having single instances of controllers for many views of the same type I would call optimization. Why should it be one per view? It's just a different approach, not a bad way.



    My novice opinions

  10. #10
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,379
    Answers
    3997

    Default

    Quote Originally Posted by bluehipy View Post
    Having single instances of controllers for many views of the same type I would call optimization. Why should it be one per view? It's just a different approach, not a bad way.
    I would back this up. Having 20 views that could be listened to by say one or two controllers is a lot better on memory than having 20 controllers. We have a global event bus that handles this.

    I'm not seeing any datefield.convert()
    Mitchell Simoens @LikelyMitch

    Check out my GitHub:
    https://github.com/mitchellsimoens

    Posts are my own, not any current, past or future employer's.

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •