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

[Jeremy F. <jfi...@ma...>]

    Yes, a static CFC is really just a wrapper for the UDFs I was =
considering anyway - but I was trying to avoid the =
server.staticInstance.methodCall(object) syntax and reduce it to =
methodCall(object) - it's just a matter of degree.
It will probably be easier to address this once we have a core to put a =
facade on. It might turn out that this would be application specific so =
that you could have a facade in server scope with udf calls as a mask, =
or the facade itself might store some instance data so that you would =
store it in session scope. The advantage here would be the ability to =
plug in a security module that has access to user permissions and the =
like. What's more the facade could even be instantiated per request if =
needed. I think the point is to build the core modules and see where =
that leaves us.
    I imagine a single attribute in each 'object' that is a reference to =
the Modus entity through which the Modus methods interact. Given the =
three services and the facade mentioned above, that attribute would =
either be a reference to the facade instance or a struct containing =
references to all of the above. The reason that might be important is to =
allow non-persistent objects, non-valdated objects and non-rendering =
objects. Of course, if we have 'null' versions of those and we construct =
the facade instance from the three service objects, then we 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 adding honda._modus to refer to the single facade instance. =
It would be added automatically by Modus object creation / retrieval =
methods and used by store / update / etc methods.

Haven't quite grokked this suggestion. How would honda._modus be used? =
Here's sort of how I'm thinking Modus would be used:

In a global include:

<cfif NOT isDefined('server.modus.facade')>
<!--- Define and retrieve an xml descriptor- -->
<cffile action=3D"READ" file=3D"modustest\descriptors\pressrealease.xml" =
variable=3D"xml">
<cfset pressreleasexml =3D xmlParse(xml)>

<!--- Instantiate the facade - we're putting this into the server scope, =
but it doesn't have to be --->
<cfset server.modus.facade.pressrelease=3D =
createObject("component","org.bacfug.modus.facade.basefacade").init(press=
releasexml)>

<!--- Continue the same process as above for all content objects --->
</cfif>

Internally, the facade parses the xml and instantiates the appropriate =
modules. That means that the descriptor is really driving the whole =
thing.

Would the honda._modus idea fit into this picture?

-Jeremy