Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43CD0AB6.3080906@lojjic.net>
Date: Tue, 17 Jan 2006 08:18:14 -0700
From: Jason Johnston <cocoon@lojjic.net>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Dynamic CF Forms: JX, XSLT or Flowscript? (Performance!)
References: <loom.20060117T094346-320@post.gmane.org>
In-Reply-To: <loom.20060117T094346-320@post.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Florian Leinberger wrote:
> Hi,
> 
> I have a Cocon Form. Depending on the rights of the User, parts of the form
> (i.e. a repeater, a group, widgets) should be shown or hidden. In the flowscript
> I have the information weather the user has the right to see a special part of
> the form or not.
> 
> I see three possibilities how to achieve this:
> 
> a) Setting the widgetstate in the flowscript depending on the rights of the user
> (desadvantage: I don`t really have full control over the layout of the form in
> just showing/hiding the widgets, difficult for groups,...).
> 
> b) Parsing the form-template with an additional own xsl-Stylesheet (we have done
> this before, works allright, problem though when reloading the form)
> 
> c) Using jx-Templates (probably the easiest solution to handle)
> 
> Performance is very much of a concern for us. The portal we have built on Cocoon
> is frequented by many users and performance isn´t very well already today. So we
> are hesitating to apply JX to a huge part of our forms. But maybe this is wrong
> and it´s better than adding own xsl-transformations to the forms? Can anybody
> share any experiences or thoughts on this? 

There is a known issue with performance of JX macros that affects CForms 
template evaluation, in the version of JX currently included in Cocoon 
2.1.x.  However, on the dev list there is currently a vote underway to 
include the new refactored version of JX from the 2.2 trunk into 2.1.9, 
which IIUC solves that performance issue so that it is now as fast or 
faster than the FormsTransformer.  FWIW.

> a) b) or c) ?

I'd probably suggest a combination of a) and c).  c) will give you the 
most control over the template, but keep in mind that the template is 
merely a view of the form model, it doesn't lock down parts of that 
model.  So if you were to hide a section of the form in the template but 
leave those widgets active in the form model, then a crafty user could 
still manipulate those parts of the model by sending the appropriate 
request parameters manually.  If security is at all a concern for you 
then you'll also want to make sure the form model is locked down. 
Widget states are probably the best way to achieve that (another way is 
to dynamically generate your definition/binding via cocoon:// requests 
but that's messy and slow.)

If you're worried about widget states not giving you enough control over 
presentation, keep in mind that if you use JX you have access to the 
form model in the JX expressions, so in your template you could use the 
widget states of certain fields/groups to perform more complex 
conditionals than just showing/hiding fields or groups.

Just my thoughts, hope that helps.
--Jason


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org