http://markupuk.org/index.xhtml
Steven: This weekend.
... I'm talking on the XForms testsuite
https://lists.w3.org/Archives/Public/public-xformsusers/2018May/0033
Steven: Are we in a ready state
to discuss?
... It seems to solve many of the problems; no clashing IDs,
uses existing mechanisms. Solves my use cases in any case!
:-)
Erik: If I userstand, the subform can communicate using submission, and it can do it multiple times.
Steven: Here is the correct link: https://lists.w3.org/Archives/Public/public-xformsusers/2018Jun/0000.html
Erik: Can the enclosing form communicate multiple times?
Steven: Yes, [There is an action <renew control="id"/> that causes the initial values
reference to be copied to the embedded instance again]
Erik: So there is complete
isolation between the two.
... How about passing events?
... In browsers, webworkers live in isolated memory space, you
can pass information back and forth using buffers of data
... the logic is that data is always copied
Steven: Similar to this proposal
Erik: How about dispatching
events?
... Would be tricky
... Embedded form could announce readiness to do stuff at any
time.
Steven: We could expand
<dispatch/> to send events into an embedded form or out
of an embedded form.
... that would make embedded controls act like existing native
controls.
Erik: Where would events be dispatched to?
Steven: for the parent it would
be the <control/> element itself
... but for the embedded form, the <model/> seems like a
consistent place; we send events to the model when there is no
other obvious place (eg xforms-ready)
Erik: First model?
Steven: Or all, as happens with
xforms-ready; we would have to decide.
... Sounds like a good addition. We ned to think about if it
requires a change to <dispatch/> to send an event into an
embedded form.
... I'll work on it further, and make those additions, and we
can talk about it again.
https://lists.w3.org/Archives/Public/public-xformsusers/2018May/0037
Steven: Since the embedded
controls use a new sort of method in submission, that could
solve our echo submission issue.
... using a method="xforms-echo"
Erik: I'm not a fan of using
@method.
... it includes http method, and other stuff too.
... it feels like reusing that attribute for other
things.
... not because it is fundamentally a 'method'.
Steven: Not sure if I agree. It's not a 'scheme' either.
Erik: Not sure what to think
about it.
... for method at present we have get, post, delete, put,
multipart-post, etc.
s/-put/-post/
Erik: Taking multipart-post, it
packages several things into one token...
... not very clean
... there should be a separate way of specifying "multipart"
(not part of this topic though)
Steven: I hear you're not very happy about it; let's think on it more.
https://lists.w3.org/Archives/Public/public-xformsusers/2018Apr/0051
Steven: No news.
Steven: Next week I'll ask about planned vacations.
[ADJOURNED]
<scribe> ACTION: Steven to incorporate events into embedded forms proposal
<trackbot> Created ACTION-2186 - Incorporate events into embedded forms proposal [on Steven Pemberton - due 2018-06-13].
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/TH/Th/ Succeeded: s/multi-/multi/ FAILED: s/-put/-post/ Succeeded: s/sontrols/controls/ Succeeded: s/consisten/consistent/ Succeeded: s/multi-part/multipart/ Present: Alain Erik Philip Steven No ScribeNick specified. Guessing ScribeNick: Steven Inferring Scribes: Steven Agenda: https://lists.w3.org/Archives/Public/public-xformsusers/2018Jun/0003 Found Date: 06 Jun 2018 People with action items: steven WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]