+1 on rewriting the search bar using SmartGWT widgets.

Responses to Mike inline below...

On 06/04/2012 03:29 PM, mike thompson wrote:
The most dangerous aspect to the current search bar solution is that it has its own entry point; which effectively makes the search bar an application itself and we have problems with events between the two "separate" applications. We have:
1) CoreGUI.java EntryPoint for SmartGWT application
2) SearchGUI.java EntryPoint for GWT search application

Essentially, two separate event loops (one for each application). They work independently along side one another; there is no real event overlap so things work reasonably well. Deeper interactions between GWT and SmartGWT will become problematic however. So its best to unify this event model under smartGWT now before interactions get more complex.

NOTE: I don't believe the gwt widgets need their own module (EntryPoint). The gwt widgets could also be added to a Canvas or CanvasItem as a child with less side effects (http://forums.smartclient.com/showpost.php?p=33052&postcount=10)



The reason for the separate entry point is because pre JON 3.0, we actually embedded the GWT search bar in portal-war JSF pages - sort of the opposite of how we embed JSF iframes in some of our coregui GWT views. Since, we no longer use any of the portal-war pages that use the search bar, I think we can definitely do away with the separate entry point. This could be done as an intermediate step in advance of a complete rewrite of the search bar in SmartGWT.


As for the charting, we can minimize the effects of events especially if the charts are read-only or only allow hover.  There is improved html 5 charts in smartgwt 3.1: http://blog.isomorphic.com/smart-gwt-3-1-smartclient-8-3-feature-roadmap/ so we will have to see what the html 5 canvas support is. This is really a whole other topic though (a good thread of its own).


Unfortunately, I don't think any of the SmartGWT charting stuff is included in the LGPL/free edition of SmartGWT.


-- Mike Thompson