Four additional arguments in favor of using "split point moniker classes" is
that they
1) are easier to find within an IDE (i.e. "Show References" in your IDE from
a moniker class declaration would show you the associated runAsync call),
2) can take advantage of inheritance as a way to group split points into
meaningful families (which would make them more easily browsable and
navigable in javadoc and in an IDE),
3) can be javadoc'ed to explain what they do, and
4) they could potentially be augmented with additional hints to the code
splitter using annotations (these are a stretch; Lex might be able to think
of more realistic example annotations)
/**
* Split points in this hierarchy relate to the email functionality within
the office suite.
*/
class EmailSplitPoint extends OfficeSuiteSplitPoint {
}
/**
* This split point carves out all heavyweight functionality related to
composing emails,
* most importantly, the rich text area clases.
*/
@ProhibitPreloading
@MustBeExclusiveFragment
class EmailCompositionSplitPoint extends EmailSplitPoint {
}
// ... elsewhere ...
void onComposeButtonClicked() {
GWT.runAsync(EmailCompositionSplitPoint.class, new AsyncCallback() {
public void onError(Throwable e) { ... }
public void onSucess() {
new EmailCompositionView().activate();
}
});
}
On Wed, Jun 24, 2009 at 6:50 PM, Cameron Braid <came...@braid.com.au> wrote:
> Each of these different libraries would be enclosed within a unique GWT
> module therefore when you refer to the split point name, can't you just use
> the module name + split point name ?
>
> in module ThirdParty :
>
> GWT.runAsync("one", new RunAsyncCallback() { ... });
>
> in MyModule :
>
> GWT.runAsync("one", new RunAsyncCallback() { ... });
>
> <extend-configuration-property name="compiler.splitpoint.initial.sequence"
> value="MyModule#one" />
> <extend-configuration-property name="compiler.splitpoint.initial.sequence"
> value="ThirdParty#one" />
>
> Cam
>
> 2009/6/25 Lex Spoon <sp...@google.com>
>
>
>> On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoon<sp...@google.com> wrote:
>> > Overall, unless I missed something,
>>
>> Okay, Bruce pointed out a new constraint to me: if different libraries
>> name their runAsync calls, then we want to able to refer to those
>> calls reliably even if different libraries choose the same name. This
>> isn't an issue immediately, but it likely will be in the future.
>>
>> Thinking about libraries, I would add another constraint: we don't
>> want libraries to have to expose their implementation. Library
>> writers should ideally be able to document a named runAsync call
>> without exposing the precise arrangement of their internal classes.
>>
>> After some discussion at the office, a tweak to option 4 fixes things
>> up handily. Instead of passing in a string to the method, act like a
>> Java framework and require passing in a class literal. A typical use
>> in application code would pass in the enclosing top-level class:
>>
>> package org.foodity.impl;
>> class Cookies {
>> ...
>> GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
>> ...
>> }
>>
>> A library writer could instead specify a public class, so as not to
>> expose their internal factoring.
>>
>> A user of the name in a gwt.xml file would use the fully qualified
>> version:
>>
>> <extend-configuration-property
>> name="compiler.splitpoint.initial.sequence"
>> value="org.foodity.impl.Cookies" />
>>
>> A user in another Java file would use imports to make the name short:
>>
>> import org.foodity.impl.Cookies;
>>
>> RunAsyncQueue.startPrefetching(Cookies.class);
>>
>>
>> Thoughts? The main downside I know of is the one John Tamplin has
>> pointed out: if there are multiple runAsync calls within a single
>> class -- as sometimes happens -- then the programmer has to code up
>> some new classes that will only be used for naming. Can we live with
>> that?
>>
>> Lex
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
