Loading ...
Sorry, an error occurred while loading the content.

Thick Client Architecture Question

Expand Messages
  • dayardman
    Pardon me if this question is out of place but I m currently using the yui library and had a question that I think the minds posting in this group might be
    Message 1 of 5 , Feb 1, 2007
    • 0 Attachment
      Pardon me if this question is out of place but I'm currently using the
      yui library and had a question that I think the minds posting in this
      group might be amongst the best around to answer.

      I have one of my applications setup in such a way that each screen of
      the application is loaded once when the user requests it into the
      browser into a div for each screen more or less. When the user
      requests a screen that is already loaded in the browser I simply hide
      the current one and show the requested one. I also have a bit of logic
      in places so that things like table grids automatically refresh
      themselves as necessary. This works fine but I'm concerned with
      performance and scalability going forward as I'm adding more and more
      screens everyday. My question is: Is this a wise approach, or are
      there better ways of doing this? My concern is that having all those
      divs in the browser end up weighing down the DOM making it slow to
      traverse or do things like visual effects even if most of the divs are
      hidden. All the event listeners floating around as well seem like a no-no.

      As I see it there are several alternatives, namely:

      1. Use one div. Load each screen into a js var as needed and place
      that html into the div and evaluate any loaded javascript. When
      switching between loaded screens simply remove all attached listeners,
      fill the div with the html in memory for the requested screen and
      add/re-attach listeners. The big pro of this is that it seems to me
      storing each screen in a js object or array is easy and not as heavy
      as keeping it in the DOM. My problem with this approach is that
      switching out the innerHTML of a div doesn't always work the way you
      want it to, the screen doesn't seem to keep the same state it was in
      when you switched it out.

      2. Use iframes for each screen. So instead of multiple divs do
      multiple iframes. I say this because I think each iframe holds its own
      DOM space and doesn't weigh down the DOM of the parent page (?). The
      only thing in the parent page would be a bunch of iframes which
      doesn't seem so bad to me. If I do a visual effect in an iframe the
      tons of markup existing in all the other iframes wouldn't affect it.
      The cons of this approach are that I would have to load my js
      libraries again in each iframe and I'm not sure if iframes really make
      a difference in terms of adding to the slowness of the page.

      I've thought of other alternatives but those are the two that stick
      out. What do you guys think? Any advice would be appreciated based on
      your experience and knowledge of browsers, the DOM, et al. My main
      concern is responsiveness or the appearance thereof. I'm tired of
      building applications that you have to click and wait. It seems
      complete and utter common sense to me to load screens once and only
      send and retrieve data as necessary instead of getting entire pages
      over and over again. Some of the things I'm doing are for the
      government where network speeds sometimes come to a crawl and the
      fewer bytes I send over the wire the better. Please advise, I look
      forward to your responses.

      - Andrew
    • Eric Miraglia
      Andrew, There s no single, satisfactory answer to your question that would be correct for every application (IMHO). What we know from experience is that you
      Message 2 of 5 , Feb 3, 2007
      • 0 Attachment
        Andrew,

        There's no single, satisfactory answer to your question that would be correct for every application (IMHO).  What we know from experience is that you have a finite amount of DOM complexity to play with before browser performance begins to degrade.  Degradation happens sooner when there are script hooks attached to the DOM elements in a complex document.

        If your application naturally has different "screens", it seems to me that it runs more "with the grain" of in-browser programming to break those screens up as separate pages.  Where you have a single persistent interface that's long-lived (eg, like Yahoo! Mail or GMail, where the screen may be open in the browser all day long), be vigilant about destroying DOM elements and JavaScript objects when you're done with them.

        Regards,
        Eric


        ______________________________________________
        Eric Miraglia
        Yahoo! User Interface Library



        On Feb 1, 2007, at 6:38 PM, dayardman wrote:

        Pardon me if this question is out of place but I'm currently using the
        yui library and had a question that I think the minds posting in this
        group might be amongst the best around to answer.

        I have one of my applications setup in such a way that each screen of
        the application is loaded once when the user requests it into the
        browser into a div for each screen more or less. When the user
        requests a screen that is already loaded in the browser I simply hide
        the current one and show the requested one. I also have a bit of logic
        in places so that things like table grids automatically refresh
        themselves as necessary. This works fine but I'm concerned with
        performance and scalability going forward as I'm adding more and more
        screens everyday. My question is: Is this a wise approach, or are
        there better ways of doing this? My concern is that having all those
        divs in the browser end up weighing down the DOM making it slow to
        traverse or do things like visual effects even if most of the divs are
        hidden. All the event listeners floating around as well seem like a no-no.

        As I see it there are several alternatives, namely:

        1. Use one div. Load each screen into a js var as needed and place
        that html into the div and evaluate any loaded javascript. When
        switching between loaded screens simply remove all attached listeners,
        fill the div with the html in memory for the requested screen and
        add/re-attach listeners. The big pro of this is that it seems to me
        storing each screen in a js object or array is easy and not as heavy
        as keeping it in the DOM. My problem with this approach is that
        switching out the innerHTML of a div doesn't always work the way you
        want it to, the screen doesn't seem to keep the same state it was in
        when you switched it out.

        2. Use iframes for each screen. So instead of multiple divs do
        multiple iframes. I say this because I think each iframe holds its own
        DOM space and doesn't weigh down the DOM of the parent page (?). The
        only thing in the parent page would be a bunch of iframes which
        doesn't seem so bad to me. If I do a visual effect in an iframe the
        tons of markup existing in all the other iframes wouldn't affect it.
        The cons of this approach are that I would have to load my js
        libraries again in each iframe and I'm not sure if iframes really make
        a difference in terms of adding to the slowness of the page.

        I've thought of other alternatives but those are the two that stick
        out. What do you guys think? Any advice would be appreciated based on
        your experience and knowledge of browsers, the DOM, et al. My main
        concern is responsiveness or the appearance thereof. I'm tired of
        building applications that you have to click and wait. It seems
        complete and utter common sense to me to load screens once and only
        send and retrieve data as necessary instead of getting entire pages
        over and over again. Some of the things I'm doing are for the
        government where network speeds sometimes come to a crawl and the
        fewer bytes I send over the wire the better. Please advise, I look
        forward to your responses.

        - Andrew


      • dayardman
        Thanks Eric, I guess I m looking for a silver bullet, as a developer I have to believe that they exist. I m primarily focusing this effort on 2 applications
        Message 3 of 5 , Feb 4, 2007
        • 0 Attachment
          Thanks Eric,

          I guess I'm looking for a silver bullet, as a developer I have to
          believe that they exist. I'm primarily focusing this effort on 2
          applications which do have naturally different screens. However,
          because of slow network connections and a need to differentiate myself
          from the pack I want these bad boys to be peppy and fast. I don't have
          the luxury of clustered server farms or super fast application
          servers. As such I'd like to load each screen just once from the
          server when they are requested from then on only load data as
          necessary which is really not that often and tends to be far quicker
          retrievals than loading entire pages.

          As you said there is a point where the browser's performance starts to
          degrade but I'm wondering if I can't mitigate that somehow. With Yahoo
          and Google Mail they seem to retrieve the entire page when viewing a
          message or switching between "pages" such as to contacts or to spam
          but in some cases such as switching back from contacts to inbox or
          marking a message as spam they do not but instead seem to keep the
          previous view in the browser and simply show it. I'd like to do that
          but more of it, I'm just not sure at what point degradation will start
          to occur.

          I've more or less decided to store each screen in its own div, created
          dynamically when first requested from the app. Switching between pages
          will hide or show the divs. I'll then do some tests to see how many I
          can hold in the browser before it starts to slow down or hog memory
          and set a limit based on that so that if a page is requested and I
          already have x number of pages stored I'll pop the oldest visited div
          and push the new page. I may even when switching between divs try to
          remove all listeners from the div and reattach them when you switch
          back to it. If you have any cautions with this approach please advise.

          Last question, as for destroying DOM elements and javascript objects
          when done with them, what's the cleanest way to do that?

          Again thanks for your reply, I appreciate it.

          - Andrew

          --- In ydn-javascript@yahoogroups.com, Eric Miraglia <miraglia@...> wrote:
          >
          > Andrew,
          >
          > There's no single, satisfactory answer to your question that would be
          > correct for every application (IMHO). What we know from experience
          > is that you have a finite amount of DOM complexity to play with
          > before browser performance begins to degrade. Degradation happens
          > sooner when there are script hooks attached to the DOM elements in a
          > complex document.
          >
          > If your application naturally has different "screens", it seems to me
          > that it runs more "with the grain" of in-browser programming to break
          > those screens up as separate pages. Where you have a single
          > persistent interface that's long-lived (eg, like Yahoo! Mail or
          > GMail, where the screen may be open in the browser all day long), be
          > vigilant about destroying DOM elements and JavaScript objects when
          > you're done with them.
          >
          > Regards,
          > Eric
          >
          >
          > ______________________________________________
          > Eric Miraglia
          > Yahoo! User Interface Library
          >
          >
          >
          > On Feb 1, 2007, at 6:38 PM, dayardman wrote:
          >
          > > Pardon me if this question is out of place but I'm currently using the
          > > yui library and had a question that I think the minds posting in this
          > > group might be amongst the best around to answer.
          > >
          > > I have one of my applications setup in such a way that each screen of
          > > the application is loaded once when the user requests it into the
          > > browser into a div for each screen more or less. When the user
          > > requests a screen that is already loaded in the browser I simply hide
          > > the current one and show the requested one. I also have a bit of logic
          > > in places so that things like table grids automatically refresh
          > > themselves as necessary. This works fine but I'm concerned with
          > > performance and scalability going forward as I'm adding more and more
          > > screens everyday. My question is: Is this a wise approach, or are
          > > there better ways of doing this? My concern is that having all those
          > > divs in the browser end up weighing down the DOM making it slow to
          > > traverse or do things like visual effects even if most of the divs are
          > > hidden. All the event listeners floating around as well seem like a
          > > no-no.
          > >
          > > As I see it there are several alternatives, namely:
          > >
          > > 1. Use one div. Load each screen into a js var as needed and place
          > > that html into the div and evaluate any loaded javascript. When
          > > switching between loaded screens simply remove all attached listeners,
          > > fill the div with the html in memory for the requested screen and
          > > add/re-attach listeners. The big pro of this is that it seems to me
          > > storing each screen in a js object or array is easy and not as heavy
          > > as keeping it in the DOM. My problem with this approach is that
          > > switching out the innerHTML of a div doesn't always work the way you
          > > want it to, the screen doesn't seem to keep the same state it was in
          > > when you switched it out.
          > >
          > > 2. Use iframes for each screen. So instead of multiple divs do
          > > multiple iframes. I say this because I think each iframe holds its own
          > > DOM space and doesn't weigh down the DOM of the parent page (?). The
          > > only thing in the parent page would be a bunch of iframes which
          > > doesn't seem so bad to me. If I do a visual effect in an iframe the
          > > tons of markup existing in all the other iframes wouldn't affect it.
          > > The cons of this approach are that I would have to load my js
          > > libraries again in each iframe and I'm not sure if iframes really make
          > > a difference in terms of adding to the slowness of the page.
          > >
          > > I've thought of other alternatives but those are the two that stick
          > > out. What do you guys think? Any advice would be appreciated based on
          > > your experience and knowledge of browsers, the DOM, et al. My main
          > > concern is responsiveness or the appearance thereof. I'm tired of
          > > building applications that you have to click and wait. It seems
          > > complete and utter common sense to me to load screens once and only
          > > send and retrieve data as necessary instead of getting entire pages
          > > over and over again. Some of the things I'm doing are for the
          > > government where network speeds sometimes come to a crawl and the
          > > fewer bytes I send over the wire the better. Please advise, I look
          > > forward to your responses.
          > >
          > > - Andrew
          > >
          > >
          > >
          >
        • martti
          We had a very similar thick-thin client dilemma. The reality is: if you need a thick client, you have to skip javascript. We switched to glade-3 &
          Message 4 of 5 , Feb 5, 2007
          • 0 Attachment
            We had a very similar "thick-thin" client dilemma. The reality is: if
            you need a thick client,
            you have to skip javascript.
            We switched to glade-3 & php-gtk2 & xml-rpc.
            The good with glade-3 IDE is, that you can use them by pygtk/php(client
            version), even by C++.

            dayardman wrote:
            >
            > Thanks Eric,
            >
            > I guess I'm looking for a silver bullet, as a developer I have to
            > believe that they exist. I'm primarily focusing this effort on 2
            > applications which do have naturally different screens. However,
            > because of slow network connections and a need to differentiate myself
            > from the pack I want these bad boys to be peppy and fast. I don't have
            > the luxury of clustered server farms or super fast application
            > servers. As such I'd like to load each screen just once from the
            > server when they are requested from then on only load data as
            > necessary which is really not that often and tends to be far quicker
            > retrievals than loading entire pages.
            >
            > As you said there is a point where the browser's performance starts to
            > degrade but I'm wondering if I can't mitigate that somehow. With Yahoo
            > and Google Mail they seem to retrieve the entire page when viewing a
            > message or switching between "pages" such as to contacts or to spam
            > but in some cases such as switching back from contacts to inbox or
            > marking a message as spam they do not but instead seem to keep the
            > previous view in the browser and simply show it. I'd like to do that
            > but more of it, I'm just not sure at what point degradation will start
            > to occur.
            >
            > I've more or less decided to store each screen in its own div, created
            > dynamically when first requested from the app. Switching between pages
            > will hide or show the divs. I'll then do some tests to see how many I
            > can hold in the browser before it starts to slow down or hog memory
            > and set a limit based on that so that if a page is requested and I
            > already have x number of pages stored I'll pop the oldest visited div
            > and push the new page. I may even when switching between divs try to
            > remove all listeners from the div and reattach them when you switch
            > back to it. If you have any cautions with this approach please advise.
            >
            > Last question, as for destroying DOM elements and javascript objects
            > when done with them, what's the cleanest way to do that?
            >
            > Again thanks for your reply, I appreciate it.
            >
            > - Andrew
            >
            > --- In ydn-javascript@yahoogroups.com
            > <mailto:ydn-javascript%40yahoogroups.com>, Eric Miraglia
            > <miraglia@...> wrote:
            > >
            > > Andrew,
            > >
            > > There's no single, satisfactory answer to your question that would be
            > > correct for every application (IMHO). What we know from experience
            > > is that you have a finite amount of DOM complexity to play with
            > > before browser performance begins to degrade. Degradation happens
            > > sooner when there are script hooks attached to the DOM elements in a
            > > complex document.
            > >
            > > If your application naturally has different "screens", it seems to me
            > > that it runs more "with the grain" of in-browser programming to break
            > > those screens up as separate pages. Where you have a single
            > > persistent interface that's long-lived (eg, like Yahoo! Mail or
            > > GMail, where the screen may be open in the browser all day long), be
            > > vigilant about destroying DOM elements and JavaScript objects when
            > > you're done with them.
            > >
            > > Regards,
            > > Eric
            > >
            > >
            > > ______________________________________________
            > > Eric Miraglia
            > > Yahoo! User Interface Library
            > >
            > >
            > >
            > > On Feb 1, 2007, at 6:38 PM, dayardman wrote:
            > >
            > > > Pardon me if this question is out of place but I'm currently using the
            > > > yui library and had a question that I think the minds posting in this
            > > > group might be amongst the best around to answer.
            > > >
            > > > I have one of my applications setup in such a way that each screen of
            > > > the application is loaded once when the user requests it into the
            > > > browser into a div for each screen more or less. When the user
            > > > requests a screen that is already loaded in the browser I simply hide
            > > > the current one and show the requested one. I also have a bit of logic
            > > > in places so that things like table grids automatically refresh
            > > > themselves as necessary. This works fine but I'm concerned with
            > > > performance and scalability going forward as I'm adding more and more
            > > > screens everyday. My question is: Is this a wise approach, or are
            > > > there better ways of doing this? My concern is that having all those
            > > > divs in the browser end up weighing down the DOM making it slow to
            > > > traverse or do things like visual effects even if most of the divs are
            > > > hidden. All the event listeners floating around as well seem like a
            > > > no-no.
            > > >
            > > > As I see it there are several alternatives, namely:
            > > >
            > > > 1. Use one div. Load each screen into a js var as needed and place
            > > > that html into the div and evaluate any loaded javascript. When
            > > > switching between loaded screens simply remove all attached listeners,
            > > > fill the div with the html in memory for the requested screen and
            > > > add/re-attach listeners. The big pro of this is that it seems to me
            > > > storing each screen in a js object or array is easy and not as heavy
            > > > as keeping it in the DOM. My problem with this approach is that
            > > > switching out the innerHTML of a div doesn't always work the way you
            > > > want it to, the screen doesn't seem to keep the same state it was in
            > > > when you switched it out.
            > > >
            > > > 2. Use iframes for each screen. So instead of multiple divs do
            > > > multiple iframes. I say this because I think each iframe holds its own
            > > > DOM space and doesn't weigh down the DOM of the parent page (?). The
            > > > only thing in the parent page would be a bunch of iframes which
            > > > doesn't seem so bad to me. If I do a visual effect in an iframe the
            > > > tons of markup existing in all the other iframes wouldn't affect it.
            > > > The cons of this approach are that I would have to load my js
            > > > libraries again in each iframe and I'm not sure if iframes really make
            > > > a difference in terms of adding to the slowness of the page.
            > > >
            > > > I've thought of other alternatives but those are the two that stick
            > > > out. What do you guys think? Any advice would be appreciated based on
            > > > your experience and knowledge of browsers, the DOM, et al. My main
            > > > concern is responsiveness or the appearance thereof. I'm tired of
            > > > building applications that you have to click and wait. It seems
            > > > complete and utter common sense to me to load screens once and only
            > > > send and retrieve data as necessary instead of getting entire pages
            > > > over and over again. Some of the things I'm doing are for the
            > > > government where network speeds sometimes come to a crawl and the
            > > > fewer bytes I send over the wire the better. Please advise, I look
            > > > forward to your responses.
            > > >
            > > > - Andrew
            > > >
            > > >
            > > >
            > >
            >
            >
          • Nico Giraldi
            Hi, i am getting this problem: input fields inside a dialog widget over a panel with modal setted at true are not more editable.If i set panel modal at false
            Message 5 of 5 , Mar 14, 2007
            • 0 Attachment
              Hi,
              i am getting this problem: input fields inside a dialog widget over a
              panel with modal setted at true are not more editable.If i set panel
              modal at false everything works fine. I have tested it in FF and ie on
              win platform. Panel and dialog are builded from markup.
              In firebug i am getting this error
              [Exception... "'Permesso negato per impostare la proprietà
              XULElement.selectedIndex' when calling method:
              [nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e
              (NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame ::
              http://yui.yahooapis.com/2.2.0/build/container/container-min.js ::
              anonymous :: line 114" data: no]

              Page and code is here http://luckybet.e-mind.it/registrazione.html
            Your message has been successfully submitted and would be delivered to recipients shortly.