diary - slice, value, select relations
Opened this issue · 11 comments
There is a need to alling
- element's
value
slot
expression for location in datadom- event
- value expression propagated into slot
- initial slot value expression
Ideas to think about
# | markup | sl. init | sl. from | event | effect |
---|---|---|---|---|---|
1 | <input slice="s"> |
no | value | change | 1:1 slice⮂value |
2 | <input slice="s" value="A"> |
A | value | change | slice⮂value, w/ initial |
3 | <input slice="s" value="A" slice-event="tap"/> |
A | value | tap | ^, on sync on type |
4 | <input slice="s" value="{$a}" slice-event="tap" /> |
attr a |
attr | tap | ^ w/ initial from attr |
5 | <input slice="s" value="B" slice-value="'x'+@value" /> |
expr | expr | change | on click s="xBchanged", init by expr, static value |
6 | <input slice="s" slice-value="'x:'+@pageX" slice-event="mousemove" /> |
mouse | on move s="x:123" |
Aspects
- initial slice value
- initial element value
- on event slice data
- slice-driven value
Things to think over:
- element
value
gives just inital value, value
is changed by element in runtime.- on re-render
value
is overriddidden by template. Hencevalue
can not be used to keep the state/changes. - the goal of
slice
is to define- the query to populate the slice
- initially
- on event in runtime
- when
value
is missing, the data selector to set initialvalue
- the query to populate the slice
Slice related attributes
slice="name-of-slice"
name of slise, xPath to location in/datadom/slice/
root. "a|b" = 2 slicesa
andb
slice-event="tap"
, Replacement forslice-update
. space-separated events, w/init
syntetic eventslice-value="@value"
- xPath evaluation of value assigned to slice.
Attributes passed to slice-value
made as combination of element attributes (@value
is a runtime value
of element).
Event object fileds
In slice-value
xPath those are available with event/@prop
notation. Like for MouseEvent event/@pageX
datadom in slice-value xPath
In order to access data from whole dataset the XML have to be same as in slice
and any another selector: {xPath}
, <value-of select="xPath">
,...
The properties of slice-ed element is primary subject of data access, hence have to be presented in datadom
as
- node
- with attributes matching the operated element
- with event serialized as node with props as attributes
? Should the event target properties be exposed or attributes are sufficient?
related: #42
Does the removable of the slice=s element trigger the slice-update event?
@jasvir , that has to be defined in the scope of this issue.
IMO the slice-event
( replacement for slice-update
) should disable the slot initialization. The syntetic init
event can be used if there is a need.
<input slice="s" > IMO is equals to
<input slice="s" slice-event="change init" slice-value="/datadom/slice/s">
The reason of init disabling:
- actions like buttons should not change the slice value unless clicked. But the
value
attribute is still needed and can be used in expression
<button value="abc" slice="s" slice-event="click" >
populates the slice with value when clicked but not on initialization.
Does the removable of the slice=s element trigger the slice-update event?
I guess you meant would remove or adding the element with slice
and value
would trigger the change of slot?
<if test="some condition"
<input value="when included by condition ^^, this is assigned to slice" slice="s" type="hidden">
</if>
The answer is yes. But removing of element would not trigger the slice change.
@jasvir , are there concerns on naming convention for slice attributes ?
I'm a little confused by when you have hyphens and when not - that seems inconsistent. slot-event vs slotvalue. It's not a big deal but I would avoid hyphens if possible. if they were ever in the future to be reflected to javascript, the properties would need to be turned into camel case (so slot-event would be slotEvent).
@jasvir , you right. It has to be consistent. And during conversation I have misused slot
and slice
sometimes.
The slot
is UI DOM injection in current HTML template standard. slice
is datadom part ( /datadom/slice/xxx
) which is part of this discussion.
So slice-event
can be later translated to sliceEvent
as you mentioned.
Now to the match of attributes to elements.
slice
is an attribute and slice-event
is another attribute on same element. Like
<input slice="xxx" slice-event="keyup" />
But sometimes we would need to populate into different slices with own values. For that own tag has to be used for each slice to avoid confusion.
<textarea>
<slice name="a" slice-event="keyup" slice-value="'typed '+$value" ></slice>
<slice name="b" slice-event="keyup" slice-value="char_count($value)" ></slice>
In scenario ^^ the same event to populate different values into different slices. I.e. a="typed GFDFAHGF", b=22.
More in #42
One more thought but I'm not sure this is the right issue for me to add it to... DOM elements have a convention of making executable code in attributes ie event handlers have the convention of starting with on...so onload, onmousedown etc (heh except online). This makes the life of sanitizers easier. I don't fully understand the semantics of slice-value but if you have expressions in there, it's worth thinking through if you want a convention between dead data attributes and active code.
@jasvir , the custom-element
syntax is a mix of HTML and XSLT conventions. It does not use onXxx
event handlers with JS code on it. It does not prohibit its use though. At least for now.
XSLT and custom-element
attributes do expression evaluation via XPath. There are various attributes and {xPath}
convention for such expressions. select
, test
, etc... Those do not have prefixes and special convention, just hardcoded names.
The slot
attribute prefix can be used for recognition that the value is XPath expression. I.e. "active" attributes:
slice
is XPath of slot name selection in/dataset/slice/
slice-value
is XPath to be evaluated on eventslice-event
is event names union, can be XPath as well...
Regarding the “active” component, it’s not just the attributes that are active, but the entire template is considered active markup. A custom-element
is primarily composed of this template.
Status update. Implemented in develop
branch. Unit tests tbd for release. Will be shipped along with #42