Stupid question.. why not just do this as a relationship?
Mark
On Fri, Dec 5, 2008 at 11:56 AM, Matt Graf <[EMAIL PROTECTED]> wrote:
>
> Yes I agree in most cases what I am trying to is not the best idea
> but, in our system we have four fields that are the same in every
> table. Which are insOn insByFK updOn and updByFk. and the fk is the
> foregin key to the user table and the our keys are UUID's which make
> no sense to user so in my base decorator I have getcreatedby and
> getupdatedby which looks up the user first and last name so I can
> display the name on the record.
>
>
> <cffunction name="getUpdatedBy" access="public" returntype="any"
> output="false">
> <cfargument default="" name="userid" required="false"
> type="string">
> <cfscript>
> var local = {};
> local.updByFk = getUpdByFk();
> local.sReturn = "";
> local.map = StructNew();
> if(local.updByFk neq "00000000-0000-0000-0000000000000000" and
> local.updByFk NEQ ''){
> StructInsert(local.map, "userid", local.updByFk);
> local.user = listUserByPropertyMap(local.map);
> local.sReturn = local.user.FirstName & " " &
> local.user.LastName;
> }
> if(local.sReturn eq '' and arguments.userid NEQ ''){
> StructInsert(local.map, "userid", arguments.userid);
> local.user = listUserByPropertyMap(local.map);
> local.sReturn = local.user.FirstName & " " &
> local.user.LastName;
> }
>
> return local.sReturn;
> </cfscript>
> </cffunction>
>
> <cffunction name="getCreatedBy" access="public" returntype="any"
> output="false">
> <cfargument default="" name="userid" required="false"
> type="string">
> <cfscript>
> var local = {};
> local.insByfk = getinsByfk();
> local.sReturn = "";
> local.map = StructNew();
> if(local.insByfk neq
> "00000000-0000-0000-0000000000000000" and
> local.insByfk NEQ ''){
> StructInsert(local.map, "userid",
> local.insByfk);
> local.user = listUserByPropertyMap(local.map);
> local.sReturn = local.user.FirstName & " " &
> local.user.LastName;
> }
> if(local.sReturn eq '' and arguments.userid NEQ ''){
> StructInsert(local.map, "userid",
> arguments.userid);
> local.user = listUserByPropertyMap(local.map);
> local.sReturn = local.user.FirstName & " " &
> local.user.LastName;
> }
> return local.sReturn;
> </cfscript>
> </cffunction>
> On Thu, Dec 4, 2008 at 3:15 PM, Brian Kotek <[EMAIL PROTECTED]> wrote:
>> In theory it would probably be pretty easy for Mark to allow an option to
>> specify a generic Decorator at the root level that would be applied to any
>> objects that don't have a decorator explicitly defined. Personally it sounds
>> like a questionable idea, because in my experience, every object has it's
>> own Decorator that extends a base Decorator (as others have mentioned). I
>> can't really imagine a use for a Decorator that would be applied generically
>> to a large number of objects. Or, more specifically, I can't imagine a case
>> where one would use this and not rapidly run into a brick wall and switch to
>> individual decorators.
>>
>> On Thu, Dec 4, 2008 at 2:19 PM, Matt Graf <[EMAIL PROTECTED]> wrote:
>>>
>>> I don't think I am explaining myself very well lets see if I can
>>> explain it a little better
>>>
>>> Here is an example of where I tell transfer to use my decorator
>>> <object name="widget_one" table="widget_one"
>>> decorator="model.decorators.widget_one">
>>>
>>> now what I want is for transfer to use my base decorator without
>>> telling transfer to do so.
>>>
>>> is that possible?
>>>
>>>
>>>
>>
>>
>> >
>>
>
> >
>
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
--~--~---------~--~----~------------~-------~--~----~
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
You received this message because you are subscribed to the Google Groups
"transfer-dev" 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/transfer-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
