How It Works

Peter Boughton edited this page Jan 18, 2012 · 1 revision

The Big Idea

We want to somehow link our code with what we use to create that code. Integrate the two ends of the beast. Picture a dragon, eating it's tail.

We want an environment where we can develop as close to the speed of thought as possible.

A place that takes all the little bits and pieces that make up our ideas, and puts them together in various ways for us-- Which in turn gives us fresh ideas for ways of putting not only the pieces of our ideas together, but composing those composed ideas with other ideas.

A place that provides thoughtful- nay, insightful- perspectives on, and for, the things we create.

We will call this fantasmal place an Integrated Development Environment, or IDE.

CFEclipse strives to be an IDE for CFML. I say strives, because CFML is an incredibly flexible language.

To gain insight on the code, the editor needs to know how to interpret it. This is achieved through parsing the code using lexical analysis. Here's a graphic: [http://en.wikipedia.org/wiki/File:Parser_Flow.gif](http:// en.wikipedia.org/wiki/File:Parser_Flow.gif). Somehow this is sorta related to BNF and finite state machines.

If that stuff doesn't scare the snot outta you, good show my friend, good show!

So, the difficulty, obviously, is that CFML can be sorta, um, ambiguous, unlike other languages where there is more, um, rigidity.

Even so, there is a finite number of ways to construct CFML, so we're not Super Outta Luck, as the saying sorta goes.

Anyways, on with some implementation details!

How We Do It

I'm just a person who likes to know how things work, and who's under no illusions that the way one thinks things work, is indeed, actually the way things work. There had been thousands of hours of work put into CFE, long before I was on the scene. There are millions of hours at work within Eclipse itself. I've made what sense of both of them that I can (although Eclipse is more of a plural than a singular), but it is entirely possible I'm incorrect in whole, or in part, on the information that follows. So take it all in stride my friend.

Basically, it works like this: A text editor doesn't even see text, all it sees is characters. We may see "one two" as 2 words, but it would see 7 characters. Imagine trying to tell it how to "see" CFML (you can't provide insight without the sight part). This is basically my take on how we do just that:

We begin with a text document, and run it through a tag parser. We compare the tags to known CFML tags (they're in the dictionary), and get possible/valid attributes and whatnot for any we find. If CFML were like XML, this step would be trivial-- it ain't, so it ain't. We have to account for tags like , which are valid thusly too: .

Because CFML doesn't use things like import statements, and instead relies on the engine to provide what is needed, we need to know what the engine provides. This is done through the aforementioned "dictionary files", which are XML files describing the tags that are available. "Custom tags" are handled through what we call "user dictionary files".

This first parse gives us the bare-bones ICFDocument, which is a model that represents our source code. We do a couple other parses, looking for variables and whatnot, to flesh out this model, but basically, the model is the thing we work with. The parsers tell us what parts of our model are invalid, which we relay to the user.

Once we have a model to work with, things are easier, because it's just a matter of presentation after that. We tell the various views how, and what parts, of our model to present to the user. For instance, the "outline view" may show a function as an element in a tree, while the "properties view" would show it as an element with a list of properties.

Pretty cool, right? Yeah, single points of reference rock.

The Big Picture, or Where we go From Here

We're currently doing a lot of the parsing "by hand", meaning we're not (as far as I can tell) using something like BNF notation. There are tools for doing some of this for us, like ANTLRv3 or JavaCC, etc., and we plan on using something like this in the future, if possible.

There are a couple of Eclipse plugins that would take care of a lot of the other things we will currently have to do ourselves, like hover annotations and Mylyn integration. Currently we're looking at using the DLTK/WTP projects, as they are geared towards languages like CFML, which is a heady mix of CFML, HTML, Javascript and CSS (did I forget something? What a list, neh!).

If you have questions or comments, bring them to the developer group @ [ http://groups.google.com/group/cfeclipse-dev](http://groups.google.com/group /cfeclipse-dev).

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.