Hej Martin
>Making a small application with two select boxes and two labels including
>logics is about 600 KBytes! I don't think it is a small application.
Now we have removed all logics and the size is still 78 kBytes!!! We think it
is too big for that implementation. Must be a lot of dead code there.
>Sounds in deed not like a small application. Could you perhaps share your code
>(the application code) so that we can see whats causing such a huge amount of
>file size?
>Additionally, if you want to investigate some more on dependencies: The
>generator offers a way of logging dependencies. Just search for the log key in
>the config reference in the manual.
>1. to look over dependencies between classes and if it can be changed to make
>an application slimmer
>We are trying to keep the dependencies as low as possible but as you sure can
>imagine, thats not as easy as it sounds. But be sure there will be some
>changes in the future because on limited devices like mobile devices, that
>size does matter even more.
I hope that...
>2. let the generator remove ALL functions not called to minimize the
>application size. In config.json there can be introduced a definition clause
>preserving certain functions in certain classes and modules. This would really
>minimize the size of an application. Today there is a lot of dead code
>transported over Internet and never called.
>I think thats technically not possible at all, at least not as comfortable as
>we want it to be. Adding the methods to the config file is really
>uncomfortable and in my opinion not an option. And how should the generator
>know what method will ever be called on runtime in the application?
>We already have a bug open for removing static methods the same way you
>described but doing that for member methods is insane! I'm quite sure we don't
>put much effort on removing those but on static methods, you are absolutely
>right, especially in case you use one static method of a gigantic utility
>class.
It is sure possible! The question is how it can be done the best way. As you
register dependencies of objects, classes you can register dependencies off
line of functions. This register is at generation time so it does not affect
runtime. Additionally, it can be easily implemented by a generator tag and
giving as a part of the documentation.Insane ideas have changed the world many
times!
1. Just a draft idea:
@$callme callanother Clazz.runme
callme : function()
{
this.callanother();
var clazz = new Clazz();
clazz.runme();
},
2. the other way is parsing, which creates some problems...
Pros: good documentation and size reduction by deleting dead code
Cons: the developer needs to document!!! (but it is really good even though
most don't like it) = a necessity to document
You still have the opinion that it is useless?
Is the interface of the generator easy to plug into, modules? Do you have any
special way of doing that?
Stefan
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
