I don't think there is any way I could agree more with this post Cliff. Well
said. Often when new technologies come around we find ourselves thinking about
all the cool ways we can apply them, which is perfectly natural, and part of
the learning process, but unfortunately forget about simpler
YES, your core business objects should be aware of the limitations.
Aspects are not part of your business model, and don't care about
rules and such (or at least they shouldn't!).
So, if you want to intercept method calls to perform validation,
that's a perfectly acceptable use of AOP. The
, 2006 12:22 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Aspect or not?
YES, your core business objects should be aware of the limitations. Aspects
are not part of your business model, and don't care about rules and such (or
at least they shouldn't!).
So, if you want to intercept method calls
Interesting. I'd always though of AOP as primarily a tool for increasing
cohesion and DRY by pulling out cross cutting concerns.
Not sure where I suggested that it isn't. If you see *the initiation*
of validation/business-rule enforcement as a cross-cutting concern in
your application, then AOP
] On Behalf
Of Dave Ross
Sent: Wednesday, July 05, 2006 4:59 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Aspect or not?
Interesting. I'd always though of AOP as primarily a tool for
increasing cohesion and DRY by pulling out cross cutting concerns.
Not sure where I suggested that it isn't
That makes perfectly good sense, I think. What should be happening is (assuming I went the aspect route here) the aspect
doesn't do the work, a core business object does
the work and the aspect just knows about that object. The aspect passes information
to the core business object, that object
exactly!
On 7/5/06, Adam Haskell [EMAIL PROTECTED] wrote:
That makes perfectly good sense, I think. What should be happening is
(assuming I went the aspect route here) the aspect doesn't do the work, a
core business object does the work and the aspect just knows about that
object. The aspect
guru's out there, are there any other approaches we should
be considering?
Best
Wishes,Peter
-Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Adam HaskellSent: Wednesday, July 05, 2006 5:43
PMTo: CFCDev@cfczone.orgSubject: Re: [CFCDev] Aspect
On 7/5/06, Peter Bell [EMAIL PROTECTED] wrote:
I KNEW there was something bothering me about this solution and I couldn't
figure out what it was. I just figured it out. This is not a cross cutting
concern!!!
ok. Except no code has really been posted, no detailed specs dicussed.
What I'm trying
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dave Ross
Sent: Wednesday, July 05, 2006 9:53 PM
To: CFCDev@cfczone.org
Subject: Re: [CFCDev] Aspect or not?
On 7/5/06, Peter Bell [EMAIL PROTECTED] wrote:
I KNEW there was something bothering me about this solution and I
couldn't figure
I also think it's important to think about where and how AOP is
commonly applied to understand what sorts of uses are appropriate.
Most commonly you see containers like Spring/ColdSpring managing
stateless infrastructure components like DAOs or Services using the
Singleton pattern. It is less
Title: Message
Hi
Adam,
I
would add this to the core business model. For me, aspects are cross cutting
concerns that decrease cohesion (a product shouldn't know about logging,
security or workflow, so those are the classic examples of AOP). To me it is
perfectly appropriate that a
This application sits outside of the POS terminal so this does not work with payments or anything of the sort. It is strictly PSE purchase tracking and reporting. Thankfully the business owners decided how to ID people; by State ID, drivers license, or Passport number.
Stores are not limited to
Original Message-From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Adam HaskellSent: Tuesday, July 04, 2006 2:24 PMTo:
CFCDev@cfczone.orgSubject: Re: [CFCDev] Aspect or
not?This application sits outside of the POS terminal so
this does not work with payments or
I've worked on some very large-scale, complex web applications, and I've never had
a case where this
sort of pseudo-record-locking approach was needed.
Dave, this is mearly a request for clarification (not a flame or anything), since this
whole issue was brought up on a fellow team members'
I've worked on some very large-scale, complex web applications, and I've never had
a case where this
sort of pseudo-record-locking approach was needed.
Dave, this is mearly a request for clarification (not a flame or anything), since this
whole issue was brought up on a fellow team members'
would it be safe to say that the methods mentioned (re-read
before write, timestamps, hashing, etc) always worked well
for you so nothing else was seriously considered? you were
able to build this into the system from day one, the bloody
thing worked perfectly and that was the end of the
Why would you want to?
because to integrate the functionality we want to bolt on to the existing system would
mean (pretty much) a complete rewrite of the whole thing, whereas adding an additionl
aspect would be much easier and cleaner.
(I'm not convinced that AOP is the big deal some
What version of CF are all these sites now running on?
John Farrar
--
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by
NOT ACCEPTABLE: timestamp/last-saved-by/hashing-the-record ( +
comparisons)
- 100+ tables in schema, all needing the additional fields to the 150+
sites
- still doesn't prevent editing (ie: only notification after the event)
PROPOSED: mimic row locking by code using a row lock table to record
On Mon, 09 Aug 2004 23:34:22 -0500, Barry L Beattie [EMAIL PROTECTED] wrote:
we're now placed into a position that AOP-like crosscutting could come to the rescue
for us.
is there *any* way that we can attach aspects to CF (mostly for tracking and
logging)?
Why would you want to? (I'm not
21 matches
Mail list logo
