Bug 73426 - setData editor
Summary: setData editor
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: VE (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 2000
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: David J. Orme CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-08 00:06 EDT by Pramod Varma CLA
Modified: 2011-06-13 11:38 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pramod Varma CLA 2004-09-08 00:06:22 EDT
We are developing enterprise business applications UI based on RCP. UI layer 
uses web services to connect to a J2EE backend and calls our services that take 
input and output in XML.

As part of our UI infrastructure, we have a common library to bind values from 
XML (our model) to the UI controls by specifying data bindings (as XPath 
strings) at control level. We would like to see a way to specify multiple name-
value String pairs that gets put into the widget using setData. Basically a 
setData editor (for String name-value pairs) within property editor. If we hand 
write the code in source editor it looks like this: 

Text txtOrderNo = new Text(pnlParent, SWT.BORDER); 

txtOrderNo.setData("yfc:DataType","OrderNo"); // our app has a common meta data 
repository for base and user defined data types 

txtOrderNo.setData("yfc:Binding","/Order/@OrderNo"); 


Of course we can do all these manually in source editor. But the whole point is 
that a visual designer should really try to eliminate the need to go back and 
forth between design and source mode to fix all these. 

I'd greatly appreciate your take on this.
Comment 1 David J. Orme CLA 2004-09-08 10:09:13 EDT
Gili: This is a good idea (and we need it to fully support Essential Data as
well).  We use setData() in ED for exactly the same purpose as these guys
are--to specify control-data bindings.

Is this a 1.0 or a 1.1 feature, though?  (Pramod, we're right about to declare
feature freeze for 1.0 right now, so we've got to be careful about what we put in.)

Thoughts?
Comment 2 Gili Mendel CLA 2004-09-08 11:01:25 EDT
This will require some work... for a beginner, we could not treat this as a
2-way "property", since we could only set it once (last value will be in the
model).. where as, you will require a sequence of settings (diff. arguments) to
the same "property" data.

... so what make sense here, is providing something like a method invokation
support setFoo(args)., where once can contribute a context menu action ... but
how will you visualizej the set of method invocations on the JavaBean View/FF if
any??

Need some thinking
Comment 3 Pramod Varma CLA 2004-09-29 01:48:21 EDT
Gili, David

Any update on this? We have started using VE 1.0 and it is working out very 
well. We still shift back and forth between source and editor for coding 
setData on controls. We ONLY need setData with String arguments. Is there a 
possibility of adding it to 1.1? Thanks.

Regards, Pramod.
Comment 4 Gili Mendel CLA 2004-09-29 08:25:48 EDT
Reference this defect in the ve mailing list; there are a few options, with
merits, flaws and effort level, be nice to get other's point of view.

You can personally hard code a decoder to work with a fluffed up "data" property
to deal with fact that data is not really a property.

You can define the "data" to be a indexed property (we do not support index
properties, but this will be a general JavaBean support)... as use it as such.


We may have to provide generic support to method invokation for one to extend
and use the semantics you need.
Comment 5 Pramod Varma CLA 2004-11-18 23:12:28 EST
I looked at VE 1.0.1.1 and it's "data" property editor. But, that still does 
not solve my problem of associate String name-value pairs to widgets. 

I had posted on VE mailing list as you suggested and did not receive any 
serious response.

Any update you guys can give me on this? Thanks.
Comment 6 Gili Mendel CLA 2004-11-19 07:56:24 EST
The simplest manner to get this working for now is to use a JavaBean with all of
your keys (e.g., Binding, DataType etc), and set the data to this bean.  You
could than use the PropertySheet to specify particular settings, or override the
Data property editor to be a specialize  one to deal with this new JavaBean.