Hi Bryan Surely it's not just a matter of how many nodes and bindings are sensible in the form for acceptable form performance but also how many include fields are sensible in terms of whether a human can fill them in accurately in a reasonable time. If a human had to enter every bit of data required by that Signature complexity in that Order form they would probably complain of that amount of work even more than complaining of the response time of the form - or go insane trying to complete such a form.
I would think about 30 bindings were about optimal for an Order form and since the form is to be completed by a human rather than application then I'd say about 150 fields is a reasonable limit. 150 fields and nodes with 30 bindings might be about right for a hand-completed order or any form for that matter - except for an onerous tax form of course. e.g. http://xforms4ubl.svn.sourceforge.net/viewvc/*checkout*/xforms4ubl/BusinessWeb/CreateOrder.zip which isn't an ODF/XForm but XHTML/XForm but illustrates the argument. Maybe there would be some challenge converting it to ODF/XForms. I'd like to give it a go sometime. Hoping you still enjoy some of that holiday. All the best Stephen Green On 10/04/07, bryan rasmussen <[EMAIL PROTECTED]> wrote:
Hi, I have reduced the number of bindings about as much as I can reasonably expect to reduce them, removing all bindings to complex elements, to 444 bindings. The form is still somewhat slow however, about 1 second to enter 2 characters. I have also tried removing bindings to prefilled simple elements, bringing it down to 352 bindings, but I feel sort of ambivalent about that optimization. At any rate it should not be done all the time without users having a choice to turn it off. So any other possible optimizations? The tree display showing all document bindings still shows the bindings that are no longer explicitly declared, but I guess they are implicit and this is the reason for the display in the tree? I'm thinking if there was a way to do multiple forms, via a sort of workflow system this would allow me to reduce things to a usable number of bindings. but then how to manage this, in a reasonable amount of time[should be delivering at the end of this month, and I'm on vacation now]? Cheers, Bryan Rasmussen On 4/10/07, bryan rasmussen <[EMAIL PROTECTED]> wrote: > Hi Lars, > > Yes that's what I figured, I've already removed the generation steps > that takes the complex elements without attributes. I guess I'm at the > point where this is not premature optimization anymore :) > I was just wondering if it would lead to any side-effects to do this. > > Cheers, > Bryan Rasmussen > > On 4/10/07, Lars Oppermann <[EMAIL PROTECTED]> wrote: > > Hi Bryan, > > > > I'm not sure if I understand what you mean by this... > > > > Consider the following pseudo-form: > > > > <doc> > > <xf:model> > > <xf:instance> > > <a> > > <b> > > <c/> > > </b> > > </a> > > </xf:instance> > > <xf:bind name="binding1" nodeset="/a/b" /> > > <xf:bind name="binding2" nodeset="/a/b/c" /> > > </xf:model> > > <form> > > <control xf:bind="binding2" /> > > </form> > > </doc> > > > > In this case, "binding1" dies not serve any useful purpose. It could be > > removed from the document in order to speed up processing in > > OpenOffice.org. Is this what you mean? > > > > Bests, > > Lars > > > > bryan rasmussen wrote: > > > Hi Lars, > > > > > > This is bad news. One solution on my end as a method for decreasing > > > number of bindings, If I bind to a path /a/b/c will OO accept that I > > > neglect the binding to /a/b? > > > > > > Cheers, > > > Bryan Rasmussen > > > > > > On 4/5/07, Lars Oppermann <[EMAIL PROTECTED]> wrote: > > >> Hi Bryan, > > >> > > >> I checked out your documents. I can confirm, that they perform painfully > > >> slow in OpenOffice.org. I have analyzed what is happening in the > > >> application and found, that the way updates are currently handled in the > > >> xforms implementation is not fit to handle forms with a larger number of > > >> bindings efficiently. > > >> > > >> This means, that I cannot make any useful suggestion on how you could > > >> optimize your form, since the current implementation mostly depends on > > >> the total number of bindings in the document. current.odt includes > > >> almost 1000 binding elements. If you can reduce the number of bindings, > > >> the form would not suffer so badly. > > >> > > >> I suggest, that you file an issue for this and attach your test > > >> documents. > > >> > > >> Thanks you for pointing out this problem. > > >> > > >> Bests, > > >> Lars > > >> > > >> bryan rasmussen wrote: > > >> > oops, forgot to attach the documents > > >> > > > >> > On 3/30/07, bryan rasmussen <[EMAIL PROTECTED]> wrote: > > >> >> Hi, the three attached documents show different Xforms in Open Office. > > >> >> > > >> >> The document params.odt is generated from a very small xml document > > >> >> using a generic transformation I have to output Xforms in Open Office > > >> >> for any well-formed non-mixed content document. > > >> >> > > >> >> The document Order.odt shows a large document generated with the > > >> >> same transformation that has been edited in design mode (a UBL Order > > >> >> in the Danish subset) > > >> >> > > >> >> The document current.odt shows a large document generated with a > > >> >> transformation that reuses the generic transform but changes display > > >> >> in some instances to make it much better. > > >> >> > > >> >> There is a performance problem with these documents. The first one has > > >> >> no problem. The second one has a slight performance problem in > > >> >> entering information into the fields but it seems to work reasonably > > >> >> well. > > >> >> > > >> >> The final one is so painful to work with that if anyone asked me to do > > >> >> it I would have to consider it an act of aggression. > > >> >> > > >> >> Now there are parts of this third document that are different from the > > >> >> others, but of all these that I am aware of I can't think of any > > >> >> reason why it should cause the whole document to be problem, I am > > >> >> worried it is mainly a problem with document size (which would be a > > >> >> lot worse with a document with say 50 invoice lines instead of the 10 > > >> >> the current has. ) > > >> >> > > >> >> So I'm hoping that a many eyes effect will have others point out what > > >> >> is causing the performance problem (so long as I can fix it) > > >> >> > > >> >> By the way I think development of solutions using Xforms in OO really > > >> >> needs tools, I have developed some to make things easier for me and am > > >> >> thinking that it might be nice to build some simple structure checking > > >> >> tools that can point out potential performance difficulties. > > >> >> > > >> >> > > >> >> Cheers, > > >> >> Bryan Rasmussen > > >> >> > > >> > > > >> > > > >> ------------------------------------------------------------------------ > > >> > > > >> > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
