Re: Most efficient way for a big XForms file

Florian Lacoste:
> 
> I'm trying to use XForms as UI for a WS, allowing the user to send 
> differents requests, each with differents mandatory or optional objects 
> and attributes.
> 
> For the UI part, I use a <xforms:switch> with <xforms:trigger> to select 
> which type of request must be sent. But for the model part, I wonder if 
> some kind of structures are better than others.
> 
> Should I use one model with several instances, one for each type of 
> request ? Or rather one different model for each type of request (that's 
> what i'm using now)? Or symply one huge model with a huge instance with 
> one sub-element for each  type of request, and the <xforms:submission> 
> chosen would select which parts must be submitted ?
> 
> Some of the attributes required are common to most requests, so there 
> are a lot of common elements in my cases. But even so there are not 
> always to be inserted in the same places in the request. Maybe if I used 
> only one model I could avoid repeating these portions of code with a 
> complex relevant attribute ?
> 
> Anyway, maybe this isn't even worse the trouble and all these solutions 
> are more or less equivalent, but I'd like to have the opinion of people 
> more experimented than I am wih XForms.

Hello,

I cannot claim to be very experienced, and I don't know how much
functionality and how large instances you are going to handle (link?),
but here are some observations from working with the Chiba web module:
- Try to separate all read-only data from the rest, and group them into
	independent instances as much as possible. This eases the process of
	changing data, and marking them read-only makes loading faster because
	little or no validation is needed.
- Try to minimize the number of objects in the read-only data; this is
	the only serious bottleneck in my own system now. You might consider
	serving it dynamically.
- Also, loading as little data as possible for each request type could
	help you avoid scaling problems.
- (In Chiba, you can gain performance by putting read-only data into a
	separate model. This will not change your XPaths (models are
	"transparent"), but they will not be revalidated when the other models
	change.)
- Try to keep XPath dependencies and calculations as simple as possible
	(duh!), your future self will thank you for it.

HTH :)

Disclaimer: YMMV, blah, blah, assumptions, special requirements, etc.

-- 
Victor Engmark
"Quid quid latine dictum sit, altum viditar" - "What is said in latin,
sounds profound"

Received on Friday, 16 September 2005 12:11:22 UTC