Awesome stuff Oisin! Gonna have a play! 2008/11/3 Oisin Hurley <[EMAIL PROTECTED]>: > On the subject of smart completion in IDEs, I've been experimenting with the > Xtext (http://wiki.eclipse.org/Xtext) to produce a simple, text-based > editor with > primitive syntax completion, error checking and outline views for Eclipse. > > http://code.google.com/p/camel-extra/wiki/CamelSpit > > There's some screenshots there to have a look at -- I started by looking at > Vadim's ANTLR grammar, but drifted from that somewhat purely because I > haven't fully grokked yet how Xtext does its thing. > > Camel processors seem to follow a basic genetic plan, with some semantic > constraints, along the lines of > > <processortype> <expression> > <action-section> > <targeting-expression> > <configuration-section> > > plus any scoping syntax to clump things accurately. This could lead to a > very clear grammar *but* it means that you have extra semantic-check > pieces to put in to make up for the generic structure (i.e. for some > processors > you don't have configuration, or you can do any actions). > > Taking the from the editor perspective, the goals are really to be as > deterministic > as possible, so that when a syntax completion request comes in, the options > that are presented to the developer make sense. Ideally, the semantic > processing > is minimized to cut down on the lag time before the completion pop-up occurs. > > The xtext grammar at http://tinyurl.com/5vsp28 goes down this route. > > Of course, the bit that's interesting is the approach of going > editor-first. Xtext > will generate an ANTLR grammar, as well as the model elements for a syntax > aware editor and outline view, which is nice. However, the generated ANTLR > isn't as, ah, elegant as you might want it to be. There's bound to some kind > of > maintenance issue going on there, as well as concerns not being correctly > separated. Trade-offs persist. > > --oh >
-- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
