Community
Participate
Working Groups
Created attachment 140573 [details] overview diagram The goal is enabling the end user to store snippets that are not text based and have some complex logic behind them. Some examples are storing common JPA model, JSPs, Configurations that can be reused in several projects. Current implementation is based only on text snippets, but in my opinion can be easily extended so it can cover any scenario. The implementation should be also extensible, so different vendors can benefit from the snippets view in their proprietary solutions. I have made initial overview diagram of the idea.
An explanation of the concrete user and plug-in developer scenarios would be useful, as it's already possible to do this as a plug-in developer using a custom insertion class and your own transfer type. Exactly how an end-user would construct snippets employing more complicated logic is something I'm curious about.
I will try to explain in use cases: Developer/End User: want to draw a diagram using Custom/Vendor specific GEF Editor for example and JPA Entity model. And the user wants to save this model as a snippet, so she can reuse it later in another project. I know about the insert mechanism, but in this case it is not enough, since it is missing logic for storing in this case the JPA Model and logic to reproduce it on insert. My idea is to have the snippet framework extensible so vendors (plugin developers) can write "Providers" that are able to deal with certain object from certain editor, and provide insert and save action. The plugin developer should enable the user to work on certain editor with the snippets view. The plugin developer should specify enablement and provider class in extension point. Enablement is for on which editor the provider will work. The provider class should implement in my opinion 2 methods: one that will save additional content something like: IStatus saveAdditionalContent(IPath path) and one that returns ISnippetInsertion class: ISnippetInsertion getSnippetInstertion() I am working on a prototype separates current Text based logic in a TextSnippetProvider and creating JPA Entitties Provider, I can record a short video of what I have done till now. I am trying to do this easy for the plugin developers and trasparent for the end users. So the plugin developers should implement save and insert. End users will work with the snippets view in the same way they use it in text editors.
Created attachment 141047 [details] initial version of the core funcionality what is in the patch: 1. New Extension point for registering snippet providers. 2. Text based logic for insert and add to snippets is moved in TextSnippetProvider 3. Some manager classes are created to deal with extension points and applicability for the providers. 4. Providers have priorities similar to the ModelProviders. 5. SnippetTransfer based on ByteArrayTransfer is added for drag and drop. 6. New property is saved in the user model (id of the provider) - I am thinking of removing that if possible 7. Fallback to TextSnippetProvider if other provider fails. Some info about the extension point It has provider class that in most cases should extend AbstractSnippetProvider (ISnippetProvider is for greater freedom) Priority - if more then one Provider is applicable for certain editor, the one with lowest priority will be chosen. Enablement - based on org.eclipse.expressions on which editor is the current provider active.
Created attachment 141048 [details] some junit tests here are some junit test that are added to test the new functionality.
Dimitar, or others, I know you said you'd want this for "...Custom/Vendor specific GEF Editor ..." but I'm curious if anything in WTP could or should take advantage addition? I partially ask out of pure curiosity, but also because it's harder to provide an API if we (WTP) do not actually make use of it. If we don't really make use of it, perhaps a small "example use" could be provided for one of the Graphical editors in WTP? [And, sorry if how to do that is obvious to others, or already included in JUnit tests ... I've just scanned over this bugzilla and that question came to my mind.] Thanks.
Hi David, Providing meaningful example in eclipse is our next step :) I am currently researching some graphical editors that can take advantage of this functionality. And hopefully will have some basic implementation soon.
Created attachment 144819 [details] added support for import export and delete of complex snippets
Created attachment 144823 [details] adds snippets support for faces config xml navigation view This is an example how the new functionality could be used. Here in faces config xml one can add to snippets part of the navigation along with the jsps (using context menu). the jsps then can be inserted in any other project. The jsps will be inserted in the same place they were taken and the navigation rules will be added to the xml. (I did not have enough time to add DnD)
Nitin, did you have the time to review this contribution? We hoped to have this in the WTP December 2009 release, but because it was canceled, David mentioned that it could be included as exception in the Galileo SR1 release. Before we can discuss this we need to have the provided patches reviewed.
(In reply to comment #9) > We hoped to have this in the WTP December 2009 release, but because it was > canceled, David mentioned that it could be included as exception in the Galileo > SR1 release. Before we can discuss this we need to have the provided patches > reviewed. I think that needs discussion regardless of the patches being reviewed.
Created attachment 146236 [details] modified and combined patches Most of it looks alright to me, but I have a few questions and observations. There's already a SnippetTransfer class used for clipboard operations; having another with the same name for use with drag and drop is confusing. And is there a reason to use this for drag and drop instead of org.eclipse.jface.util.LocalSelectionTransfer? I've left this as-is pending your thoughts. There are opportunities for optimizing class-loading and plug-in activation that could be done through ID strings. Most problematic here, for me, is org.eclipse.wst.common.snippets.internal.SnippetContributor.getPrio()--allowing extensions to return priorities invites abuse. Was 0 made the highest priority to try in an attempt to avoid this? The SnippetProvider extension point uses "impl" instead of the somewhat standardized "class". I changed it. Additionally, are there any provisions for cleaning up the storage area? If a snippet is no longer contributed in a future release, its metadata content should go away cleanly. And the new SnippetManager#moveFilesInStorageFolder(IPath, IPath[], IProject) and SnippetManager#moveFilesInWorkspace(File[], IProject, IPath) aren't used in the snippets plug-in or tests; they are better placed in the JSF extension plug-in. I also fixed a few typos, expanded some abbreviated method names (e.g. I favor getPriority() over getPrio()), and moved the snippet storage into a subdirectory of the plug-in's state location. org.eclipse.wst.common.snippets.core.ISnippetProvider will need documenting, and I think ISnippetProvider#isActionEnabled(ISelection) could use a name better fitting to something in a core package. I'd also like you to review the edit permissions in the customizer dialog for the snippets that come from the providers; it may need to do a item.setSourceType(ISnippetsEntry.SNIPPET_SOURCE_PLUGINS) in AbstractSnippetProvider#createSnippetMetadata(PaletteEntry) before returning.
thanks for the feedback. SnippetTransfer - I will see what I can do to improve the situation there. Prio - I have specifically done this to avoid plugin activation, that is why the initialization of SnippetContributor is done in 2 steps. the idea is to have maximum flexibility and the consumers to be able to override the default behavior, in my opinion this is nice to have, but not essential. I can remove it. About the cleaning up - there is a mechanism that deletes the generated additional content on remove of the snippet. SnippetManager#moveFilesInStorageFolder are purely helper methods for the providers, I am reusing them in 2 snippets that I have prototyped, one is SAP specific. I think if they are a little bit polished, they will be in great help for the contributors. All interface methods and the extension point will be documented. ISnippetProvider#isActionEnabled(ISelection) could use a name better fitting to something in a core package - Agree I will research. about the edit permissions in the customizer dialog - I will check. I will get back to you when I address at least some of the issues
Created attachment 146652 [details] polished - java doc, removed snippet transfer, exception handling improved SnippetTransfer - removed only one remains, Prio - left it unchanged if you wish I will remove it. Provided documentation and javadoc. ISnippetProvider#isActionEnabled(ISelection) could not find better place for it, since it is provider specific, every provider should state that the add to snippet action will be available or not (for example there is no selection of text) about the edit permissions in the customizer dialog - looks OK users should be able to add additional information like variables about the snippet, that can be really handy, the only thing is the code snippet area that is currently not needed in some cases.
(In reply to comment #13) > about the edit permissions in the customizer dialog - looks OK users should be > able to add additional information like variables about the snippet, that can > be really handy, the only thing is the code snippet area that is currently not > needed in some cases. I have to emphasize your last point and ask that they be disabled for anything having a provider other than the text one--unless we want to enforce that all providers have to support the variables.
From what I have imagined and tested variables are stored correctly no matter of the provider. However as you said there is not much sense in allowing the user to add variables since this is hard to be predicted by the provider. I think the provider should be able to add variables and maybe supply default values. Another approach is that the provider can say if it allows additional variables to be add by the user. Which approach do you think will be best?
(In reply to comment #15) > However as you said there is not much sense in allowing the user to add > variables since this is hard to be predicted by the provider. I think the > provider should be able to add variables and maybe supply default values. > > Another approach is that the provider can say if it allows additional variables > to be add by the user. > > Which approach do you think will be best? I think it's out of place being something asked of a provider by the framework. If support for variables is there at all, it is an internal detail of the provider. I would lean toward that being something internal and specific to the text provider. Any further thoughts on enabling the provider to supply a Control to be shown in the customizer dialog?
In the last day, while I was working on this I realized that may be the best approach is to provide possibility for the SnippetProvider to supply UI for customize dialog, I think in this way we will be open for enhancement. The text provider will provide the VariableItemEditor. What do you think? One more think the snippet text area in customize dialog has a label Template Pattern, which is a bit confusing. Maybe only Template will be more appropriate?
Created attachment 148521 [details] javadoc and disable of variables for provider based snippets somehow I have lost some changes and attached wrong patch for javadoc and the fixes. Here is the original fix for java doc and snippets transfer + changes for customize dialog.
Created attachment 148523 [details] updated the faces config implementation according to the latest patch
(In reply to comment #17) > In the last day, while I was working on this I realized that may be the best > approach is to provide possibility for the SnippetProvider to supply UI for > customize dialog, I think in this way we will be open for enhancement. The text > provider will provide the VariableItemEditor. > > What do you think? I think that'd work well. > One more think the snippet text area in customize dialog has a label Template > Pattern, which is a bit confusing. Maybe only Template will be more > appropriate? Depends on where that string comes from. Parts of the UI are inherited from the GEF superclass.
It is in a property file in the snippets plugin.
Nitin do we have something more to improve here?
No, I think we're good here. I'm a little nervous about putting it in this week, though. Early M4 ok?
sounds good. We can test it more thoroughly then.
I'd swear I've added an M4 target milestone and field value to Common twice now, but it's still not there.
Released with the following changes from attachment 148521 [details]: -extension schema's "priority" attribute is optional -SnippetContributor#priority defaults to 100 (lowest) instead of zero -plug-in version bumped up to 1.2.0 -AddToSnippetsEditorActionDelegate restores several (now deprecated) methods for binary compatibility -"Template Pattern:" label in customizer dialog is now just "Template:" -SnippetCustomizerDialog#copyInputStream(InputStream, OutputStream) made package protected instead of public -SnippetCustomizerDialog#unzip(ZipFile, String) made package protected instead of public -ISnippetProvider#getCustomSnippetEditor() is now ISnippetProvider#getSnippetEditor() Thanks for all your work, Dimitar.
