A suggestion for the next release of InfoPath

[G. Tarazi]

I am reading on the internet that Microsoft is going to release a beta of
InfoPath 2006 in the middle of 2005, a client and a server, and since the
time is coming, here is a suggestion.



Have a sample with a 10 page InfoPath form, a one that includes conditional
formatting, rules, c# code, nested sections (and that is very important),
etc.



I am saying that just so you can realize how slow a form can go today, if it
has multiple views and each view has multiple pages.

 

[Scott Roberts [MSFT]]

Hi,

Would you be able to share your form template with us so that we can use it
to improve the performance of the product?

Thank you,
Scott

 

[G. Tarazi]

Thank you for the response, I can't share a year of development; the forms
are not ours, they belong to my client, but here is a small comparison.



Create a tree schema with 700+ end nodes, create an InfoPath form with 60+
views, import that schema to that form, and show parts of it differently in
the 60+ views inside that form, show all of it for printing in some of the
views; have a 200+ event handlers, and 15,000+ lines of C# code, the
results? The form will talk 2 minutes to start, literally 2 minutes; well,
in the multiprocessor dev server, it takes 1 minutes (4 XEON 3.0 Ghz, 1GB
RAM); redo the above with Windows Form, the form will take a second to
start! Well, some times up to 3 seconds.



Use a simple C# code to transform the xslts of the form using c# and the xml
data to html (without InfoPath) it takes a second or 2 on the multiprocessor
server.




I realized the InfoPath forms are ok until they reach the 2 page limit, then
the speed just starts to decrease, and the forms are getting slower.



Well, I mean slower to start in the first time, loading it just takes larger
amount of time, then the form is fast, until you switch to a new view, and
the rendering begins again, well the rendering is not that bad, my biggest
problem today, it the form startup time.



Thank you

 

[Scott Roberts [MSFT]]

Thank you for your feedback. We will look into this.

- Scott

 

[G. Tarazi]

Just an update



I have started improving the performance of the forms, at this stage my goal
is 5 sec max from the point the end user presses of the share point site, to
the form opened completely on his screen; and I found that the C# event
handlers, if commented on compile, the forms start faster (way more faster),
I know there maybe a possible problem with the code inside, but I found also
that the same code if written in Java Script is not causing the problem, I
mean, the form will open way more faster if the event handlers were java
script instead of .net code. (but I am still verifying that point)



Another thing is splitting the form to multiple xsn files, this will make
the development more complicated, since all the forms will share the same
java script file, but it will improve the form performance a lot.



I have been advised here by Microsoft couple of months ago, to split the
large form view to multiple views, in order to make the form faster, and to
have one additional view (combining all the other small views) that I will
use only when I want to print the form or see all the sections together.



The idea is nice, but we found later that having multiple views is
duplicating the xsf file size, and that decreases the form speed, and many
of these views with large sections are making the form slower, so I am
deleting them as part of the performance tuning, and going back to a single
view, and splitting the rest to other separate forms.



And of course moving the form from .net to Java Script, the main idea of
using .net in a form was taking benefit of the power of the framework, but
since that is costly "the form must be signed", and signed forms are harder
to work with, to install, and maintain, and since the xml functions on the
..net InfoPath are different from the System.Xml once, and since only one
developer can work on the form on the same time when the form is in VS.NET,
with part of the power of VS.NET, like unable to take advantage of source
safe for example (for multi developers), and many other issues; I just can'
t see a benefit of having the from in VS and .NET, so I am moving part of
them to Java Script.