Skip to main content
Jump to: navigation, search

PDT/1.1 RequestedFeatures

Revision as of 13:02, 23 February 2008 by (Talk | contribs) (RequestedFeatures moved to PDT/1.1 RequestedFeatures: renamed for consistency w/ PDT 1.5 documents & to add automatic breadcrumbing)

High Level Plan for PDT v1.1


Though the current modeling framework has sufficed for the first couple of releases of PDT, some issues have been raised that can't be dealt with continuing down the same path that we have been pursuing. Our current modeling technique is lacking in a few key areas:

  • Performance (hold everything always) - We are kind of optimistic on our users' computer. During the workspace build process we are keeping superfluous data, performing type resolving information that is out of scope. We don't use any index for search mechanism, so everything is kept on the heap.
  • Scalability - Events for model change are too lose, if someone changes the layout of a file the build mechanism is operated and the whole file is deleted and inserted.
  • Not JDT way - The resource presentation that is used in the JDT project is better in many aspects. Any resource in the workspace has a presentation in the model. This is a better way doing things in Eclipse.
  • Soft Typing is not used - There are many techniques to soft type resolving. Currently we are conservative in our approach.
  • Resolve types without hinting - we should do more to resolve some of the elements like fields, methods and functions without expecting the user to give us the answer.
  • Resolve primitive types - we don't resolve primitive types like string, number, date, etc.

As you can see, this covers a variety of areas and concerns. Our goal is to provide enough options that users gain the power of extensibility and productivity.


At a high level for PDT v1.1, we're going to try and focus on these main areas:

  1. Revising modeling techniques – Its time to catch up Eclipse's standards. We have decides that our previous modeling technique is getting oldish. So naturally we are targeting JDT's concepts with adaptation to the php dynamic binding nature (given by the DLTK project).
  2. Code Manipulation – sometimes the editor should generate new code or even rewrite an existing code. This is an excellent mechanism for such kind of tasks. Also a great advantage is that we catching up JDT's standards on these capabilities as well so many of JDT's features are quickly portable to php.
  3. UI enhancements – this is the part that our community should be most happy to hear about. Since infra was enhanced , more and more UI features are available. Taking for example mark occurrences, override indicators, better code completion, fast searching, quick fixes and more.
  4. Upgrading our Dependencies – While most of Eclipse 3.4 enhancements are infra related, Web Tools 3.0 brings the Ajax tools into their editor and this is automatically brings it to the php environment. Editing, browsing, launching, code assisting, folding, and more features are now available for the JavaScript side as well.

UI Framework Changes

A number of minor changes can be made to the UI framework itself to simplify the experience. Some of these ideas include:

  1. Use event handling of the DLTK framework - UI components are used to listen to our model change, since we are changing the model we will have to change the way these component are acting.
  2. A new PhpReconcilingStrategy is added - this is to listen on the document changes and reconcile the SourceModel of our core model.
  3. Web Tools LineStyleProvide mechanism is lack of text presentation reconciler (where in JDT this is the editor's responsibility) this mean that only LineStyleProviders can determine the coloring of our editor. So the logic of color reconciling should move from the editor to WST providers.

Additional Paths

Beyond the framework changes, we will also being introducing an extensive unit test standards that cover our new components.

In the future we want to install | EMMA on our build server so we have a code coverage reports as well.


Over the next month or so, I hope to collect input from all interested parties and start formulating a design and prototype from those comments. We would also like to ask for help with the process, either by providing patches or helping to test at various stages in the development.

We hope to have a first cut of this new functionality available in the M1 timeframe to help drive the discussion further, having a more complete sample in the EclipseCon timeframe.

In addition, we welcome feedback at all points in the process, so feel free to chime in with your suggestions and problems. Keep in mind that your comments will help us prioritize features so we get as many key requirements addressed for version 1.1 as possible.

The goal is to make PDT better for users and that can only be done with your (the PDT and Eclipse community) involvement. Thanks!

Community Comments

<RoyG>Comments should go on this and we will integrate them in with the design document. Please remember to note your comments in brackets, such as <RoyG>My comments...</RoyG> so we can keep track of different threads. Any comments that are sent in to the newsgroup or mailing lists may be paraphrased and reposted on the Comments page and be integrated into the document also.

We look forward to your feedback and suggestions! </RoyG>

Back to the top