18 Mar 2010 9:37 AM #11
stever: as you faced this problem , i wanna ask you ( other's are welcome to answer too ofcourse ):
let's say i'm VERY determined to have this functionality ( deferred script loading & deferred initialization ).. which is the best direction :
1. yours , shown on your post
3. 'envelope' ( my latest proposal )
4. purchasing ultra-expensive account and pushing the developers to make it
5. giving up and not wasting my time on it
18 Mar 2010 9:41 AM #12
I don't like the system of having the client and server communicate which classes are already on the client, and it really does no good in caching them (from a cache utilization perspective).
You can still lazy load on show if you want, by having a container for it. Same way you would do it in the unpatched current version of ext.
18 Mar 2010 9:52 AM #13
On the dynamic loading of classes:
a) container knows that it must check and load if needed the classes. this is quick and dirty, has lots of issues, and is not automatic.
b) SamariJack has already done some stuff for loading classes on demand (a long time ago). That is partly why many of the ExtJS classes have changed to the 2 param Ext.extend from the 3 param version, which makes the interception of class creation a point at which a sync load could occur.
c) Alter the createComponent such that when an xtype is not registered, that it asks the server to download it, or calls a client side handler to do so (you might pre-register all the known xtypes and give a routine on how to load them.
The dynamic loading of classes is orthogonal to the deferred creation of them. However, they can be combined in some helpful ways. For example, when moving the items to deferredItems, we could iterate and see what xtypes there are that are not currently loaded, and start loading them since we know that they may be used in the very near future. I'm going to take a look at this approach.
18 Mar 2010 9:57 AM #14
i just looking for a good way to not overload the browser. hundreds of big packages ( ext ones / application ones ) does that. if it was unnoticeable i wouldn't bother. but it take around 15 seconds to power up my current one ( not from browser cache ), with gzipping, on a relatively powerfull computer. the application slowness is really noticeable too.
Maybe i'm looking at the wrong direction for solutions
and stever- thanks very much for the support. i really appreciate that. +1
18 Mar 2010 10:25 AM #15
18 Mar 2010 10:38 AM #16
"Hundreds? the Ext breakdown is into 10 files, I think." => I meant components.. many of which are not required by the app most of the times. probably i over-counted it..
speed & load tests:
130 js files, 620kb of downloaded data ( 1.5 mb saved using compression ).
50 mb ram in use ( before any actions and activex loaded ) - deferredrender used.
time to download and initialize the scripts: 8 sec. ( from server on local network. from website it takes much more, especially for low-connections and weak computers ).
total initialization time ( with loading initial data , css, and all ) is around 13 sec.
I have extensive nesting ( tabs , accordions, border-layouts which are rarely expanded, toolbars, card-layouts etc. and many of the components require specific big extensions which are not used by any other ( gmaps in only one tab, charts only in another etc ). its going to be a big backend management system.
and the big problem is- it's going to ( fortunately ) be extensively used by telco's which are sitting on thin-clients ( weak,small computers ) and restricted to ie6
18 Mar 2010 1:21 PM #17
18 Mar 2010 3:48 PM #18
19 Mar 2010 5:03 AM #19
Thanks guys. so, bofore jumping on anything, i'll need to analyze exactly the bottlenecks. ( loading/initializing/rendering/layouts etc ), and then fix them one-by-one.
let's return to the subject of the thread - deferred loading and initialization. i'll try to make some re-usable solution, based an all the info i have now ( thanks to you all ).
the solution will consist of two parts:
1. dynamic script loading mechanism based on xtype-relations and server-side concatenation, minifying , obfuscation ( & scrambling ) and caching . the cached scripts will be ready-to-use without passing through php ( file with cached script links will be provided to the app , just like the direct api . it will be independent of the deferred initialization, and may be used as-is.
2. reusable deferred-initialization utility , which will use (optionally) the dynamic-script-loading . it will fit common component which hide functionality : card-layout ( with all it's overrides like tab panel etc ), accordion-layout, border-layout ( w. collapsed regions ), etc.
21 Mar 2010 1:28 AM #20