On Aug 22, 9:07 am, Mickey <[EMAIL PROTECTED]> wrote:
> I think one of us is still missing some points (hopefully it's me). So
> let me try to clarify.
>
> On Aug 21, 3:00 pm, walden <[EMAIL PROTECTED]> wrote:
>
> > > Thanks for the reply. What I mean by "developed independently" is that
> > > a core UI framework would be built/distributed as a common
> > > infrastructure, and add-on components would be developed/distributed
> > > individually to integrate/run on this platform.
>
> > Just like my application builds on the GWT UI classes, no?
>
> Yes, I understand this point, and yes this would work if you are only
> talking about compiling one component (or as many as source is
> available for) on top of the base framework module lbrary. But the
> idea breaks down after that in the same way that I cannot expect to
> build on top of one of your modules - because I do not have your
> source. I only have my source and the common library source.
>
I don't understand your notions of dependency, apparently. You can't
build on top of anything whose interface is unknown to you, and you
can't integrate or test with something for which you have no
implementation. If you have the interface to my library, you can code
to it and bind later with the implementation to do testing. If you
never intend to test, then you don't need any of this. I'm just
confused what you expect to be able to accomplish. Why worry about
linkage between modules that will never know each other in any sense?
I'm sure it's me who's missing something.
> > The fact that you still have to package one of those permutations at
> > some point in order to deploy it is the point I was making earlier.
> > "Permutations" is not a problem for the GWT compiler, which will
> > optimize each particular permutation to a better runtime than your
> > plug-in approach could.
>
> No. The idea is not to "package" these combination together (just as
> Eclipse plug-in combinations are not packaged together). Plug-ins
> would be packaged/installed separately and installed into the same
> base location whereby they become integrated into a cohesive "app".
> So, effectively the packaging is performed at install time in a
> cumulative fashion, not beforehand for distribution, because again,
> the plug-ins may come from different sources.
I say "package"; you say "become integrated into a cohesive app". A
rose by any other name...
The point is, for the third time now, if you must integrate and vet
the integration, you might as well do it a la GWT. It almost sounds
like you are shifting your customer into the development process. In
that case, give them the GWT compiler and teach them how to turn a set
of plug-ins into a "cohesive app". Best case, they will get compile
errors and call you immediately.
> Well, I've seen enough people here voice similar interest in this type
> of support. So I do not think I am alone. I was just hoping that
> someone might have discovered some clever way of overcoming this
> limitation.
I think the "similar interest", when grounded in practicality, has
more to do with total load size, preferring a dynamic loading model to
shorten perceived latency. The idea of throwing a bunch of
independently designed modules together and worrying about
dependencies later sounds like a recipe for disappointing quality to
me.
Walden
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
