All good points.
Would interfaces be supported as well ?
Are there any dangers of allowing arbitrary classes (or interfaces) to be
used as monikers ?
i.e from your example, would there be anything wrong with using
EmailCompositionView.class as the moniker ?
void onComposeButtonClicked() {
> GWT.runAsync(EmailCompositionView.class, new AsyncCallback() {
> public void onError(Throwable e) { ... }
> public void onSucess() {
> new EmailCompositionView().activate();
> }
> });
>>
>>
I guess the compiler would have to verify that each call to runAsync uses a
unique moniker - is there anything else ?
Must the moniker class exists in your own module ?
Would you only allow leaf classes to be used as monikers, i.e. could you use
OfficeSuiteSplitPoint.class as a moniker ?
Cam
2009/6/25 Bruce Johnson <br...@google.com>
> 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
-~----------~----~----~----~------~----~------~--~---
