cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [cforms] xreporter expressions on (Avalon) steroids
Date Thu, 22 Jul 2004 11:27:55 GMT

On Jul 21, 2004, at 7:54 PM, Bruno Dumon wrote:

> On Wed, 2004-07-21 at 18:23, Gianugo Rabellino wrote:
>> I'm currently working on a more-than-average sized cforms 
>> applications. We
>> have quite a few usecases where validation is kind of a PITA, 
>> requiring
>> quite a few of business logic to be performed. Nothing difficult, 
>> nothing
>> that requires heavy algos to be created, but still (as an example) 
>> quite a
>> bit of interaction with datasources to check for data consistency.
>> So far, we have been using Javascript, but I'm feeling we would hit a 
>> wall
>> very shortly since the road to spaghetti code is dangerously close.
> Maybe you could refactor some of that code into java classes that you
> call from the javascript. Or you can also write the validators directly
> in Java (which doesn't require declaring them in cocoon.xconf and 
> making
> builder classes for them, there is also something like <fd:java
> class="..."/>)

Yup, this solves the language issue but not the architectural one: 
still no avalon context available.

> Or attach one custom validator to the form itself and perform all your
> validation needs from there, which allows to organize your validating
> logic in any way it fits you best.

Which doesn't promote reuse though, since it will validate on the 
specific combination of widgets in the forms..

>> xReporter's expressions seems to us the next natural choice: writing
>> expressions is easy, yet there is all the power/flexibility of Java 
>> under
>> the hood together with the possibility of chaining stuff together.
> You could also consider writing a limited set of configurable custom
> validators, unless you need the extra flexibility that expressions add.

That's exactly what I'd like to achieve. Chaining expressions is a big 
plus here.

>> Now, I reckon that xReporter expressions were designed as simple 
>> snippets
>> of easy code, and I sure see the benefits of KISS, but still we could 
>> use
>> some cooperation between components inside them. Do you have any handy
>> solution we might have overlooked and/or do you think the (easy to
>> implement) solution could be useful for other CForms users? Are your 
>> FS
>> alarms well off-scale already? :-)
> Technically it would be possible to give expressions access to the
> servicemanager by putting it in the expressioncontext object that is
> given to each expression. I'm not sure if it is a good thing to do,
> maybe you could share some examples of what you're trying to achieve?

I hear you, I'm concerned as well. Let me see if I can make you an 
example: some of our forms require that a given requested operation has 
to be performed with some date constraints (i.e.: "same day", "not 
earlier than", "no later than"). In some cases, also, it has to be in a 
working day where "working" can't be defined algorithmically (as in 
"throw away sat, sun, christmas and easter") but has to rely on a list 
of valid working days which is kept on a database. In some cases, you 
need both (ANDed or ORed). So, we have two different checks to do, and 
all their permutations (timeframe only, valid day only, timeframe and 
valid day ANDed or ORed). As you can see, this screams expressions (or 
some other unforeseen kind of composition).

Can you see my point and maybe provide a different solution? Keep in 
mind though that this is just one of our convoluted usecases...

Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance:

View raw message