Hey Mike,
this thing is totally cool! Thanks a lot for sharing that!
Of course, it can even get better with a few tiny enhancements:
- split view of .html and .wod - probably side-by-side as it makes
the moset sense, since .wods are not very large horizontally.
- .api file support (I do use them:)
- a menu with the most-used elements that get inserted in .html and .wod
- validation of bindings that show up in Eclipse's problems things.
One could limit that to first-level bindings that doesn't match.
- Dynamic WYSIWYG with CCS 3.0 support. Prefably with a running WOApp
that does the re-rendering.
As the last one is probably easiest, I'd suggest you get busy with it
first:)
^foo can be completed if you have proper .api declaration. parent.foo
is of course not possible but a very bad idea anyway.
Thanks again, Anjo
Am 03.07.2005 um 06:56 schrieb Mike Schrag:
> I just checked in the first "real" version of the wod text
> editor ... It provides syntax coloring and completion on the
> following things:
>
> 1) Element Name - wodclipse looks in the .html template for all the
> <webobject name = "xxxx">'s (it's slightly more forgiving than that
> exact syntax) and uses the xxxx's as completion candidate
>
> 2) Element Type - you have to type at least one character in the
> element type area (after the : in the definition) because just
> giving every possible option takes forever, but after that any
> class that is in the classpath of the wod's project that is
> assignable to WOElement will be a candidate
>
> 3) Association Name - any public or protected (is protected valid
> for wod's?) non-static field, _field, set, or _set method that is
> in the Element Type class will be reformatted in the standard style
> (drop the set, lowercase first letter) and be a completion
> candidate. At the moment I don't use the .api file mainly because
> I never use api files in my apps :) As I'm writing this, I realize
> I haven't actually tested to see if inherited fields/methods
> appear, so I'll have to look at that.
>
> 4) Association Value - similar rules as association name but for
> get methods and it supports keypath notation for "reflectable"
> keys. If you use ^ or parent., then I have to punt, because it's
> impossible to complete those. I haven't added in Session or
> Application yet either, mainly because I don't know that I can
> reliable determine the correct class to use for them -- I could
> probably at least wire up WOApplication and WOSession base classes,
> though -- I'll have to give those more thought.
>
> A next obvious step here is to add an incremental compiler for wods
> to verify element names and keypaths. The tricky part with
> keypaths is that I can only know when it's right and I can't ever
> technically know when it's wrong because of dynamic keypath
> support. Element Names is a much easier problem to solve, though
> (basically giving compile errors when you have invalid types or
> undefined element names).
>
> Let me know if it blows up your eclipse :)
>
> Oh, you may need to go into File Associations and wire up "WOD
> Editor" to .wod files, or Open With=>WOD Editor.
>
> ms
>
This archive was generated by hypermail 2.0.0 : Mon Jul 04 2005 - 09:38:47 EDT