Re: [Modus-devs] Some general Modus comments to start with

[Sean A C. <se...@co...>]

On Tuesday, Nov 5, 2002, at 17:00 US/Pacific, Jeremy Firsenbaum wrote:
> Yes, yes. That is kind of what Sean was getting at when he mentioned=20=

> syntactic sugar. You can have a wrapper or facade component that=20
> handles all of the interaction with the=A0"dumb" layers of the system.=20=

> Sean had actually mentioned a few=A0UDFs, but I think another static =
CFC=20
> would be the

Yes, a static CFC is really just a wrapper for the UDFs I was=20
considering anyway - but I was trying to avoid the=20
server.staticInstance.methodCall(object) syntax and reduce it to=20
methodCall(object) - it's just a matter of degree.

> So a service-based Modus might have the following components:
> =A0
> Persister - this is responsible for moving data on and off disk. It=20
> should maintain=A0the memory-based cache as well.
> =A0
> ContentObject - this essentially provides data validation services.=20
> Anything else?
> =A0
> Renderer - suited primarily to HTML for now. At the least this=A0takes=20=

> over for renderBasicForm().
> =A0
> Facade - the sole instance that is created externally. It=A0finds or=20=

> instantiates the appropriate components as defined in the descriptor.=20=

> Provides coarser-grained access to the dirty work of retrieving,=20
> rendering, validating and storing a contentObject. This is where the=20=

> "substantially less coding" requirement is fulfilled.

Yes, this fits well with my proto-thoughts on a service-based=20
architecture. Thanx Jeremy.

> That might be tricky to provide method-based access since the=20
> persister would probably work best if it returned a struct. For=20
> example: honda.fields.color =3D "blue". In fact, the EJB example that =
I=20
> mentioned does just this.=A0They use a=A0value object java bean to =
return=20
> a methodless instance of the EJB and coldfusion treats it=A0just =
like=A0a=20
> struct. I hate to see the methods go too, making the system feel less=20=

> object-like, but it seems to be the best solution for getting data in=20=

> and out of static components.

Bear in mind that CFMX already turns honda.fields.color into a series=20
of method calls so adding getField() and setValue() methods really only=20=

adds overhead. We need to remember that CFMX is not Java :)

I imagine a single attribute in each 'object' that is a reference to=20
the Modus entity through which the Modus methods interact. Given the=20
three services and the facade mentioned above, that attribute would=20
either be a reference to the facade instance or a struct containing=20
references to all of the above. The reason that might be important is=20
to allow non-persistent objects, non-valdated objects and non-rendering=20=

objects. Of course, if we have 'null' versions of those and we=20
construct the facade instance from the three service objects, then we=20
could fall back to just a references to the facade instance.

In other words, you're talking about honda.fields.x and I'm suggesting=20=

adding honda._modus to refer to the single facade instance. It would be=20=

added automatically by Modus object creation / retrieval methods and=20
used by store / update / etc methods.

Am I making sense?

"I can smell your brains!"
-- Mittens the Kitten : http://www.matazone.co.uk/theotherside.html