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?
>>
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
