[qooxdoo-commit] SF.net SVN: qooxdoo: [10690] branches/legacy_0_7_x/qooxdoo/frontend/ framework/too
Brought to you by:
ecker,
martinwittemann
From: <wp...@us...> - 2007-10-27 20:03:49
|
Revision: 10690 http://qooxdoo.svn.sourceforge.net/qooxdoo/?rev=10690&view=rev Author: wpbasti Date: 2007-10-27 13:03:47 -0700 (Sat, 27 Oct 2007) Log Message: ----------- Minor changes Modified Paths: -------------- branches/legacy_0_7_x/qooxdoo/frontend/framework/tool/generator2.py Modified: branches/legacy_0_7_x/qooxdoo/frontend/framework/tool/generator2.py =================================================================== --- branches/legacy_0_7_x/qooxdoo/frontend/framework/tool/generator2.py 2007-10-27 19:58:07 UTC (rev 10689) +++ branches/legacy_0_7_x/qooxdoo/frontend/framework/tool/generator2.py 2007-10-27 20:03:47 UTC (rev 10690) @@ -46,13 +46,13 @@ * Each part defines a part of the application which you want to load separately * A part could be of visual or logical nature * Each part may result into multiple packages (script files) -* The number of packages could be exponential to the number of views +* The number of packages could be exponential to the number of parts but through the optimization this is often not the case -* You can automatically collapse the important views. Such an important -view may be the initial application class (application layout frame) or +* You can automatically collapse the important parts. Such an important +part may be the initial application class (application layout frame) or the splashscreen. Collapsing reduces the number of packages for the -defined views. However collapsing badly influences the fine-grained nature -of the package system and should be ommitted for non-initial views normally. +defined parts. However collapsing badly influences the fine-grained nature +of the package system and should be ommitted for non-initial parts normally. * Further optimization includes support for auto-merging small packages. The relevant size to decide if a package is too small is the token size which is defined by the author of the job. The system calculates the token size of @@ -61,9 +61,9 @@ Internals ====================== * All merges happen from right to left when the package list is sorted by priority. -The main theory is that a package which is used by multiple views must have the dependencies +The main theory is that a package which is used by multiple parts must have the dependencies solved by both of them. So the merge will always happen into the next common package of -both views from the current position to the left side. +both parts from the current position to the left side. * There are some utility method which @@ -344,7 +344,7 @@ # - # PREPROCESS PHASE: VIEWS + # PREPROCESS PHASE: PARTS # if execMode == "parts": @@ -645,7 +645,7 @@ ###################################################################### -# VIEW/PACKAGE SUPPORT +# PART SUPPORT ###################################################################### def processParts(partClasses, partBits, includeDict, loadDeps, runDeps, variants, collapseParts, optimizeLatency, buildScript, buildProcess): This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. |