cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: [cforms] xreporter expressions on (Avalon) steroids
Date Wed, 21 Jul 2004 17:54:51 GMT
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="..."/>)

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.

>  OTOH,
> writing our own validators is kind of overkill: as I said before, the
> current usecases are more convoluted than complex, and in most cases what
> we need is "chaining" different validation rules rather than write
> monolithic ones.
> 
> 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.

>  Problem
> is, though, that we could really use composition in expression lifecycle:
> atm, specifically, we need to access a Datasource, and we are skeptical
> about using one of the available internal-only Cocoon hacks (or build our
> own) to grab a ServiceManager.
> 
> 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?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message