Home » Eclipse Projects » Eclipse Platform » Generalizing CellEditor
|
| Re: Generalizing CellEditor [message #332746 is a reply to message #332735] |
Fri, 07 November 2008 13:42   |
Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 11/6/2008 8:09 PM, Cameron Bateman wrote:
> Has anyone ever looked into the idea of generalizing CellEditor for use
> outside of properties view? The CellEditor abstract base class provides
> a very elegant MVC way of doing property editing. When I look at doing
> property editing in another context, such as a UI forms-based editor,
> CellEditor has everything I want in terms of change events,
> selection-based action support and input validation.
> In fact, if not for the "activate/deactivate" part of its lifecycle, I
> could probably use it directly anywhere I want to do property editing.
I'm not sure what you mean; CellEditor is usable in any TableViewer (and
TreeViewer, I think). It is not specific to the Properties view.
If you're looking for a general (non-table-specific) editing capability,
have you looked at JFace Data Binding? It is very nice for doing the
model <-> GUI linkage including conversion, validation, etc.
Eric
|
|
|
| Re: Generalizing CellEditor [message #332778 is a reply to message #332746] |
Fri, 07 November 2008 20:07 |
 Cameron Bateman
Messages: 481
Registered: July 2009 |
Senior Member |
|
|
> I'm not sure what you mean; CellEditor is usable in any TableViewer (and
> TreeViewer, I think). It is not specific to the Properties view.
ASIDE: Actually, in combination with ControlEditor, I've found that you
can use it anywhere, although not always pleasingly. The only thing that
seems to be tableviewer specific is the activate method that takes a
ViewerCell event.
> If you're looking for a general (non-table-specific) editing capability,
> have you looked at JFace Data Binding? It is very nice for doing the
> model <-> GUI linkage including conversion, validation, etc.
Yes, this is more what I mean. I have looked at Data Binding and think
it's a really good API. But (correct me if there's something I'm missing
something) it lacks the view part of the MVC puzzle.
Consider for example that with EMF.Edit I can effectively generate editing
UI for any data type in my model. I can do this because CellEditor
provides an abstraction in createControl and the way it wires underlying
controls up to the CellEditor lifecycle (such as the way
editorValueChanged is fired when a change is made to the control) that
allows EMF to automatically generate editing UI without me knowing or
caring how it binds to my model.
It seems like there is a common abstraction of a PropertyDescriptor that
could be shared between CellEditor and DataBinding that would allow the
same code that works for cell editors to also work (although more
robustly) with data binding.
Thanks,
Cameron
|
|
|
| Re: Generalizing CellEditor [message #332780 is a reply to message #332778] |
Fri, 07 November 2008 20:46 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Cameron Bateman schrieb:
>> I'm not sure what you mean; CellEditor is usable in any TableViewer
>> (and TreeViewer, I think). It is not specific to the Properties view.
>
> ASIDE: Actually, in combination with ControlEditor, I've found that you
> can use it anywhere, although not always pleasingly. The only thing
> that seems to be tableviewer specific is the activate method that takes
> a ViewerCell event.
>
>> If you're looking for a general (non-table-specific) editing
>> capability, have you looked at JFace Data Binding? It is very nice for
>> doing the model <-> GUI linkage including conversion, validation, etc.
>
> Yes, this is more what I mean. I have looked at Data Binding and think
> it's a really good API. But (correct me if there's something I'm
> missing something) it lacks the view part of the MVC puzzle.
Really? What do you miss in the MVC? V is your SWT/JFace-Widget, M is
EMF, C is databinding (Conversion, Validation, ...)?
>
> Consider for example that with EMF.Edit I can effectively generate
> editing UI for any data type in my model. I can do this because
> CellEditor provides an abstraction in createControl and the way it wires
> underlying controls up to the CellEditor lifecycle (such as the way
> editorValueChanged is fired when a change is made to the control) that
> allows EMF to automatically generate editing UI without me knowing or
> caring how it binds to my model.
Do you know about EMFDatabinding-Bundle?
>
> It seems like there is a common abstraction of a PropertyDescriptor that
> could be shared between CellEditor and DataBinding that would allow the
> same code that works for cell editors to also work (although more
> robustly) with data binding.
>
Isn't EMF-Databinding filling exactly this gap?
>
> Thanks,
>
> Cameron
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: Generalizing CellEditor [message #332785 is a reply to message #332780] |
Fri, 07 November 2008 22:39 |
Cameron Bateman
Messages: 481
Registered: July 2009 |
Senior Member |
|
|
> Really? What do you miss in the MVC? V is your SWT/JFace-Widget, M is
> EMF, C is databinding (Conversion, Validation, ...)?
But what if I don't want to know about the details of the SWT/JFace
widget? With the CellEditor, if I know my type is a String, I can ask for
a TextCellEditor. If it's a collection of enumerated values, I can get a
ComboBoxCellEditor. I need know very little (or in many cases nothing)
about what SWT control needs to be created or how it gets wired up.
If I layer EMF.Edit on top of that, I need to know even less. If the
model knows that the type is an enum, *it* will create the
ComboBoxCellEditor and as long as I'm happy with the defaults, "it just
works".
> Do you know about EMFDatabinding-Bundle?
Yes.
> Isn't EMF-Databinding filling exactly this gap?
It helps, but there is no adapter factory to support databinding. I could
write one, but it seems like there should be a way to reuse the
IPropertyDescriptor and IPropertySource information that already exists to
create property editors that also support JFace data-binding.
Thanks,
Cameron
|
|
|
Goto Forum:
Current Time: Sat Dec 21 17:11:17 GMT 2024
Powered by FUDForum. Page generated in 0.03529 seconds |
] 
Search
Help
Register
Login
Home
