1. #1
    Sencha User
    Join Date
    Sep 2011
    Posts
    13
    Vote Rating
    4
    thefugal is on a distinguished road

      1  

    Default Unanswered: Executing initialization code before stores autoLoad?

    Unanswered: Executing initialization code before stores autoLoad?


    The project that I am working on requires a sort of handshake procedure with the server before API calls can be made. I was intending to do this initialization in application#launch, but ran into a problem with stores where autoLoad is set to true. In this case, the stores are created and autoloaded before launch is called. I get the same behavior when I move the initialization code into a controller#init method as well. I can't seem to find a hook into the application lifecycle that allows me to execute my initialization code before the stores autoload themselves.

    Is this not a use case that is supported?

    At the moment, it seems like I only have three options:
    - Override the store autoloading private method to call out to some singleton controlling the connection state, check the state, and initialize if necessary
    - Override private methods within the application itself to give me the hook I need, or
    - Do my initialization code outside of Sencha Touch, before the application begins to load.

    Given that my intention is to turn this project into a user extension:

    - I don't really want to have to subclass store. It seems prone to problems when upgrading Sencha Touch, it feels inelegant, and it's a big pain to have to remember to extend that class rather than Ext.Store when creating a new store (the Ext.Store stores will work in all cases except autoLoad, which has the potential to lead to subtle, hard-to-track-down bugs). It would be MUCH better if the users of the user extension could just configure it one place and have everything Just Work, rather than needing to subclass this special store over and over.

    - I don't really want to have to override private methods in the application... That seems dangerous/unclean/inelegant/error-prone-during-version-upgrades. It has the advantage of being a bottlenecked, one-time change for users, but I myself would be reluctant to install a user extension with this requirement.

    - I have a natural aversion to just throwing some globals onto the window, but it seems like the lesser of these evils.

    Is there a better solution that I am missing? Is there a good reason why Sencha Touch is making it so hard for me to execute code before the stores load?

    Thanks!

  2. #2
    Sencha User
    Join Date
    May 2012
    Posts
    16
    Answers
    2
    Vote Rating
    0
    spky is on a distinguished road

      0  

  3. #3
    Sencha User
    Join Date
    Sep 2011
    Posts
    13
    Vote Rating
    4
    thefugal is on a distinguished road

      1  

    Default


    @spky: thanks for the pointer, but I do not think that solves my problem

    In order to leverage the beforeload event to solve this problem, I think that either:
    a) the user would have to instantiate every single store with something like
    Code:
    listeners: {
        beforeload: Ux.blah.initializeConnectionIfNecessary
    }
    or
    b) subclass Ext.Store to have that listener automatically applied

    Not really any functional difference from the solution of subclassing Ext.Store to augment the autoloading code, except that in the beforeload strategy, the check gets performed on every single store load as opposed to just the autoloads.

    Either way, I still require the user to do something special every time they create a store (and if they don't risk subtle bugs). In my opinion, it still shouldn't be the store's responsibility to conditionally initialize a connection -- that's something that I should be able to do exactly once, during the app's startup.

Thread Participants: 1

Tags for this Thread