cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: [cforms] xreporter expressions on (Avalon) steroids
Date Fri, 23 Jul 2004 08:31:10 GMT
On Thu, 2004-07-22 at 13:27, Gianugo Rabellino wrote:
> 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.

Just had a closer look and it seems what I wrote above doesn't exist. It
wouldn't be hard though to implement it, and get the validator through
the Avalon lifecycle as Tim suggested. Since this only happens once when
building the form definition, efficiency certainly wouldn't be a

> > 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...

Unless you fall back to java or javascript code, I have no alternative.

Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message