Page 1 of 5 123 ... LastLast
Results 1 to 10 of 45

Thread: Ext Best Practices (load script or inline?)

  1. #1

    Default Ext Best Practices (load script or inline?)

    I have been trying to design my application model for a fairly large application using the Ext element.load to load scripts into divs to extend the functionality of the initial application. I am curious though... after reading several articles in the help area, I get the feeling that loading scripts via this method is not recommended and considered bad practice. If this is true, what is the alternative method? In order to have a solid application with optimum performance, is it suggested that the entire application (including all the form creations, grid creations, menu creations, etc) be loaded right into the header? I "assumed" initially that by loading the scripts as they were needed, it would cut down on the initial load time of the page (which is already long enough as it is), but based on some of Jack's comments throughout this forum, I am starting to think this isn't true?

    Also, if I create a grid in a tab, I would assume it would be better not to destroy it and leave it there for reuse when that tab is closed (question, because once again asking for verification)? If so, is there a way to redirect the method of the close button for that tab to hide it instead of killing it?

    Is there a best practices document somewhere within these forums that would outline how to get the maximum performance and load time utilizing Ext?

    And off topic, but probably an easy one, is there a degredation report on browsers prior to the compatibility list?

    To give you some background, my application (once loaded) will NEVER redirect to another page. All the work will be done within one page/interface.


    -T

  2. #2
    Ext User cluettr's Avatar
    Join Date
    Apr 2007
    Location
    Boston, MA
    Posts
    336

    Default

    Im amidst this very issue right now exactly as you have explained it. Beleive it or not I just posted something nearly identical... hoping someone can provide insight for us : )

  3. #3

    Default

    Ya, well you know, I have seen a lot of talk around the forums about similar and round-about optimization techniques, etc, but nothing solid. I do gather from my studies in this forum that it is better to include scripts rather then load them into divs, but I haven't seen many solid topics on what the best practices are. I would assume the creator built this framework with specific intentions of how it would be used in large scale applications, but unfortunately, I think for my large scale application, EXT will have to take a back seat. I think the learning curve is a little too steep for RAD and will push my project back nearly a year in order to get all the concepts of EXT. Cool framework though, one of the best and most versatile I have seen in the javascript community.

    I am a C# ASP.NET / OO Classic ASP programmer that has done quite a bit of JS, but this definitely opened my eyes to the fact that JS is much more complex and versatile then it is given credit for.

  4. #4
    Ext User cluettr's Avatar
    Join Date
    Apr 2007
    Location
    Boston, MA
    Posts
    336

    Default

    I'm so with you on this! This is quite complex and has already pushed back my own project about 2 weeks. For the first time I am starting to understand why big corporations are so against Open Source. There's no accountability and no service contracts. Without it you post, wait and hope. Granted there are support contract options that Jack has provided but this is a zero budget project. I'm on a wing and a prayer. This is a promising tool which I hope to get my head around sooner than later but it's been frustrating so far.

    At the moment I have all the code for generating my grid in the head tags of the html page. Then in the script I load in via an ajax request I call the functions that build the actual grid. So I have a half and half approach working. While I think this approach is a bit better then having all the code in the called script I'm still missing something as far as redisplaying the grid rather then recreating it. I'd settle for being able to destroy the grid before creating again but I'm stumped on that one too...

  5. #5

    Default

    If I had chosen to move forward with EXT, I would have gone with the support contract and the full license for sure (you couldn't have a viable product without it), but I would need the capital for that which is kind of in reverse order (build the product, get the return... not get the capital, build the product [unless you have sponsers]). Since this is more of my personal company project (that has had many external companies pushing it), I am not really accountable to anyone (just "hopes"), but at the same time with it being mine, there is no capital backing it until completion.

    Anyhow, from what I gather, when creating objects that are going to be reused, you create them once, and after the div is destroyed, you leave it in memory for reuse when the div is reintroduced. The one thing I am not too clear on is if you have a panel with say a grid and you close the panel, the grid remains in memory, but the div does not. When you go to open that panel again, the grid doesn't just magically appear again (I would assume), so when you want that grid to show up again, you have to somehow tell it to go back to that panel and pick up where it left off without recreating the entire thing. Now another concern that I think you should be concerned about if you are thinking about speed and optimization is that it is well documented that the 1.0/1.1 grid has memory leaks and is extremely slow with semi-large datasets. In that respect, if you are serious about your application, you may have to wait the few months for 2.0 to hit production.

    For me, speed is always an issue, and I am not 100% on this, but I think the majority of the overhead goes into the layout. It appears to load much slower then my login page and actually gets slower every time I refresh the page (This may be an IE memory cleanup issue).

    Yesterday I tried to move all my code to the head of the main document and load external pages into the content pane for each page in the hopes that this would assist in optimization, but it has started breaking and this is where my frustration started to peak.

    I got as far as creating a login form with dynamic validation via AJAX that opened a new window (or prompted you to click on a link after login if you had popup blocker enabled), then I created a layout, created some public members for that layout so other parts of my app could manipulate them (external scripting access to center, north, south, east, and west layout objects) and created the standard external interfaces for hiding or collapsing/expanding sections. I then created the AJAX grid, threw a quick toolbar on there, got the delete functionality working, tried to add a form by a toolbar button, and this is where things started to go south...

    I started looking into the optimization thing and tried to move all the "work-horse" code as specified previously, but most of my hard work started crapping out. And as beautiful as IE 6 is (what we use at work, and yes, sarcasm), the js engine has some of the worst debugging capabilities in the world (crap like "object failed" - what freakin object?), and it calls out "line 112" which leads nowhere, because the problem exists in one of the include files. I suppose what would help my faith in js again a little is better debugging that gives me something I can actually use? Ok, that's my own fault for not knowing decent debugging tools, but it is definitely a good portion of why my frustration level has exceeded the usefulness of JS. When JS becomes this complex, you MUST have something up to par with the latest and greatest parsers/debuggers of the major programming languages. It now takes me upward of a week just to complete one small portion of the website.

    Keeping all of my rants in mind, in summary I would say that I am frustrated beyond belief and a good 50% of it is my own ignorance, but when one small piece of your project takes one week, you can imagine what this project would look like timewise if there are upwards of 100 pieces to the project.

  6. #6

    Default Retarded...

    Ok, for all the IE users who didn't read the sticky (me included), the good debugger is companionjs - there is 50% of my problem...

  7. #7

    Default 25% of the next piece

    In answering my own questions through experimentation, including things in the header is MUCH faster then loading them after the fact. The interface seems to run 50-75% faster without performing the task of executing scripts on seperate pages after the fact (just executing one function that wakes up the parent to populate it). For the second part (caching and reintroduction of items), I will run a few tests and see if I can't come up for the answer to that one too.

    I love how through sheer determination and experimentations I eek through answering my own questions.

  8. #8
    Ext User cluettr's Avatar
    Join Date
    Apr 2007
    Location
    Boston, MA
    Posts
    336

    Default

    I feel your pain.

    One question...

    Code:
    (just executing one function that wakes up the parent to populate it).
    What do you mean by wakes up the parent to populate it?

  9. #9
    Ext User cluettr's Avatar
    Join Date
    Apr 2007
    Location
    Boston, MA
    Posts
    336

    Default

    Just loaded companionjs and of course that doesn't work... can't click on the errors it shows... Browser based development is #($*#*$&)(#*&$

  10. #10
    Ext Premium Member BernardChhun's Avatar
    Join Date
    Mar 2007
    Location
    Quebec, Canada
    Posts
    831

    Default

    ohoy majorpay,

    I'd like to answer your question based on what I've done until now. I won't consider this as bad or good practice but it has worked for me since the start.

    I've always used script tags to load my javascript as it was cluttering my html/php/asp file like crazy as the project grew into one big bloat.

    then I separated the whole code into independant structures within independant files for dev coding.

    once it is ready for production, I use a small python script to gather all the files into one big js file to limit the number of uploading files to the client. Browsers tend to be locked on the number of files they can download at the same time...

    We gzip everything that comes out of the server et voil

Page 1 of 5 123 ... LastLast

Posting Permissions

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