1) split view -- I was trying to decide how I wanted to do this ... I
was contemplating just adding a "switch between" button kind of like
XCode's button to switch between .c and .h, but the split view might
be cool too. I'll have to see how hard this would be.
2) .api files -- you're talking specifically just binding support,
right? The only tricky part here might be finding .api files for
wo's not in your own project (I just need to look at what the API in
eclipse is like for this)
3) most-used elements -- can you give me an example for this one?
You mean like a pulldown that has "WOHyperlink" in it and it inserts
into the html at the current position and adds empty bindings into
the .wod?
4) validation -- this is really only possible with api support I
think, or is that what you mean? I might actually start using api
files if I added this ;)
5) wysiwyg -- Um.. yeah :)
Can you explain how ^foo can be resolved? I thought that meant to
bind to your parent's foo variable, but in the context of a single
wod, I don't know what your parent might be. But then I don't know
all the things you can specify in api files.
On Jul 4, 2005, at 9:38 AM, Anjo Krank wrote:
> 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 - 11:18:46 EDT