Re: XForms: Series of questions on a simple invoice application

Sorry, I forgot to prepend "XForms" on my subject line, to indicate that 
I'm asking questions about the XForms support from the XPI nightly builds.

--Paul

Paul Everitt wrote:
> 
> Hi all.  I have a series of questions in support of building a small 
> invoice application, which if I succeed in doing so, I'll try to write 
> up a decent tutorial on how I did it.
> 
> My questions mostly revolve around which design patterns I should use, 
> based on what parts are fairly stable in the nightly builds.  I follow 
> the status updates here:
> 
>   http://www.beaufour.dk/blog/
> 
> ...quite frequently and find the information exceptionally useful.  My 
> first attempt at doing this sample app in the nightly XPI 4 weeks ago 
> was quite frustrating.  This blog helps me get a feeling on which 
> direction to go.  (As a note, I've tinkered with XUL/chrome/RDF apps for 
> a few years.)
> 
> I won't go too much into requirements, just enough to start asking 
> questions.  Imagine a little application to browse, edit, add, and 
> delete invoices.  For the moment, pretend the information on each 
> invoice is very flat and boring: invoice number, title, amount, and a 
> vendor from a pre-defined list.
> 
> I must admit, I got stuck pretty quickly. :^)  I needed some way to 
> browse around the existing list of invoices.  I could do it in two basic 
> ways:
> 
> 1) Tree.  Use <select> and change the currently-displayed invoice for 
> the right event.
> 
> 2) VCR-like.  Use something like MS Access, where you have:
> 
>   <<    <    [90____]   >    >>
> 
> Handle each form control similarly to (1).
> 
> I found that event handling never worked quite the way I expected it to. 
>  I tried xforms-select but could never make anything happen. DOMActivate 
> didn't work.  Even attaching an HTML event via JS didn't produce much 
> help (as the model appears quite opaque to the DOM).
> 
> Based on the nightlies, what is a stable, good UI approach (select vs. a 
> series of <input> form elements) for browsing a series of "records"?
> 
> What is the right way to handle an event for that UI approach, 
> reflecting it into the model so that another <group> of elements 
> automatically changes to a different bound element?
> 
> --Paul