Hi Bryan,

I fear I cannot answer this question in an accurate way. It would largely depend on the complexity of the expressions used in the bindings.

I do not currently have the time to do a thorough evaluation of this issue. I can give the general advice, that you should only create bindigs that are actually needed for the form to work, that is, they are either used to associate a control with a node, or they are used to declare some calculation or constraint MIPs for the node (or nodeset).

Bests,
Lars


Bryan Rasmussen wrote:
Hi Lars,
So, what do you suggest is the limits of how many bindings a form should
currently allow. I've tried with less than 400 and performance is still not
reasonable.

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]

Reply via email to