Hi Stefan, Maybe because there are so many different kinds af application you can build with GWT that it's hard to say if there is any one "best practice" - perhaps there there are number of good blueprints suitable for particular types of application. But for me there are a few guiding principles I adhere to:
1) GWT, based on Java, is fully object oriented, so all OO principles apply - they are well known. 2) Use the GWT event model for sending messages between widgets, do not hold any direct internal references to peer widgets to call peer methods directly. In the face of complexity this simplifies code and makes it more robust. It also means that pieces can be easily swapped in and out of the application and it makes testing and maintenance a lot easier. This is the Observer pattern, it has stood the test of time and it avoids tight coupling between components. In practice this means that a parent widget typically instantiates and lays out its child widgets and then hooks up their event listeners etc for them, but the children have no idea who their parent is or who their peers are - they just broadcast events which other widgets might listen out for. 3) The exception to this rule is where you have a group of widgets that work very closely together for exactly one purpose - in OO parlance are highly cohesive - so that to all intents and purposes they have little or no relevance to anything outside that purpose. In this case it can be not only acceptable but probably desirable to use direct method calls between them. I'm not sure that there is an accepted name for this pattern - I've seen things like "goal-oriented windows" etc - and in GWT it is tempting to call it a Composite, but although related, GWT's Composite isn't exactly the same thing, nor is the GoF definition of it. Two examples of what I mean by this are a) a form with a number of input fields, list boxes etc, where you might want to do validation/auto-suggest work on the fields, and b) a navigation structure, e.g. a Tree, where you also have a button bar with a range of tool buttons driving functions off the tree's selected item and might need to turn themselves on/off depending on the item selected. It can be more efficient and basically easier to put everything in one class and have the individual field/buttons etc call each other directly via private access in this situation. You would typically use a GWT Composite to implement this pattern. 4) However you need to be careful with this exception and use the concept of "granularity" - a component should be neither too big nor too small, but just "right". What "right" is is matter of judgment. When I was learning C++ in college I was taught that the "right" size of a function was usually between 5 and 12 meaningful lines of code. My own rules of thumb on this are that I do not like GWT classes to have more than about 100-150 LoC max. If they go over this and the class qualifies as a "single purpose unit" then I tend to break it up using private internal classes. If it looks like it's going over about 500 LoC, then I break it up into separate public classes if I can and go back to using the Observer pattern and the event system. But this a judgement call, a matter of craft IMO rather than science and situation vary widely. 5) Decide early on whether you are after an application that looks and feels like a web page or like a desktop application. Outside of aesthetic considerations, it is technically more difficult to get a GWT UI to work perfectly completely contained within the browser's window area, resizing itself perfectly etc and it will cost you some to do so. The browsers think of everything as a document so their natural tendency is to extend the height of the document, invoking scrolling, and not to contain within the available visible client area height. if you want a desktop style app, then it's probably a good idea to do extra work up front on the overall layout mechanisms until you get it working properly. If you are used to windows style GUI programming, maybe Swing or SWT, or you are writing a business application, it can be difficult to choose on this one. At the end of the day customer perception is all, but I think that if your users will be happy with a more "web style" layout then it's probably best to go that way. I would recommend you trial some prototypes early on to find out. Ask yourself whether Google tried to copy Outlook when they made GMail. 6) Plan your asynchronous RPC calls out in the large up front and plan for them to change as you find out if your initial decisions where good - in most non-trivial apps I think some changes in approach will become necessary as real performance figures start coming in. RPC is a trade off between keeping the number of calls to a minimum whilst at the same time keeping the size the packets to a reasonable level, and no two situations will be identical. Aim for a response time of <1s except for situations where that is clearly not practical, such as uploading a 20MB PDF file or performing a complex query on a large database, in which case show an obvious clear message describing what's going on. Pinpoint any situation where you might get a large number of items returned for display, e.g. in a tree or a data grid, and plan for staggered (or lazy) retrieval, e.g. use a PagingTable. Thus is not just an issue of network load, it is also that GWT widgets use up a lot of HTML "boxes" and it takes browsers an appreciable amount of time to draw thousands of them. 7) Keep as much session state as possible on the client. Application servers and servlet containers use up a lot of resources mainaintaining user's session state across a server cluster, so they work much faster if they don't have to do this. Aim for a stateless server. 8) Always use ImageBundle to get your images across to the client - it puts them all in a single image strip for transfer across the network and this makes a big difference to start up times since otherwise each image is fetched using a separate HTTP call. You asked about "high performance", and I think the key issues above that relate to it are the last four, 5,6,7 & 8. The more "desktop" like or "fancy" you make you UI the less quickly it will tend run. The way you handle RPC calls can have an *enormous* impact on your user's perception of performance. 7 & 8 are self explanatory, but they also make a serious difference to performance. I do not believe that static and final have any appreciable impact on performance at all, except that in certain limited cases the use a the Singleton pattern can be both useful and improve performance, and that is based on static. Regarding the size of GWT js files, aside from the fact that they heavily optimized for you by the GWT compiler, as I understand it after the first download to a particular client they will be cached by the browser. The browser will subsequently request the app's HTML file, note the js include, and check with the server if it has changed since the data stamp on its cached copy and use the cached version if possible. I think Google have got this about as right as it could be got and I would leave that side of things to GWT itself, certainly initially, as I don't think there's much you can do yourself that will make any noticeable difference - just program naturally in Java. The stuff I brought up in 5-8 are however totally up to you, and they really do make a big difference to performance. regards gregor On Sep 29, 2:46 am, wt <[EMAIL PROTECTED]> wrote: > Take a look at this thread, which is about puremvc4gwt and read the > puremvc best practice doc. That should give you an example on how to > organize the client code. > > http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa... > > On Sep 25, 4:44 am, Stefan <[EMAIL PROTECTED]> wrote: > > > Hi, > > > Does anyone know any good resources for "Best practices" when writing > > GWT apps? Questions I would like to have answered: > > > * How to I write high-performing apps? I know that the compiler helps > > out, but how do I write code that helps the compiler to minify/ > > optimize my app? > > * How does "static" and "final" assignments affect the performance of > > apps? > > > Thanks in advance! > > Stefan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
