On Sat, Feb 21, 2009 at 5:12 PM, Henry Ho <[email protected]> wrote:
> I see... the reason why I use cfproperty tags to specify a type that's
> actually an interface is because I was trying to write a validation
> framework. I thought cfproperty is a great place to specify the
> metadata of the class, so the validation framework can use the type
> attribute to check if the property is really of that type.
<cfproperty> has a specific meaning for web services - it defines the
names and types of WSDL data type.
Usually you define specific VOs (value objects) for use with web
services so that you have control over WSDL generation without
interfering with anything else you might want to do with a full domain
object.
You might consider this sort of approach:
DomainObject.cfc is your full-fledged object with validation etc etc
- it has <cfproperty> for validation etc
- it has variables.instance which is where it stores the instance data
- an instance of DomainObjectVO
DomainObjectVO.cfc is your value object for web services
- it has <cfproperty> tags specifically for WSDL generation
- it has no methods, and uses THIS scope for its data
In other words, DomainObjectVO is a "typed struct" (which is what web
services need) so inside DomainObject's init() you have this:
function init() {
variables.instance = createObject("component","DomainObjectVO");
}
and elsewhere you treat variables.instance as a regular ol' struct.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" 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/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
