Re: [Modus-devs] Re: New Code Posted

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

On Thursday, Nov 14, 2002, at 15:12 US/Pacific, Nathan Dintenfass wrote:
> That is one of the reasons I would propose that things like a=20
> persister are tied to a contentObject, not to an application.

I'm not sure. I'd like to be able to create 'bindings' (for want of a=20
better word) for content objects to multiple persisters and renderers -=20=

that's kind of what I think of the facade as doing: acting as the=20
controller for a specific persister/renderer binding to a named content=20=

object.

> I think that org.bacfug.pressRelease vs org.firsenbaum.pressRelease=A0is=
=20
> still a better way to do it than simply "pressRelease"

True, I have no problem with requiring explicitly qualified content=20
object names (users can always create their own aliases to the object=20
factory).

> IMO Modus should not require CFAPPLICATION to run at all.

Um, well, I'm not sure I agree here. Requiring an application name is=20
no big deal. As long as it works with the anonymous application...=20
Which may become a common trick to share scope data with Java. I'm not=20=

quite sure what 'appName' looks like in the anonymous application=20
(Jeremy?).

> I think it's probably OK that org.bacfug.pressRelease has a single=20
> persister, no?

No. See above.

> I guess that with your setup you won't be able to extend an existing=20=

> type.

Not sure why you think that. You can extend a type and then specify=20
that extended type in the descriptor and it should work. The services=20
model just decouples type definitions from instances - that still=20
allows inheritance. Or am I missing your point?

> Personally, if it ends up being server.modus.get() I will always use=20=

> that rather than setting modus =3D server.modus.

I agree. I'm not too keen on the 'shortcut' and I think developers will=20=

quickly get used to this idea of server.<uniqueinstance>.<method>() in=20=

the CFC world (I sure wish we'd gotten 'static' methods to work=20
properly in CFMX... they existed in a very early build but then they=20
went away - to simplify the model, I suppose).

> The server or request scope are better than the application scope=20
> because they don't require CFAPPLICATION and they get around the nasty=20=

> issue of CFC's losing the proper page context.

I'm with you on that. Server scope is my preferred scope anyway for=20
caching.

"SOAP is not so much a means of transmitting data
  but a mechanism for calling COM objects over the Web."
-- not Microsoft (surprisingly!)