Is there any chance you can post a binary?
On 05/07/2005, at 1:18 AM, Mike Schrag wrote:
> 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 - 19:08:52 EDT