Thanks everybody: I made an architecture change on where to keep my
model functions,here is the approach I have taken......

My initial setup I had a usercontroller.cfc and a user.cfc as well as
the user record/gateway objects reactor was generating. I have
eliminated the user.cfc and moved all the methods  to reactor
userrecord and usergateway objects (therefore they have reactor
because they ARE reactor).
Then I did also implement a "service layer" (exposed by remoteFactory)
that runs parallel with the controller layer with some overlap (the
calls to the model are similar)

There is one really neat benefit to this setup: before, the only way
to fire off my getUserToDoList() method was to broadcast a message and
go through the controller, now by integrating most of my model into
the reactor extended record objects I can access the methods by firing
the broadcast OR by calling getUserToDoList() right off any reactor
userrecord I am working with

This app will be a monster so I let me know if i am either too anemic or obese




On 10/31/06, Ken Dunnington <[EMAIL PROTECTED]> wrote:
FYI, The Reactor factory is available in CS when using MG:U as a bean
called "ormService", so you can add this to your bean def as Peter
suggests:
<property name="reactorFactory"><ref bean="ormService" /></property>

I personally use a Service Layer that is well suited to being proxied
by the RemoteFactoryProxy, and this layer is where I would inject the
ORM service.

On 10/30/06, Peter Bell <[EMAIL PROTECTED]> wrote:
> Personally I'd use CS to create the model and would use it to inject the
> Reactor factory into the necessary parts of the model (just include it in
> the CS XML config and add the arguments to your model constructor), but
> someone on the list with more MG, Reactor and CS experience may be able to
> give a better, more MG specific response to this.
>
> I would NOT put it in application scope as the whole point of CS is to avoid
> having to do that.
>
> Best Wishes,
> Peter
>
> On 10/30/06 3:23 PM, "Doug Sims" <[EMAIL PROTECTED]> wrote:
>
> > So the question is: so should I put the orm factory in the application
> > scope so I can access it from my model? calling
> > getmodelglue().getorm() only seems to work from the controller, so I
> > assumed you had to pass it in to the model.
> >
> > Thanks
> > Doug
> >
> >
> > On 10/30/06, Peter Bell <[EMAIL PROTECTED]> wrote:
> >> Hi Doug,
> >>
> >> Just one general comment is that it really isn't the job (IMO) of the
> >> controller to provide the model with the ORM beans. The model should work
> >> self standing. The controller is just responsible for handling form, URL 
and
> >> (probably) session scopes and for providing well parameterized calls to the
> >> model and then to take the returned data from the model and to pass that to
> >> the view.
> >>
> >>
> >> Best Wishes,
> >> Peter
> >>
> >>
> >> On 10/30/06 2:40 PM, "Doug Sims" <[EMAIL PROTECTED]> wrote:
> >>
> >>>   Overall Goal:I am trying to expose a webservice (* using a
> >>> coldspring RemoteFactoryBean to create a remoting facade).
> >>>
> >>> I may be mixed up between the M and the C in MVC, but my model
> >>> currently requires orm gateways or even the whole orm as a param.
> >>>   In my current setup (see below) the controller is passing an
> >>> instance of my orm(reactor), or sometimes just a gateway into the
> >>> model. When I create the RemoteFactoryBean of the model directly, it
> >>> expects the orm to be passed as a param. I was thinking by exposing
> >>> the controller through the webservice, it would provide whatever the
> >>> model needed. Here is the function in my controller as well as the
> >>> corresponding one in the model
> >>>
> >>> ----------------------------Controller Function------------------------
> >>> <CFFUNCTION name="getUserToDoList" access="public" returntype="void"
> >>> output="false">
> >>>   <CFARGUMENT name="event" type="any">
> >>> <cfset var UserID = session.user.getUserID()>
> >>> <cfset var ORM = getModelGlue().getORMService() />
> >>> <cfset var getList = getUserObject().getUserToDoList(UserID,ORM) />
> >>> <cfset arguments.event.setValue("UserToDoList", getList)>
> >>> </CFFUNCTION>
> >>>
> >>>
> >>>
> >>> -------------Model Function---------------------------------------
> >>> <cffunction name="getUserToDoList" access="public" returntype="query"
> >>> output="false" hint="I get the user to do list data.">
> >>> <cfargument name="UserID" type="string" required="true" />
> >>> <cfargument name="ORM" type="any" required="true" hint="I am the ORM
> >>> service, passed in by my controller" />
> >>> <cfset var myUserID = arguments.userID />
> >>> <cfset var myORM = arguments.ORM />
> >>> <cfset var myList =
> >>> myORM.createGateway("usertodolist").getByFields(userid="#myUserID#")
> >>> />
> >>> <cfreturn myList />
> >>> </cffunction>
> >>>
> >>> Should my model access the orm in another way?
> >>>
> >>> Thanks in Advance,
> >>> Doug
> >>>
> >>>
> >>> On 10/30/06, Joe Rinehart <[EMAIL PROTECTED]> wrote:
> >>>> Hey Doug,
> >>>>
> >>>> That's a bit beyond the scope of what Model-Glue is meant for:  if
> >>>> there's application logic inside your controllers, it should be moved
> >>>> into a model class.  Then, you can use the class from either your
> >>>> Model-Glue app or a remote application.
> >>>>
> >>>> Can you maybe provide more info on what this controller does?  We can
> >>>> try to sort it out together.
> >>>>
> >>>> -Joe
> >>>>
> >>>> --
> >>>> Get Glued!
> >>>> The Model-Glue ColdFusion Framework
> >>>> http://www.model-glue.com
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >
>
>
>
>
>


--
It is by the fortune of God that, in this country, we have three
benefits: freedom of speech, freedom of thought, and the wisdom never
to use either.
 -- Mark Twain



Reply via email to