ReactorORMController is almost generic!

[seancorfield]

ReactorORMController could, in theory, be renamed ORMController since it relies on the AbstractORMAdapter interface.

Well, it's *mostly* generic. There are two places that I've found so far where it assumes ActiveRecord? style ORMs:

Line 121:

<cfset record = orm.new(table).load(argumentCollection=criteria) />

This should be:

<cfset record = orm.read(table,criteria) />

Line 175:

<cfset record.save() />

This should be:

<cfset orm.commit(table, record) />

This makes the ORM controller more generic and makes it easier to write other ORM adapters.

[joe.rinehart]

I've made the two suggested changes (I'd like it to be as generic as possible), but I'm not 100% sure it can be entirely generic.

There's a good deal of Reactor-specific code that deals with editing of instances in iterators.

I'm not entirely sure there's a good way to address this outside of ORM-specific ORMController implementations.

The options I can think of follow:

1. Move all methods except genericCommit into a GenericORMController. FooORMController would extend this, implementing its own genericCommit. It's not the prettiest, but it'd take some load off of those implementing other ORMs, and allow overriding of whatever was desired.

2. Extend metadata (as we discussed over the phone) to provide things like "iteratorMethodName" for each property, with values like "getFooIterator" for Reactor.

This'd still be problematic, as it'd have to describe how to deal with things like how to manipulate the contents of the iterator (see lines 161-164 and 169-171 of ReactorAdapter? revision 241).

3. Implement an IteratorAdapter? for each ORM that "genericized" the interface of the iterators returned, using the metadata bit we discussed to decribe how to get the iterator, then wrap it in an adapter instance. Bit of a hassle.

4. Implement a RemoveFromIterator?(iterator, propertyname, value) method in the ORM adapter that receives an iterator and removes all records where propertyname=value. Same approach as #3, but doesn't bother with wrapping iterators. Still uses metadata to state method name used to get iterator.

Thoughts?

[joe.rinehart]

(In [264]) Fixes #240,#242,#210

[cfgrok]

Milestone Feature Requests deleted