Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Recommended Approach for Referencing ISC Objects

    Hello,

    We're in the midst of developing a fairly complex web application using SmartClient and are hoping for a recommendation from Isomorphic regarding best practice for referencing objects within our application. For example, when working with a tabset, we frequently need access to the tabset or a tab within the tabset from within one of the various panes, or from a control nested within a pane. One approach we have been using is to assign an object reference to the tabset at its creation using a variable, and then use that variable to further assign an object reference during the subsequent creation of other elements, such as the pane of a tab, or a listgrid within a pane, etc. Then we can just use something like this.myTabSet.doSomething() from within an event handler later on in order to call a custom method on the tabset.

    One reason this works well for us is that a lot of our UI objects are dynamically created from base custom classes and the ID's aren't set until runtime. Also many of our custom UI classes can exist in multiple concurrent instances. That said, we do realize that we could refactor and use the IDs if that were the recommended approach. Something along the lines of "window[this.myTabsetID]" in order to gain a reference to the tabset such as in the proceeding example.

    So - our question is: Does Isomorphic have a specific recommendation regarding using direct object references versus passing IDs around? We're wondering if there are any concerns regarding memory leakage with direct references versus using IDs? Is the SmartClient framework providing any additional functionality if we used IDs that we're miss out on by using direct object references?

    Thanks for the help!

    Philip

    #2
    Take a look at this example of a custom component - the parent component uses object references to track subcomponents.

    The AutoChildren subsystem neatly encapsulates this pattern and eliminates boilerplate code.

    If you end up in a scenario where you seem to require passing global IDs around, you may just not have thought through the best encapsulation approach. For example, when building an application, we typically make a SmartClient class representing the application as a whole. This means multiple instances of the application could be created if that is ever needed (for example, a single superuser needing to log in as multiple other users..) and it can be embedded inside a larger application.

    Separately, it's a good idea to assign at least a few IDs for Automated Testing (see the overview) - but this is totally distinct from inter-references between your components, which generally should not require global IDs.

    Comment


      #3
      Exactly what we were looking for. Thanks very much!

      Comment

      Working...
      X