IMHO, expressing rules using first class Java objects *can* be just as
flexible as defining rules in an XML file.
The analog to changing a value in an XML file is using a property editor to
change values stored in a JavaBean (thus avoiding recompiling). The upside
of this approach is simpler integration with visual editors (simply
implement a property editor for your form-bean). Ultimately, I feel this is
where your less technical people can begin to contribute more effectivly.
The other route requires hand-rolling a visual editor for your XML scheme
and/or having your users learn quite a bit about the intricacies of your
schema.
I the case Nick outlined below, I would simply use polymorphism. Once in
place, if you really wanted to materialize these objects from an XML file
then the Struts digester could be indispensable. Something like this might
apply:
Employee <<interface>>
|
+-- AbstractEmployee <<abstract-base>>
|
+-- ExecutiveEmployee
+-- ExploitedEmployee
public interface Employee {
Location getLocation();
JobCode getJobCode();
float getSalary();
float calcBonus();
}
public abstract class AbstractEmployee
implements Employee {
private Location location;
private JobCode jobCode;
private float salary;
public AbstractEmployee(float salary, Location location, JobCode jobCode)
{
if(location == null) {
throw new IllegalArgumentException("location cannot be null.");
}
if(jobCode == null) {
throw new IllegalArgumentException("jobCode cannot be null.");
}
this.salary= salary;
this.jobCode= jobCode;
this.location= location;
}
public Location getLocation() { return location }
public float getSalary() { return salary; }
}
public final class ExecutiveEmployee
extends AbstractEmployee {
public ExecutiveEmployee(float salary, Location location) {
super(salary, location, JobCode.EXECUTIVE);
}
public float calcBonus() {
// use location & jobcode to return
// a large chunk of change to the executive.
}
}
public final class ExploitedEmployee
extends AbstractEmployee {
public ExecutiveEmployee(float salary, Location location) {
super(salary, location, JobCode.EXPLOITED);
}
public float calcBonus() {
// use location & jobcode to return
// a small chunk of change...
}
}
-- Levi
> -----Original Message-----
> From: Nick Afshartous [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 22, 2001 12:44 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: server-side, java-based validation rules for struts..
>
> David Winterfeldt writes:
> > I don't think there would be anything wrong with your
> > idea, but I think it is a little more flexible keeping
> > the validation separate from the ActionForm. I
> > started working on a validation framework, but I put
> > the info in an xml file. I would rather change a
> > value in an xml file than having to recompile my code.
> >
> >
> > * It makes the validation rules more accessible to
> > less technical people. One day the XML might tie into
> > a JSP editing tool to provide easy access and editing
> > of the validation rules.
>
> I've been thinking of doing something similar for
> the logic rules associated with business objects.
> For example, consider an Employee class where the
> logic to calculate the bonus is based on some of the
> other attributes of the object (i.e. jobcode, location).
>
> It would be useful to define these rules in XML to
> facilitate maintenance as you point out for validation
> rules.
> --
>
> Nick
>
