On Thu, Oct 29, 2009 at 11:57 AM, Sumanth P K <sumanth.technical@gmail.com> wrote:

Sanjay,

I have been looking regarding the custom editor implementation. Which one from your experience in Eclipse Plugin Development is a better approach:

1) Building a Custom Editor by extending from the Eclipse Text Editor OR

>> What I understood from Ramesh is that he is looking for a simple editor which will have 4 columns, so extending the text-editor will not work. Should be a new editor with a table and cell editors to support different use-cases; more like Property View with 4 columns instead of 2 and should be a table instead of a table-tree.

2) Using the EMF approach where we define a model, tansform it into an Ecore Model and build the editor for it.

>> The effort would be too high, and also such an elaborate framework is an overkill when all we are interested to do is create/update key/value pairs with 2 more attributes.

Thanks,

Sumanth.

On Mon, Oct 26, 2009 at 10:46 PM, Sumanth P K <sumanth.technical@gmail.com> wrote:

The idea of Custom Editor looks good to me. That way the user would have the flexibility to use the editor of choice. I shall proceed in this direction.

On Mon, Oct 26, 2009 at 8:47 PM, Sanjay Chaudhuri <email2sanjayc@gmail.com> wrote:

The eclipse properties editor comes with 2 columns and that cannot be changed; so we need to have a new custom editor which will be look like the properties editor, however have 4 columns instead of 2. By default, we can wire eclipse to open up ra.xml in our own custom editor, however users can still open it up in default xml editor with the "Open With" option. If we only need to address the porperties section, we can have a table with each properties in each row.

On Mon, Oct 26, 2009 at 9:35 AM, Ramesh Reddy <rareddy@redhat.com> wrote:

On Sun, 2009-10-25 at 17:51 -0500, Sanjay Chaudhuri wrote:
> Ok; then to keep things very simple, we can have a simple editor which
> potentially can be a table/tabletree like properties view; however
> with 4 columns instead of 2, viz, key, value, type and description. I
> bring up tabletree as an option, incase you want the hierarchy to be
> visible, which I think can be important because the file is a xml and
> I saw it having a good nested structure.
>
All properties are at the same level in the ra.xml file, since we are
only dealing with properties section of the ra.xml, the tree is
optional. Once we make it hierarchical don't you have to use XMLEditor
instead of the Property editor?