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
_______________________________________________
Kss-devel mailing list
Kss-devel codespeak.net
http:
//codespeak.net/mailman/listinfo/kss-devel
|
