Chase235 / cloudcourse

Automatically exported from code.google.com/p/cloudcourse
Apache License 2.0
0 stars 0 forks source link

Rationale for rules.py implementation #6

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Hi Guys

Django doesn't yet seem to have a defacto standard for implementing complex 
business logic so I 
was pleased to explore your approach.

Would you mind sharing the rationale which lead to this implementation.

Was there an existing system you based the implementation on?

Were there a disadvantage to using a lighter function based rule implementation 
(like the 1.2 
validation system) rather than a classed based approach?

Would you recommend this approach for others?

Thanks for sharing cloudcourse it with us.  I'm enjoying reading through the 
code.

cheers, Oliver

PS. Feel free to close this if it's an inappropriate use of the issues system.  
It seemed like the best 
way to reach out.

Original issue reported on code.google.com by olivergeorge on 30 May 2010 at 5:00

GoogleCodeExporter commented 9 years ago
We started this implementation from scratch.
The goal was not so much to build a full fledged rule engine, but build a 
system to be flexible enough so we can add/remove rules easily at different 
levels. 
And naturally we ended up building a simple rule engine.

I think using a class vs functions gives us  maintainability  advantages as we 
leverage polymorphism for a bunch of rules. But functions would probably work 
just fine too.

cloudcourse mailing list is probably better to follow up on this.

Original comment by ir...@google.com on 5 Nov 2010 at 2:46