Bug 370516 - Add a script/code property editor
Summary: Add a script/code property editor
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Sapphire (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 372816
Blocks:
  Show dependency tree
 
Reported: 2012-02-02 21:50 EST by Greg Amerson CLA
Modified: 2021-11-19 09:22 EST (History)
1 user (show)

See Also:


Attachments
Patch #1 (31.92 KB, patch)
2012-02-06 04:04 EST, Greg Amerson CLA
no flags Details | Diff
sapphire-gallery.xml (705 bytes, application/xml)
2012-02-06 04:08 EST, Greg Amerson CLA
no flags Details
patch-2 (requires patch-1 on bug 372816) (26.99 KB, patch)
2012-02-29 00:51 EST, Greg Amerson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Amerson CLA 2012-02-02 21:50:21 EST
Currently sapphire has property editors for simple text, long text, and html.  It would be nice if there were a way to support editing blocks of code or script.  The specialites of a code editor would be things like line numbers, syntax highlighting, and other enhanced editing capabilities.
Comment 1 Greg Amerson CLA 2012-02-02 21:52:59 EST
I have a prototype of this type type of property editor that embeds a ITextEditor where a normal Text control would be in the case of a normal sapphire value property editor that uses a textbox.  However, in my prototype I'm just activiting a custom property render as a factory hint.  How would we want this to be done in the framework or how would this code/script editor be activated?  By annotation or do we want the user to activate the code editor via the factory hint?
Comment 2 Konstantin Komissarchik CLA 2012-02-02 21:55:15 EST
Let's start with just the factory hint. Once the new property editor is fairly complete, we can discuss automatic activation strategy.
Comment 3 Greg Amerson CLA 2012-02-02 22:05:16 EST
So for the first step in the contribution do we want to just hardcode the platform default textEditor or do we want to discuss a strategy for finding the right "ITextEditor"?
Comment 4 Konstantin Komissarchik CLA 2012-02-02 22:09:49 EST
I think we will need some way to specify the content type. The part that makes this experimental to me is that I am not sure how many editor implementations will play nice with this embedding. Which ones have you tried so far?
Comment 5 Greg Amerson CLA 2012-02-02 22:47:02 EST
I've tried default TextEditor which works fine.  I've tried the JavaEditor with groovy extensions to edit a groovy script.  The editors are not as full featured as their Full editorPart counter parts.

I plan on trying a few more soon, like JavaScript.  Eventually I may even bundle a basic syntax-color and code folding editor that support like this one:  http://www.gstaff.org/colorEditor/
Comment 6 Greg Amerson CLA 2012-02-02 22:50:01 EST
But those additional editors are for my adopter product, for the framework, perhaps we should just stick with platform textEditor and maybe give an option for adopters to turn on the contentType queriying? So if they know it will work (because they have tested it, etc) they could turn the querying on?
Comment 7 Konstantin Komissarchik CLA 2012-02-02 22:53:24 EST
Is there a clear advantage of plain text editor over a plain text box? I would be most interested in including this feature in Sapphire if it can be demonstrated to work well with at least one or two prominent source editors... Perhaps Java and XML for starters?
Comment 8 Greg Amerson CLA 2012-02-02 23:48:26 EST
The advantages for platform text editor over basic text box are not overwhelming but still somewhat better:
- line numbers
- shift/right left actions
- whitespace handling
- spellchecking

But I agree, the JavaEditor, XML Editor would be good litmus tests.  I've tried both JavaEditor and XMLEditor locally and both seem to embed without errors, not for sure how fully functionaly their features, would require more poking around.  

In my prototype the nested editors don't have all fo their global actions wired up correctly so not all keybindings work or popup everything you would expect, but some of that is likely just due to my incomplete prototype at this point.
Comment 9 Konstantin Komissarchik CLA 2012-02-03 12:43:54 EST
That's encouraging.

To move forward with evaluating the feasibility of this, let's add @ContentType annotation, but it's unlikely to be the final form of this feature's enablement. Need to think through of how this should logically interact with the existing @Type facility.
Comment 10 Greg Amerson CLA 2012-02-04 09:02:17 EST
Do you have a preference on what this should new class/capability should be called?  CodePropertyEditorRenderer, SourcePropertyEditorRenderer?  ContentTypePropertyEditorRenderer
Comment 11 Greg Amerson CLA 2012-02-06 04:04:15 EST
Created attachment 210556 [details]
Patch #1

Here is a patch for prototype of this feature.  Here are a few FYIs...

- renderer is called CodeValuePropertyEditorRenderer.  I'm open to alternative names, Script, Source, Content, ... I just went with code for first prototype.
- Added a new top level adapt method to SapphirePart so that in this new property editor renderer I can grab a reference to the IEditorSite with a simple getPart().adapt() call.  


This prototype is missing the following items to be complete:

- changes to sapphire model from source editor don't propagate back to embedded ITextEditor
- still need dispose/cleanup of embedded text editors.

Known issues

- in the case of XmlEditor, instead of StructureTextEditor embedded, it embeds a MultiPageEditorPart, so you have the unneeded design/source tabs, need to determine best method for handling this case.
- there are some focus handling issues when multiple editors on same details page
Comment 12 Greg Amerson CLA 2012-02-06 04:08:57 EST
Created attachment 210557 [details]
sapphire-gallery.xml

Sample sapphire gallery to show new code properties
Comment 13 Greg Amerson CLA 2012-02-29 00:51:32 EST
Created attachment 211778 [details]
patch-2 (requires patch-1 on bug 372816)

This is a new patch with the SapphirePart adapt() mechanism removed (which has been added to bug 372816