Search Bar reimplementation in SmartGWT

mike thompson mithomps at redhat.com
Mon Jun 4 19:29:22 UTC 2012


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 at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>> _______________________________________________
>>> rhq-devel mailing list
>>> rhq-devel at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>> 
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://fedorahosted.org/pipermail/rhq-devel/attachments/20120604/990cb6c9/attachment.html>


More information about the rhq-devel mailing list