On 10/07/2015 09:53 AM, Angelo zerr wrote:
2° Delegate JavaScript features to other components liek tern
On this topic, I suggest the following changes in JSDT that I find as
working enough for my experiments regarding merging Tern Outline into
JSDT Outline:
* Remove some extension points that are covered by upstream frameworks.
Mainly the Common Navigator, which makes it easy to write an extensible
Outline or a Quick Outline, without need to add other extension points.
For example, the "javaScriptElementFilter" extension point could be
replaced by usage of the commonFilter.
This is not a critical issue for extensibility, but removing code in
JSDT without loosing funcitonality nor extensibility is something that
we'll all see as a good thing.
* Take advantage of adapters: in most classes where we want to have
extensibility, JSDT directly uses or casts to its types
(IJavaScriptType, IJavaScriptUnit, IJavaScriptElement...). Extenders
projects may not use directly these types but might be able to adapt to
the specified types relying on the Core adapter framework. By leveraging
that and checking for adapters when possible, several pieces of JSDT
code would remain working with the parts of extending frameworks.
Current JSDT Outline filters are an example: Tern can provide its own
richer elements to Outline, but since they're not JSDT types, filters
don't work. Assuming JSDT would check for adapters and Tern would
provide adapters, filters would remain working even with Tern content.
We can imagine similar thing for refactorings, search and others.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/wtp-dev
