[Kss-devel] Global state; was Re: Save inline form on pressing Escape

[Balazs Ree]

Sun, 04 Mar 2007 15:14:27 +0100 keltezéssel Godefroid Chapelle azt írta:

> Godefroid Chapelle wrote:
>> Hi
>> 
>> I just checked in some code for inline form without save cancel
>> buttons.
>> 
>> I have built basic support for Cancel on pressing Escape.
>> 
>> Currently, pressing Escape will cancel only if the input has the focus.
>> 
>> This might not be enough : I have the feeling that pressing Escape
>> should globally cancel edit forms.
>> 
>> It is currently possible to have two (or more) inline forms activated.
>> If we do not want Escape to cancel all inline forms, we need a way to
>> discriminate which form to cancel.
>> 
>> I'd like to hear opinions.
>> 
>> 
> I have the feeling that we need our events to trigger on stuff more
> specific than just the node.
> 
> Jeroen needed to setup some global state like (shift pressed).
> 
> I wonder if we could not have stuff like this:
> 
> input:keypress {
> evt-keypress-keycodes : 27;
> global-state-inlineform: active;
> action-server : cancelForm;
> }
> 
> This event would trigger only if the right global state is set. This
> feels like generic functions.

The feature is obviously useful, however we may find a better syntax.

But in general the following dilemma raises. Do we want to allow this 
functionality from kss (thus making it more and more complicated), or do 
we say that for this usage you need advanced plugins?

There is a possibility to program this in javascript and it's pretty 
simple. You can store the "inlineform" variable into "this" from a 
default action of your event. Then you decide if you trigger another 
event or not from the code. Then from the kss you can bind the server 
action to the event it triggers. I admit there is not any useful 
documentation for this, but there is at least three similar examples.

To decide if this given case should be implemented in the kss level 
(actions, statevars) or in a plugin (custom event and this.xxx) mainly 
decides if this is a one-time feature or rather a component. If it is a 
component we should make it as a component or we'll end up copypasting 
long kss rules from one file to another.

(A more lightweight way of doing it would be just make a generic 
condition possible, and that condition would be evaluated in the same way 
as parameters are, using the provider functions. But this has other 
disadvantages in terms of complicating things. Then we really end up with 
expressions as parameter values.)

Maybe, Jeroen would end up making it as an event plugin anyway and we 
would not need the new feature then? Maybe we could turn this into a 
generic "condition" event?

-- 
Balazs Ree