Re: Most efficient way for a big XForms file

Victor Engmark wrote:
> 
> 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?),

The instances are not that large, like 30 elements/sub-elements, and on 
ly 10-15 submitted for the biggest one for the moment. But the UI part 
for one of the big requests is around 500-600 lines of code. I've only 
completed 5 request (only a big one) and I've like 10 more to do, 4 or 
them a lot more complex.
I'd also like to find a way to batch requests, but i've absolutely no 
idea how.

> 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.)
I've not used readonly until now, but as i'm also using chiba, i'll keep 
that in mind. Thanks.

I'm doing a similar thing with relevancy data. My instance looks like:
<data>
	<request>
		...
	</request>
	<relevant>
		<item1/>
		...
		<itemN/>
	</relevant>
</data>

	When there are optional element/attributes, I use a select with only 
one item (value:true) bound to /data/relevant/itemX and by selecting it 
(or not) the user decide if he wants to give a value for this element. 
The control bound to this element become relevant when this item is 
selected. And I only submit the /data/request part, so the <relevant> 
element is not in the request. The element is required, to force the 
user to unselect if he doen't want to enter a value and avoid having 
null attributes in the request. It works, but if someone has a better 
way, i'd like to hear it. ^^

But my problem is when this optional attribute is inside a <repeat> 
(lots of problems with repeat or is it just me ? ;p), cause if I bind 
the select to an element outside the repeat, its value will be the same 
for each repeated element (then my attributes will all become relevant 
or not at the same time). For now I created a new relevancy element 
inside my request and defaulted its value to "true"; if the user 
unselect it or enter a value, it becomes irrelevant and thus does not 
appear. But if the user unselect it, there is no way to get it back. you 
have to delete this repeated element and create a new one.

In fact I'm looking for a way to have a control that would be relevant 
in the UI while its value would be irrelevant in the instance. But one 
can't use differents binds for the instance data and the control :/

I know I could delete all unwanted elements in the submited data using 
XSLT, but it would be great if I could have a well formed request using 
only XForms.

> - Try to keep XPath dependencies and calculations as simple as possible
> 	(duh!), your future self will thank you for it.

I'm trying, i'm trying ;p



-- 
LACOSTE Florian
While trying continuously, one always ends up succeeding.
Thus: the more one fails, the more one is likely to succeed!

Received on Friday, 16 September 2005 13:10:44 UTC