litesoft
Diff Revisions
560
vs
561
for /trunk/Documents/GWT_Talk
|
@@ -50,35 +50,10 @@ |
50 |
50 |
|
|
51 |
51 |
|
Wednesday: |
52 |
52 |
|
|
53 |
|
- |
7:15am - 8:00am |
|
53 |
+ |
5:50pm - 6:50pm |
54 |
54 |
|
|
55 |
|
- |
x:00pm - x:00pm |
|
55 |
+ |
Thursday: |
56 |
56 |
|
|
57 |
|
- |
------------------------------------------------------------------------------------------------------------------------------------ |
58 |
|
- |
|
59 |
|
- |
The Primary purpose of this app was to demonstrate how to use the GWT concepts of Place/Activity/View with the RunAsync mechanism of GWT. |
60 |
|
- |
Thus allowing for splitting up the GWT generated JavaScript into a Core chunk and a number of load on demand (or Lazy Loaded) chunks. |
61 |
|
- |
|
62 |
|
- |
It is my understanding that direct calls between Lazy Loaded chunks (and from the Core to the Lazy Loaded chunks) was not possible, but |
63 |
|
- |
that once a Lazy Loaded chunk had registered an implimention of a Core interface with the Core, then either the Core or any Lazy Loaded chunk's |
64 |
|
- |
code could call the interface whenever the registered interface can be retrieved. This suggests that an optimal "fracture point" between the Core |
65 |
|
- |
and the Lazy Loaded code is the Activity. This is exactly what the GWT Large Application best practices documentation suggests (specifically |
66 |
|
- |
bundling a Place's Activity/View pair behind a RunAsync method). Obviously, this means that any Lazy Loaded Activity/View pair is NOT |
67 |
|
- |
available for direct synchronous calls. Unfortunately, this implication at the end of the GWT Large Application best practices documentation |
68 |
|
- |
invalidates the author's earlier recomendation to have all the Views sychroniosly accessable in the ClientFactory. |
69 |
|
- |
|
70 |
|
- |
The recogmended start up infrastructure code when using the Place/Activity/View approach is: |
71 |
|
- |
|
72 |
|
- |
xxx |
73 |
|
- |
|
74 |
|
- |
With GWT providing these classes: |
75 |
|
- |
|
76 |
|
- |
xxx |
77 |
|
- |
|
78 |
|
- |
And the App developer providing concrete implimentations of these classes/interfaces: |
79 |
|
- |
|
80 |
|
- |
xxx |
81 |
|
- |
|
82 |
|
- |
However, the ActivityMapper's getActivity( Place ) method expects to return an Activity sychronously (it does not utilize a Call Back |
83 |
|
- |
mechanism to support asynchronous creation of the Activity). |
|
57 |
+ |
6:50am - 7:25am |
84 |
58 |
|
|
|
59 |
+ |
------------------------------------------------------------------------------------------------------------------------------------ |