> I'm going to cop-out and go with "it depends." If it meets your > needs, I'd go ahead and pass your struct. If at some point in the > future you need a formal, <cfproperty>'d TO, it shouldn't be hard to > refactor to it. > > For most things, I don't really see that need for the TO or the harm > in just passing the Bean itself along to begin with - why is some sort > of TO (your struct) necessary to begin with? Would your needs be met > by just passing the Bean back to your view? > > -Joe
In the MVC app structure I'm thinking about, passing a reference to the model into the view is probably the most natural thing to do. There's no thrash creating it, no other var created, simple. What made me stop and ask these questions were two things: a) I thought the controller should have references to the model and view, but they shouldn't know about each other, and b) thinking about how the view would access the model's instance data. Re b), I wouldn't want model data to be in public vars just for this purpose, so the view (say a cfml template at bottom) would need to contain a bunch of getter calls. That struck me as tying it somewhat to the model. Passing in a dumb data struct, or a typed object that really is just the contents of that dumb struct as public vars, seems to assume much less external context. "I need this data, and it gets passed to me, end of story.", as opposed to "I need this data, and I get passed a complex object with a bunch of methods that allow me to access it." Re a), it is true that the view wouldn't exactly be knowing about the model, just about "some object with the access methods I need". That it happens to be the actual model object in some cases is an implementation convenience only; none of its behaviors beyond the needed getters matter. Still, it just seemed cleaner and tighter that the view sees only an object with the relevant data, nothing fancier. Thoughts? Dave Merrill ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
