[cells-devel] OpenAIR: Doesn't work for me any more ...

[Ken Tilton]

Frank Goenninger wrote:
> 
> Am 11.04.2008 um 18:28 schrieb Ken Tilton:
> 
>> Oh, cool, I'll try that, makes for great demo! But the behavior you  
>> observed might derive from the spec I gave Andy, shown atop the  
>> example.lisp file. The salient part:
>>
>> ";; Oh, and the input field is also a pop-up of the query history  (which
>> ;; would not make sense if each keystroke was treated as a new query."
>>
>> ie, it would be a pretty big pop-up if each keystroke was a new  
>> query. (I am just guessing at Franz's rationale.)
> 
> 
> Which brings up a very good point:
> 
> Do we try to mimic Celtk and Cello really just as a RIA ? Or not? If  
> not then what actually is the goal beyond having fun with some new  
> technology - which is good in itself, no question about that...
> 
> Just that I know what we will aim at ...

I am not clear on the choices/distinctions you see, and I do not mean 
that in the funny way academics use it to say "Nonsense!", I mean that I 
really am not sure about what you mean.

Let me just clarify and expand on what I said to move the ball along -- 
I thought of another reason keystroke-by-keystroke on the apropos field 
would not work after I made your change and was about to type "m" and 
(had it worked and with the exported-only option off) was braced to see, 
what? a third of the symbols in my Lisp environment? :) Actually, we 
could do that if we did a scrolling list of, oh, twenty items and was 
lazy about generating the html, a definite future direction.

But! I was just talking about this one design decision, not saying every 
text input field should work this way. Clearly we want a field by field 
choice. We can go OO and create a class of input field (er, can we?) and 
have an eager field or a lazier field, or maybe we can add an attribute 
such as eager or lazy and extend openair.js to look for that, or maybe 
there is some even more powerful way that would not require forver 
extending openair.js, such as optionally providing on-<your event-here> 
handlers for any event for any widget. I am thinking coding rules on the 
  Lisp side that get Parenscripted into JS and sent over witht he widget.

Note that I am making this all up, I do not know what is possible, but 
in answer to the general question I am hearing,...

... no. No compromises in functionality. Whatever Ajax/browsers can 
handle we should be able to provide to the web author with the kind of 
fine-grained control I hand-waved about above.

cheers, kenny