Roland,
Thanks for the reply. I can certainly understand the complex comment as
part of the issue is there is work being done before the view is called
but I omitted that step to hopefully make it less complex. So much for
that idea. The Breeze conversation sounds interesting & if you are still
willing to discuss further please let me now off-line (either at
[EMAIL PROTECTED] or [EMAIL PROTECTED]) so we can set it
up. I've posted some quick replies on your 1st 2 points but we can
discuss more assuming you're still willing to have the Breeze discussion.
Roland Collins wrote:
For instance - why reassign an app-scoped variable to the request scope in
onRequestStart? Why not just refer to the app-scoped var in your
view/client code?
I do not want my views to make any use of application scoped variables.
My goal for the view is to have them program to a contract. Essentially
there is a definition (written via Fusedoc) of what variables a view can
get. So I never want a view to refer to application scope hence why the
app scope is var is assigned to a request scope var. By not directly
accessing the app scope in the view I can alter the data, say pull it
from session scope instead, before the view is called and since the view
doesn't refer to it directly it wouldn't need to change.
Honestly, the code that was posted is too complex and too deep in your
architecture to know how you're really using it. I also get the impression
(based on the code posted) that you're using CFCs more as a function library
than as a true OO system . . . which isn't necessarily bad, but it's hard to
tell based solely on the code posted.
In some ways it is more like a function library but I've tried to make
it more like a service/factory. Code asks the appFactory (really more
of an uber service/factory) for a something, an object or a specific
service or factory. An example would be for a caller to ask the
appFactory to for a User bean. The code calls a getObject method out in
the Factory (e.g. appFactory.getObject("User")) and it would return it.
Internally it asks all is smaller service/factory classes 'do you have
this object?' if so create it and give it to me. If that bean needs to
be saved to a db, the caller asks the appFactory for the service to
persist it and then it gives that service the bean for it to be saved.
Is this function like activity from the caller's perspective, yes but
the objects performing the functions store and do stuff so its not
simply a function call. Is it true OO? Well I thought so. If the
architecture is more like a function library than its due in part its my
"greenness" in OO and to the requirements of the application being built
(that's a whole other story).
Thanks again for the reply and let me know about the Breeze conversation.
-Jason
P.S. Hugo, thanks as well. I totally understand about the energy
comment. Hearing it's too much to review is certainly better than not
hearing anything at all.
--
Jason Daiger
URL: www.jdaiger.com
EML: [EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
