@TrashHalo While I agree that GWT compiler can look in to
optimizations, I am neutral to the idea of allowing optimization
options to be passed on to the compiler. I believe that should be left
to the discretion of GWT team.

Now back to my question on JavaScript size; I did a search on the GWT
forum and found that no one ever has complained about the JavaScript
size. Is it because no one has built a large application that has
around 4000-5000 GWT source files?
GWT compiler should certainly look in to options of splitting this
JavaScript in to multiple javascript and lazy load JavaScript. If
optimizations of similiar kind already exist, then I should read back
the manual.

@Ian On your question on rendering on-the-fly, We had this as one of
our initial options. Allowing the user to design the screen and then
persisting this screen structure (what widgets and how they are
grouped i.e a Tab panel or a popup etc) in the database and when the
user accesses the actual screen, fetch this structure information at
runtime and render the screen by creating widgets and panels and
adding them on the fly.

Firstly, this design had its own drawbacks
#1. The cost of fetching the screen information runtime and
rendering(which takes significant amount of time to load the screen).
Particularly that i told you, we had anywhere between 500-1000 widgets
grouped under various panels, popup panels and tab panels.
#2. Inability to perform Reflection. We have cases where users can
register Custom Adapters to certain Widgets and binding adapters to
widgets at runtime is not possible, unless i write one big IF loop,
something like this.
        if(adapterName.equals("com.google.DoThisAdapter")) {
                return new com.google.DoThisAdapter();
        } else if(adapterName.equals("com.google.DoThatAdapter")) {
                return new com.google.DoThatAdapter();
        } .......
        ...........
        .........

This made us resort to the static generation of the UI code, because
the screen designing is just a one time process in the lifecycle of
the product we are building i.e. The first time our product is
customized for a given customer.

Also the generated code is much like a hand-coded code and therefore
there are runtime rendering overheads. I hope you are clear.

<Removed thread content for brevity>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to