Results 1 to 3 of 3

Thread: question on Application architecture

  1. #1
    Ext JS Premium Member
    Join Date
    Jun 2009

    Default question on Application architecture

    Hi. I am new to ExtJs, and I need help with an issue relating to
    overall application design and architecture. I am sorry that this post will be
    rather long, but I need to explain what I am trying to achieve, in order to
    hope that I can get meaningful answers. It may also serve as the staring
    point of an interesting discussion. If all I am saying here is commonplace to
    you experts, please allow for the fact that I only came across ExtJS a couple
    of days ago also, pls note that English is not my mother tongue.

    I am designing a pure AJAX largish (30-50 "pages") application,
    which I would like to function in the following way:

    I want to have a single html page, which acts as the "container" for the
    application. the layout should be the typical application-style :
    a "west" panel containing a static tree menu, a "north" panel for banner,title
    and toolbars (variable), and a "center" panel which hosts the actual content.

    within the center panel I do not need (nor wish to) have multiple "pages" active
    at any one time. The idea is that the user clicks options on the left menu,and
    the center panel changes to show the relevant sub-page. Think of an old-style
    frameset, with the left-side <A>'s having the main frame as target, and you
    have the exact navigation functionality I wish. back-and-forward actions are
    handled by the application, not the browser buttons (for now).

    Before discovering ExtJS a couple of days ago, I was planning to achieve this
    using either good-ole framesets, or a single page with a single IFRAME for the
    "center" region. I was also using jQuery for DOM manipulation and AJAX calls,
    and a pure JSON data layer, served by PHP. I run into various issues with jQuery
    visual components (the core is ok, but the components suck IMHO),and started looking
    around. I found extJS and it was love at first sight. Ok, it is quite diffcult to
    "get", the learning curve is huge, and the lack of a proper Programming Guide
    (as opposed to the excellent Reference Guide) is a serious issue. Still, the
    power of it is significant motivation for me to spend a lot of time on it!

    (btw, is there any material anywhere, free or otherwise, that describes the
    architectural concepts of ExtJS in some depth, like object/component model, layouts,
    inheritance, life-cycle management, instance/ownership/garbage collection for components,etc ?)

    After playing some time with the basic examples, I tried to implement my initial
    design pattern, using an IFRAME hosted in a PANEL, which was hosted in a TABPANEL
    which was hosted in a BORDER layout viewport.
    (I used tabpanel because I dont know any better yet. My design does not need a tabPanel
    for center, just a simple panel, I guess). This worked as expected, after some fiddling,
    and I was very happy to see that the BORDER layout manages the 100% width/height issues
    perfectly, something which has been bugging me in html for years now.

    However, while playing with the samples, I realized that there was a different approach
    to using an IFRAME, which I feel has signigicant advantages:

    use a simple container element (the inner child panel I am using is ok for this),
    and, every time the user clicks on a selection, load HTML dynamically into the element,
    usign the element.getUpdater().update() technique. I had never considered this technique before,
    because I needed scripts to be local to the sub-pages (the ones dynamically loaded),
    and I did not realize before that Ajax calls can evaluate embedded scripts...

    What I see as a HUGE advantage in this approach, is that the HTML "fragments" loaded
    into the (single) panel do not need and in fact should not be complete stand-alone
    html pages. in particular, all the Extjs setup code (stylesheets, scripts, any other of
    my libraries) does not need to be in probably should NOT be included in the "sub-page".

    Why is this an advantage ? because it gives a huge performance boost, since the run-time
    environment is in fact fetched and compiled only once. by the same token, I now have
    a perfect location to manage application-wide, client-side state, since the container
    page is loaded only once. (I was expecting to do this via cross-frame calls in my old
    design, a practice best avoided if possible).

    OK, now come the bad news. since each sub-page gets loaded and parsed in the same,
    static environment, the issue of namespace conflicts and memory leaks arises, I believe.
    spefifically, what happens if page 1 contains a DIV with id "div1", and page 2 also
    contains the same id ? I suspect that if I dont do anything about it, I end up with a document
    having duplicate id's and you know what that means... Also, any functions contained in
    a SCRIPT tag on page 1, will probably (and do) persist when page 2 is loaded.

    When using IFRAMES or FRAMES, this issue does not arise, as each page runs in its own
    namespace and sandbox.

    I tried to address this issue by having the container page manage creation/destruction
    of components, using code such as this:

    <container page> :
    function loadContent(aUrl)
    var tab=Ext.getCmp('tab1');
    if (tab.items) tab.removeAll(true); <-- test needed, because ITEMS does not exist by default
    var upd=tab.getUpdater();

    function button1click(b,e)
    </container page>

    where 'tab1' is a plain PANEL which is child to the center TABPANEL

    <sub-page sample>
    ... component creation code,
    ... important : no calls to Ext.OnReady(), since the event will not fire anyway...

    ...for each new top-level component do this:
    var tb1=Ext.getCmp('tab1');
    tb1.add(newComponent); // add this to container collection


    I figured that, if the component/object model is anything like what I am used
    from other environments, the garbage collection/memory management will be taken
    care of by the container component, (not automatically, it seems, thus the
    call to component.removeAll() in the container code)

    so, finally, my questions:

    *. is this design pattern I am trying to use here a valid and even desirable one,
    or should I use another approach, and if so, which one, given the specifications
    I described initially (singleton center area)?

    *. is the way I found to manage creation/destruction of components the "proper"
    and recommended way, is there a better/easier way, am I violating any
    design/impementation rules of ExtJS ? is there a way that avoids having to
    manually add the sub-page components to the container, a practice best left to
    a framework and not to each individual page ? (for this discussion, I consider the
    singleton main page as part of the application "framework")

    *. would "namespaces" and "scope" help in any way augment my implementation ?

    *. any other comments you wish to make on my approach ?

    ok, that's it folks! a rather long message, I am afraid. I hope I am not boring
    the h* out of you...

    Thanks, Mike

  2. #2
    Sencha - Community Support Team jsakalos's Avatar
    Join Date
    Apr 2007


    Let's try to break it to pieces and take questions one by one:

    1. iframe vs panel load - it depends what better suits you. You can even combine them. Some (simpler) subpages can be loaded, more complex ones or from other domain can be in iframe. Take a look at ManagedIframe user extension.

    Have you seen my examples? They're tree on the left and ifram in the center.
    Jozef Sakalos, aka Saki

    Education, extensions and services for developers at new
    News: Grid MultiSearch Plugin, Grid MultiSort Plugin, Configuring ViewModel Hierarchy

  3. #3
    Ext JS Premium Member
    Join Date
    Jun 2009


    Thanks for the pointer, I will look into managedIframe. otoh, I never doubted that the tree/iframe combination would work just fine, I have been using it fir years. it is the OTHER one I am worried about.

Posting Permissions

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