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)

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).

-- Mike Thompson


On Jun 4, 2012, at 11:38 AM, John Sanda wrote:

This is slightly off topic. On the one hand, I absolutely agree that a rewrite in SmartGWT makes sense due to the event model mismatch. But on the other hand, if we cannot find a way to successfully use native GWT components along side SmartGWT, what kind of options does that leave us for graphing solutions. Maybe it is an apples to oranges comparison. I just don't want us completely avoid native GWT components/libraries across the board as that would severely limit our options for graphing solutions. To reiterate though, I am very much in favor of this rewrite effort.

- John

On 06/04/2012 10:51 AM, John Mazzitelli wrote:
we need this re-implemented in smargwt. I'm a +1 in getting that done. It is one of the most important custom components in our UI, it should be using smartgwt along with everything else.

----- Original Message -----
I tried a while back to get around that "lost click" issue but
eventually accepted that this was just a GWT/SmartGWT event model
conflict.  Although reimplementing will be a bit of work, I think we
need to do it.  The search bar is a critical component to the GUI and
needs to work as designed.

A reimplementation should be careful to maintain hooks for adding
Search
capability to various pages.  Perhaps it could even be enhanced.  For
example, it might be nice to have a search bar on the "Inventory"
landing page.  I'm not sure that's possible today as I think we can
only
embed it in a Table view.  (I wouldn't go out of my way to support
this,
though).

Certainly it must maintain the same sort of incremental preview list,
as
well as saved search support.

I'm not sure if this re-work could at all lend itself towards using
the
search bar syntax for dynagroup definitions.  Again, I wouldn't go
out
of my way for this, it was just a thought.

On 6/4/2012 10:41 AM, mike thompson wrote:
The Search Bar Bug -- Search bar saved searches menu ignores clicks
[https://bugzilla.redhat.com/show_bug.cgi?id=733487] appears to be
occurring because of GWT/SmartGWT event mismatch. It is advised in
the
SmartGWT document not to mix GWT with SmartGWT.

The proposed solution here is to remove the native GWT widgets from
the codebase and re-implement the search bar functionality using
pure
SmartGWT widgets. This is the only case of native GWT widgets in
the
codebase so after removal of the search bar the code base would be
free of any native GWT widgets and will hopefully have a little
cleaner event model.

Here is the specs for the search bar:
http://rhq-project.org/display/JOPR2/Search

https://bugzilla.redhat.com/show_bug.cgi?id=733487


Any opinions on this?



-- Mike Thompson


_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel

_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel

_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel