This may be a dump question but is there a way to create a global
decorator? And have another decorator? basically I have a couple of
functions that I want all of my transfer beans to have but I don't
want to create a decorator for every transfer object.
You mean something like this:
1) Create a decorator that extends transfer.com.TransferDecorator
2) All your other decorators extend this one
Alan
From: spiraldev [EMAIL PROTECTED]
To: transfer-dev transfer-dev@googlegroups.com
Sent: Thursday, December 4, 2008
Create a BaseTransferObjectDecorator that extends
transfer.com.TransferDecorator. Then have your decorator extend
BaseTransferObjectDecorator.
HTH
--~--~-~--~~~---~--~~
Before posting questions to the group please read:
Yes that is what I have now. But what I want is the ability to have a
global decorator without creating a decorator for my transfer object.
Example I have a widget that does not need a decorator other then what
is in the base decorator.
On Thu, Dec 4, 2008 at 10:58 AM, Matt Quackenbush [EMAIL
Absolutely. I have a base Decorator that my concrete decorators extend.
The base decorator itself extends transfer.com.TransferDecorator.
Paul
On Thu, Dec 4, 2008 at 10:51 AM, spiraldev [EMAIL PROTECTED] wrote:
This may be a dump question but is there a way to create a global
decorator? And
You could use decorator=path.to.baseDecorator. :)
Paul
On Thu, Dec 4, 2008 at 11:02 AM, Matt Graf [EMAIL PROTECTED] wrote:
Yes that is what I have now. But what I want is the ability to have a
global decorator without creating a decorator for my transfer object.
Example I have a widget
On Thu, Dec 4, 2008 at 1:19 PM, Matt Graf 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
that is what I thought.
On Thu, Dec 4, 2008 at 11:20 AM, Matt Quackenbush [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 1:19 PM, Matt Graf 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
I would look back at what Paul suggested:
You could use decorator=path.to.baseDecorator.
Then you don't need a decorator cfc, you just need a few extra
characters in your transfer.xml file.
If you're really too lazy to do that, then I have an idea that would
probably work, but it would be
On Dec 4, 2:20 pm, Matt Quackenbush [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 1:19 PM, Matt Graf 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
That's some fancy voodoo, Elliot (and Bob). Event observers are
powerful...if only they made a great Americano... ;)
Paul
On Thu, Dec 4, 2008 at 11:59 AM, Elliott Sprehn [EMAIL PROTECTED] wrote:
On Dec 4, 2:20 pm, Matt Quackenbush [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 1:19 PM,
again, no need to jump through all the crazy hoops, just use a base transfer
decorator. It will probably be a lot easier to maintain and debug.
Chris
On Thu, Dec 4, 2008 at 7:56 PM, Matt Graf [EMAIL PROTECTED] wrote:
Yes I agree in most cases what I am trying to is not the best idea
but,
I'll grant you that you'd have to add
decorator=my.path.to.my.Decorator to each tag, but why can't you
just put this in one decorator and apply that to all the classes?
Even a find/replace operation should do the trick... if you have
something that supports regex, find/replace object (.*)
In short: No.
Tips for the lazy:
You could very easily use xmlParse() to load the transfer config,
loop over the results of xmlSearch(xml,//object) and add a new
attribute like xmlSearchResults[i].xmlAttributes.decorator =
my.path.to.my.Decorator. Then use fileSave(xml) to write the XML
Rock on. You're now all set up so that iIn the future, if you need
more from one particular decorator you just create a new decorator
with extends= pointing at your current decorator and change the XML
to match the path to the location of the new decorator.
Then add code to the new one!
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
As a side bar, I just wanted to acknowledge Jared for reminding me of
something I wanted to toy with.. A few months ago I had asked the list
for a way to get all of my configured transfer object class names and
Mark pointed me to the transfer.com.io.XMLFileReader.. I ended up
using the same
I am trying to create an IteratingTransferObject, or
AbastractIteratingObject, or IteratingBusinessObject (IBO) as
described by Mr. Peter Bell...
I need something to kill the OIP evil do-er with transfer objects from
large tables that _need_ the concrete, mixin, and abstract code to
perform
18 matches
Mail list logo
