Hi deech,
On Tuesday 09 August 2011 15:29:12 aditya siram wrote:
> I have looked at the Partloader but there is a warning on the page
> telling me not to use it to load framework classes. However this is
> what I want to do. So for instance, all my apps use a table and I'd
> like to have that code cached in browser memory.
The warning does describe that you should use the application classes which
use the table widget (in your case) and put them in parts. You always have an
application class which is using a framework widget and this class should be
the starting point for parts.
The generator will automatically resolve the dependencies of your application
classes and put the neeeded framework classes in the parts where there need to
be.
> I've been trying to understand "variants" [1]. The documentation says
> it does dead code elimination, but I don't understand how to use it to
> help me.
Suppose you have the following snippet of code (this is used throughout the
framework)
--snip--
// "qx.debug" returns a boolean value
if (qx.core.Environment.get("qx.debug"))
{
// some debugging code which should be present in the "build" version
}
--snip--
The application skeletons have built-in the configuration to remove the
"qx.debug" variant out of the build version.
--snip-
"environment" :
{
"qx.debug" : false
}
--snip--
See at
http://manual.qooxdoo.org/1.5.x/pages/tool/generator_config_ref.html#environment
This (and the setting of the "OPTIMIZE" macro) tells the generator to remove
this "dead code". You can define environment keys for your application and use
these environment keys to remove "dead code" if you need to. There is a nice
write-up about the environment feature in the manual. Worth a reading :)
-> http://manual.qooxdoo.org/1.5.x/pages/core/environment.html
> Also maybe I'm doing something wrong, but I put together a small demo
> application in which I have one class that uses the following
> framework classes:
> qx.ui.container.Composite,
> qx.ui.layout.HBox
> qx.ui.layout.VBox
> qx.ui.form.Button
> qx.ui.form.Textfield
> qx.ui.tree.Tree
> qx.data.controller.Tree
> qx.data.marshal.Json (statically)
> qx.ui.groupbox.Groupbox
>
> The build step creates a 715KB Javascript file. Is this normal? Can
> this be reduced somehow?
If these widgets are used at the same time and you can't divide them into
parts you won't get any smaller since you need classes for layouting, UI core
subsystem, event layer, etc.
If you have e.g. an action which is triggered by the user which shows another
UI (e.g. another tab) you can slice your application in parts and load the
widgets only if the user e.g. presses a button (like a button which shows a
dialog).
Another possible solution would be to load a small "core" packages which
creates the UI without the necessary widgets and shows a waiting cursor as
long as the parts are loading, which contain the widgets. This way you might
get quicker startup and the application appears faster.
Regards,
Alex
------------------------------------------------------------------------------
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
