yes, with "real" coupling i just meant wiring the actual Model
together (Services & Gateways) inside ColdSpring.xml.
and injecting beans via "beans=" acts as an "easy connection" of your
Controller to the various Services
On Sep 23, 2:31 pm, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote:
> "Real coupling" as in what? Not sure I follow. Decoupling (getting
> things to talk without having to know who they're talking to) is one
> of the primary goals of OO... so coupling isn't a goal unless you're
> using the word in the sense of "hooking stuff up to other stuff"...
> which is my guess.
>
> And in that case, while I would suggest you not use a reserved
> keyword ;), yeah... you plumb stuff together in CS by setting up your
> singleton instances and wiring them together. And, indeed, using the
> beans="" attribute in an MG controller is just a shortcut for doing
> the exact same thing from within your app.
>
> J
>
> On Sep 23, 2008, at 2:57 AM, Chris H wrote:
>
>
>
> > thanks all for your replies, especially Jared for his enormous one ;D
>
> > so the "real" coupling should still happen at the Service & Gateway
> > level (via Coldspring.xml). the new automatic injection into the
> > Controller should just act as an easier way to "connect" it to the
> > Service layer, correct?
>
> > On Sep 22, 9:08 pm, Jared Rypka-Hauer <[EMAIL PROTECTED]> wrote:
> >> Chris,
>
> >> Let me chime in here with the chorus of other voices:
>
> >> The use of anything that extends
> >> mogleglue.gesture.controller.Controller definitively binds your
> >> application to the framework in question... however, since you're
> >> only going to be extending the MG core controller class when you're
> >> building your own controller in a ModelGlue app, it's a moot point...
> >> using the built-in bean injection is just using a feature of the
> >> framework when you're building an application that uses the
> >> framework.
>
> >> Where you wouldn't want any reference to the framework is actually
> >> one tier below the controller layer... your service layer. At least
> >> in theory, your controller talks to services and services talk to
> >> everything else.
>
> >> Allow me to expound for a moment? :D
>
> >> Let's look at a psuedo-codish method you might find in an MG
> >> controller:
>
> >> <cffunction name="saveUser">
> >> <cfargument name="event" />
>
> >> <cfset var UserID = event.getValue("UserID",0)>
> >> <cfset var userName = event.getValue("userName","")>
> >> <cfset var emailAddress = event.getValue("emailAddress","")>
> >> <cfset var password = event.getValue("password,"")>
>
> >> <cfset var result =
> >> variables.instance.userService.saveUserProfile
> >> (UserID,userName,emailAddress,password)>
>
> >> <cfif result>
> >> <cfset event.addResult("saveSucceeded")>
> >> <cfelse>
> >> <cfset event.addResult("saveFailed")>
> >> </cfif>
> >> </cffunction>
>
> >> From this we can extract a few observations and parse them into a
> >> couple rules of thumb that I use to keep my own mind pointed in the
> >> right direction as I develop applications (not counting laziness,
> >> client expectations, and/or anything else that may cause me to
> >> randomly break my own thumbs):
>
> >> 1) Controller methods accept an event object as their sole argument.
> >> It contains all the data from the form and URL scopes as well as
> >> anything injected into it via onRequestStart events (often
> >> application constants get stuck in the event object for convenience).
>
> >> 2) Service-layer functions take discrete arguments relevant to
> >> whatever objects they're dealing with... so while in this example,
> >> saveUserProfile(userId,username,emailAddress,password) is called with
> >> discrete arguments extracted from the event object you could (were
> >> you to be lazy and like to take chances with your apps) call
> >> saveUserProfile(argumentCollection=event.getAllValues()) and have
> >> done with it.
>
> >> 3) What goes on in the service layer is effectively hidden from the
> >> controller and therefore the service methods can be used to very
> >> simply service a Flex application, an application using a different
> >> framework, or ad-hoc code. Using ColdSpring to manage your service-
> >> layer allows you to use AOP and provide your service layer to Flex,
> >> AIR and AJAX applications very easily and passing discrete arguments
> >> into service methods can make your life a lot easier sometimes.
>
> >> Variation on rule 2: passing Transfer (or Reactor, or your own Model)
> >> objects from the service thru the controller into the view makes a
> >> good many things a great deal easier. So having userService.getUser
> >> (userID) return a User object that's then stuffed into the event
> >> object is fine... so your controllers can then use things like
> >> makeEventBean() and stuff which simplifies somethings and makes
> >> others more difficult. I actually tend to prefer this variation in
> >> practice, but prefer the notions of the other approach in theory.
>
> >> So, the goal is to make your service layer be totally independent of
> >> any other facility, but you can use built-in features of the
> >> framework when you're creating application code in an app that's
> >> making use of the framework.
>
> >> Did that make sense? I can always try again: words are free! ;)
>
> >> Laterz,
> >> J
>
> >> On Sep 22, 2008, at 11:15 AM, Chris H wrote:
>
> >>> just a general question, because i've just gotten into ColdSpring
> >>> and
> >>> everything related:
> >>> it's not a good thing to use the new automatic bean injection
> >>> because
> >>> this creates another tier to the framework (which according to Briak
> >>> Kotek and others should be avoided). it's a nice feature to have for
> >>> easy injection, but not ideal for a true OO design, right?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
For more about Model-Glue, check http://www.model-glue.com .
-~----------~----~----~----~------~----~------~--~---
