Seva's notes

Wisdom, Awareness, Responsibility :)

Archive for November 2007

Grouped Completion (Content Assist) in PDT

with 2 comments

Last Wednesday I was working on grouping of code completion (content assist) options. It’s now only exists in CVS and will be (hopefully) released with the build after the next one (the current is already finalized).


The main point of the feature is collapsing of multiple same-prefixed options into groups, instead of showing a long list of the options. For example if your application is based on Zend Framework or PEAR, most of library’s classes start with “Zend_” or “PEAR_”, and this is what you will get as a completion option. In addition, the grouped list doesn’t show common prefix if an user already typed it.


In general it’s applied to all the types of elements (classes, functions/methods, variables and constants) in all the possible contexts (general completion, doc blocks, new/instanceof etc.). The feature is disabled by default can can be found at:
Preferences->PHP->Editor->Code Assist->Group Completion Options

The logic of the grouping is very similar to completion of files in include statements in Zend Neon and is quite simple:

  1. If there are several options which share common prefix AND there are additional elements which do NOT have this prefix, the sibling elements are collapsed to groups with “…” suffix.
  2. After completion of a group, completion pops up immediately again to show elements with the typed prefix.
  3. If typed prefix has common prefix with proposed elements/groups, it’s collapsed with “…” prefix.

How it works

First, all the types of code completion options are created by objects which extend an abstract CompletionProposalGroup (View Source). The class’ work is to receive an array of CodeData‘s and return an array of ICompletionOption‘s. This is why the feature’s code is mostly aggregated in this class.
So, instead of just creating a completion option for each element, we should first create a tree of all elements, based on elements’ name chunks separated by “_”, then go over the tree and extract only the relevant elements and groups, and then create chopped completion options for groups and elements. And now in details –

Creating Tree of Elements


Luckily, Eclipse platform provides two base components which made the implementation relatively simple. It’s IPath/Path couple, which provide a comfortable solution for handling abstract OS-like paths, and ElementTree, which is a recursive tree data structure which gives access to it’s nodes based on IPaths.
The first action item here is to create a path from element’s name – it’s done by replacing all delimiters with slashes and providing the result string to Path‘s constructor. Then it’s time to recursively create the element – if the parent path is not in the tree, we’ll add it with null data attached (these nodes will represent element groups in the future). After the parents exist, we are adding the element itself to the tree with CodeData object attached.

Extracting relevant Elements and Groups


In order to get the relevant elements and groups according to 3 rules mentioned above, we basically need to recursively get children of a tree node starting from the root. However if there are no children for current node or the node has sibling(s) – we don’t want to continue deeper inside, and just return the current node. As a result, we get list of elements and collapsed groups to create completion proposals from.

Creating Elements and Groups Completion


Afterwards, the only remaining thing is to create proposals. For element proposals there is a wrapper proxy PartialProposal for CodeDataCompletionProposal which cuts off matching segments of prefix, and for groups – there is a wrapper proxy TemporaryCompletionProposal for CompletionProposal created with cut prefixes,  which only ovverrides ICompletionProposal.apply() method to reactivate completion immediately group application.

That’s all it’s about.

Written by Seva

2007-11-25 (November 25) at 06:52:43

Zend Framework vs. CakePHP, Symfony, Seagull, WACT, Prado, TRAX, eZ and CodeIgniter

with 19 comments

In contraversal with what it might seem, I won’t compare features of the mentioned projects. For that purpose you may just read this nice article by Dennis Pallett.

Instead, I will share you what I learned with help of [in]famous Ohloh project – the codebase, activity and participants dynamics comparison of the mentioned projects.

Well, I’ll not make any conclusions – just observe the facts.

(lines of code)

  Zend Framework   CakePHP   Symfony

  Zend Framework   Seagull   WACT

  Zend Framework   PRADO   TRAX

  Zend Framework   eZ   CodeIgniter


  Zend Framework   CakePHP   Symfony

  Zend Framework   Seagull   WACT

  Zend Framework   PRADO   TRAX

  Zend Framework   eZ   CodeIgniter

(active committers)

  Zend Framework   CakePHP   Symfony

  Zend Framework   Seagull   WACT

  Zend Framework   PRADO   TRAX

  Zend Framework   eZ   CodeIgniter


Written by Seva

2007-11-13 (November 13) at 01:38:51


leave a comment »

After several months of enjoying the Blogger engine I’ve decided to move to WordPress. Mainly because of browser compatibility. But now in addition I see the robustness and simplicity of WordPress and happy even more.

Written by Seva

2007-11-12 (November 12) at 04:22:00

Posted in future

Copying files the Eclipse way

leave a comment »

The tip on subject.

Written by Seva

2007-11-06 (November 6) at 07:10:00

Posted in eclipse, java, pdt