John,
I agree with you, I expect we may end up with some challenges with the
charting. The difference I see is just that we have no choice with the
charting and we do have a choice with the search bar.
I have yet to look at dkrusko's charting investigation, I'll do that
soon, but poking around I see that GChart gets some use, and on the
forums the Isomorphic guys actually seem to try to help when people have
issues.
On 6/4/2012 2:38 PM, 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(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
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel