Here we have some best practice come from real projects. These practice suggest that do ajax in a *right* way. Please consider them in you project.
Most ORM tools bring us convenience especially dealing with object relationship. In a traditional java project, we can define a consistency domain model which can be used among the tiers. This is good even in a clustered application, because they in a same JVM and the inner state of object could be stored. But, in buffalo applications, you'd better not use this as it is *really* remote call. You should consider about the band width issue.
Let's take an example: userService.listUser, which will returns an user list, and at the same time, User have AddressInfo, have Roles, and may belongs to Department. in a traditional JSP programming, it's fine. But in buffalo, it's too bad. If you don't handle any of this situation, buffalo will try to serialize every property connected with this user, even the one to many, many to many reference data. That's a huge waste of time and band width as we don't need too much data to display.
So when designing buffalo service, please use DTO(or ViewHelper) to narrow the output for use on page only.
Please desine the remoting service method really for remoting call. If a client start a remote call, the service should reply the enough infomation at once. The client need not call other method.
Many end users including me, are confused when a web application cannot use the browser foward/back button to navigate the view. A good example is google, and bad is...MSN Live Mail. From version 1.2, buffalo introduce this feature. Please consider adopting this feature to improve user experience.
This is a general requirement for all ajax products. When user click a button or link, you should provide a significant tip noticing user what is happenning. In traditional web development, those actions will cause a page refresh or page swtich. In ajax, you should provide more.
OPOA(Chinese) defines a type of web application. Small, operation based applications always have less pages and require better interaction, such as mail application, system monitor etc. For these applications, you can use OPOA to simplify the development and provide better experience.
Because the limitation of browser capacity, large applications (which has hundreds of views) that adopting OPOA find that CPU or memory is in a high usage after running for a while. For this case, you need split the whole system into modules if you still want to use OPOA. when user switch module, will really relocate to a new page so that the browser have a chance to clean memory and have a rest.