Rosh,

I don't understand your comment. My approach is to pre-generate the
whole JS with GWT as a dynamically configured project, so there's no
worry about consuming obfuscated JS as at compile time it's normal
Java...

Your approach if I understand it correctly is to dynamically on the
client side combine differently compiled GWT applications (or other
JS) then you would get multiple obfuscated emulated JRE-classes and
other shared code between the modules. Which would give a larger
memory and network footprint.

Therefor I don't think the dynamic addition of (at compile time
unknown) modules is doable with the current (or future) versions of
GWT.

/Andreas


On Fri, Mar 13, 2009 at 4:14 PM, Rosh PR <[email protected]> wrote:
> Andreas, The idea is to have different plugins loaded and run by different
> users
> at run time. So even if we manage to compile the code how is the framework
> gonna consume the generated obfuscated JS code, Cos the framework is already
> in a
> obfuscated JS state. Unless the framework try loading some js files from
> the
> file system dynamically & add it as new HTML. Which I think is not a
> practical think todo.
> On Fri, Mar 13, 2009 at 6:13 AM, Andreas Karlsson <[email protected]> wrote:
>>
>> > I am in the design phase of a application that will be deployed on
>> > different
>> > offices, each one with almost equal  workflows, automatizing, staff and
>> > requisites. Yeah, that "almost" sucks. The idea is to get one big common
>> > or
>> > default subset, build some kind of plugin / extension / delegation
>> > system
>> > for the specific and deploy different builds without forking the
>> > codebase.
>> > That forking should be a nightmare.
>> >
>> > So, your way was the initial idea, and in our project fits. But some
>> > kind of
>> > dynamic plugin loading and upgrading, without touching the core install
>> > is
>> > ideal, and a very powerful tool. For example, you can do per user plugin
>> > configs.
>> >
>>
>> But is the dynamic plugin idea to compile each plugin as a seperate
>> gwt-module (compilation unit)? If this is the case the end-user would
>> need to download duplicates of the JRE-emulation (and other common and
>> shared classes/code) which would not be an ideal solution. I will make
>> a server-side framework which manages the deployment of the GWT
>> application, as mentioned it will take minutes to recompile and deploy
>> the updated gwt application after the plugin configuration has
>> changed, but that is not a problem as the idea is not to have
>> different users have different plugins but rather different
>> offices/client of the application.
>>
>> /Andreas
>>
>>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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