15:42:02 ...with the appropriate startup for the model etc 15:42:36 ...by extension we could also download simply the UI binding against the existing model, as for dynamic form controls in a repeat 15:43:05 Nick: yes, but the init events are dispatched, so as implemented its more like a separate subform not interacting with the parent form 15:43:11 ...more like an iframe 15:43:25 John: encapsulated makes it easier 15:43:59 http://lists.w3.org/Archives/Public/www-forms/2009Jun/0023.html 15:44:37 Charlie: how is initialization handled then>? 15:44:41 Nick: via the server 15:45:09 John: probably has some form of "under the covers" communication between models 15:45:16 Charlie: perhaps just by actions 15:45:54 Nick: main driver was performance problems with large model/schema 15:46:15 John: yes, we deliver only one page at a time and use server to aggregate content 15:46:30 ...and only deliver those pages that are relevant to a given transaction 15:47:14 ...problem is schemas emerging in various industries are quite large/monolithic 15:47:37 ...we need to support interacting with them in subsets...not clear it requires a new feature for xforms if it's only one subform 15:47:49 ...perhaps so if there are multiple subforms 15:47:57 ...why work through the load action? 15:48:56 Charlie: might want to combine this with our shiny-new data-bound switch 15:49:55 Nick: submodel also submits directly to the parent document model 15:50:02 ...so starting again to look like components 15:50:06 John: yup 15:50:37 ...sounds like the aggregate applications I've been talking about, but have assumed a bit more support server-side 15:50:58 ...e.g. marshal results of several pages together and let server decide which pages to deliver to client and when 15:51:27 Nick: yes, that's what Joern is doing. Form lives on the server and we use load actions send certain parts to the client replacing parts of the main page 15:51:44 Charlie: so this is really part of the aggregate application theme 15:52:16 John: use of load does determine it's client-side processing 15:52:26 ...vs option for deferring to server logic 15:53:34 Charlie: would like to consider this together with aggregate theme, e.g. is load right approach? 15:53:46 John: also concerned about load action in general, not just in this case 15:53:56 ...possible overlap with submission 15:54:17 ...going forward whatever we do with load we should consider also for submission 15:54:56 ...why not be able to replace tabs, divs, etc with submission results? 15:55:18 Nick: for me, use load for really simple case 15:55:34 ...without need for submission mechanism in the model...short hand notation in load 15:55:41 John: yes, authoring convenience 15:56:05 Nick: could extend send with these capabilities 15:56:23 John: yes, but we should be careful in extending load so it actually remains simple 15:56:33 ...vs using submission for some of these features 15:56:42 ...rather than fully duplication all features of submission into load 15:57:18 ...so coming back to this proposal if we do something with load we should also look at supporting similar function in submission 15:57:46 ...Joern is talking about load replacing section of document with new content, which is full xform 15:58:07 ...this provides another driver for model element living in the body of the document 15:58:12 ...think we need this already 15:58:31 ...that's the only way to get xforms to run in a portal environment...multiple portlets with independent models 15:58:38 ....not at the head of the page 15:59:32 markbirbeck has joined #forms 15:59:35 Nick: yes, but events in the subform don't go to the root 15:59:46 John: but the root is the body rather than the head 16:00:10 ...just pointing out there are other reasons for wanting the model not to be in the head 16:00:40 ...this proposal just provides another similar reason for doing so 16:01:25 ...in the portal case it's server-side code that shares data across portlets, more recent work allows components client-side wiring 16:01:40 ...rather than xforms submission between components 16:01:57 Charlie: I'm still not convinced that Joern's case needs this level of separation 16:02:15 ...i.e. completely separate subforms 16:02:36 Nick: he uses the subforms as components 16:02:48 ...have their own constraints, model, etc...submit data back to parent which does the aggregation 16:03:54 John: difficult to componentize if the subform has both model and UI and the invoker has to split this into separate places in the receiving document 16:04:17 Charlie: yes, perhaps the subform can be viewed as a submodel 16:04:29 with controlled access to the parent 16:04:34 vs being completely separate 16:05:33 John: might allow for more declarative means to connect up the subform and parent 16:05:50 ...whether a server round trip is required depends on where the parent model resides, client or server 16:06:04 ...Joern seems to be placing the master model on the server 16:06:10 ebruchez has joined #forms 16:06:24 ...would want to see both model and submodel running on the logical client 16:07:05 Nick: yes, he has a new type of submission that targets the parent form's model 16:07:16 John: does that then update the parent form's model on the client" 16:07:20 Nick: yes 16:07:54 John: but the server just reflects whole state of the app 16:08:07 ...so the submission from the subform does what type of replacement? 16:08:29 Nick: submits data to surrounding form subtree, replaces node 16:08:42 John: then in response the master model runs a new load action to load next page? 16:08:48 Nick: yes 16:10:19 John: so the subform submits directly to the instance data of the master form 16:10:42 ...what type of replacement is done? 16:10:45 ...none? 16:12:08 John: and then the master model runs a subsequent load action 16:12:11 ...for the next subform 16:14:03 Nick: will look for some example markup fragments 16:14:28 John: good to have a working example but we may wind up satisfying these requirements with alternative markup 16:15:27 ...need to have orchestration across multiple pages, not clear if it's xforms markup that will need to do this 16:15:33 ...first topic for tomorrow 16:15:37 bye 16:15:43 -Steven 16:15:44 -wiecha 16:15:46 -John_Boyer 16:15:50 -Nick_van_den_Bleeken 16:15:51 HTML_Forms()10:45AM has ended 16:15:53 Attendees were John_Boyer, wiecha, Nick_van_den_Bleeken, ebruchez, Leigh_Klotz, Steven 16:15:56 rrsagent, make minutes 16:15:56 I have made the request to generate http://www.w3.org/2009/06/24-forms-minutes.html John_Boyer 16:16:00 rrsagent, bye 16:16:00 I see 3 open action items saved in http://www.w3.org/2009/06/24-forms-actions.rdf : 16:16:00 ACTION: John Boyer to move July 2nd vFtF meeting to September 3rd. [1] 16:16:00 recorded in http://www.w3.org/2009/06/24-forms-irc#T15-06-57 16:16:00 ACTION: Nick van den Bleeken to respond to http://lists.w3.org/Archives/Public/www-forms/2009Jun/0032.html by explaining how works. [2] 16:16:00 recorded in http://www.w3.org/2009/06/24-forms-irc#T15-19-52 16:16:00 ACTION: Charlie to change tests 8.2.4 a,b,c to use an input bound to a number type and ask user to enter "abc" then see alert [3] 16:16:00 recorded in http://www.w3.org/2009/06/24-forms-irc#T15-36-08