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