In my Bean CFCs I have the standard methods: getSomeProperty(),
setSomeProperty(), getInstance(), setInstance(), and validate(). What I am
toying with is how much data/meta data should/could I store about the
properties within the bean and how much (if any) might be better suited for
properties
I have a neta data driven application generator which I am currently porting
from CF5 to CFMX7, so I'm considering similar issues. I think you need to
consider two things: performance and DRY (don't repeat yourself).
Is the meta data going to be anywhere else? You only want to store and given
Kurt, I would really appreciate that. I've just read a little about, and
looked at demos of Arf!, and saw comments that it's less
industrial-strength than Reactor, and haven't had time to look into
Reactor. I've been involved in a Mach-II app that has no persistence
management, and would be
Being a FB developer I'm toying with the idea of playing around with
Model-glue and thought that I'd quickly look up on the web a typically
versus scenario but I found nothing. I was wondering if someone could
quickly tap out a few lines as to the pros and cons.
Thanks
--
Nick Tong
Managing
I haven't used FB since version 2 or 3, which was so long ago I don't think color had been invented yet, but my understanding of current-day FB is that it is a procedural framework and Model-Glue and Mach-II are object-oriented frameworks. They all implement the MVC pattern but FB does it with
All -
I'm building a list of frameworks to study up on and (gasp) maybe build a
features matrix, but primarily get familiar so I know how to identify when
to use which framework.
Thus far I have:
FuseBox
ColdSpring
MachII
Model-Glue
Tartan
Am I missing any majors that people know of?
On 1/30/06, Nick Tong - TalkWebSolutions.co.uk [EMAIL PROTECTED] wrote:
Being a FB developer I'm toying with the idea of playing around with
Model-glue and thought that I'd quickly look up on the web a typically
versus scenario but I found nothing. I was wondering if someone could
quickly tap
Seth - thanks very much for you quick responce.
I do think that the CF community is moving towards the darkside (
sorry OO ) so i think it's time to move over and get involved.
Thanks again.
On 30/01/06, Seth Petry-Johnson [EMAIL PROTECTED] wrote:
I haven't used FB since version 2 or 3, which
Brent,
Brian Rinaldi did a great job by assembling a list of ColdFusion open
source projects:
http://www.remotesynthesis.com/blog/index.cfm/2005/11/1/ColdFusion-OpenS
ource-Project-List
There your find other frameworks like: Underscore, ColdFusion On Wheels,
ARF!, Reactor, ObjectBreeze,
On 1/30/06, Brent Nicholas [EMAIL PROTECTED] wrote:
All -
I'm building a list of frameworks to study up on and (gasp) maybe build a
features matrix, but primarily get familiar so I know how to identify when
to use which framework.
Thus far I have:
FuseBox
ColdSpring
MachII
Model-Glue
Nick,
As Barney points out, the Fusebox framework itself is procedural,
but it should also be pointed out that Fusebox supports OO model
development (both indirectly and directly using ad hoc XML verbs) as
well as procedural. Should you be uncomfortable with, or else have
reservations about
Speaking from experience going from FB3 to FB4 is a much easier
transition than from FB3 to MG. One pro I found w/ FB4.1 vs MG at this
time is the ability to place all circuits, including controller, model
(CFC's) view, in a shared area. This allows me to share the same
circuits between
Hey Jason,
This allows me to share the same
circuits between applications. We have a core set of functionality that
does not change in 95% of our jobs.
I'm actively addressing this in the Model-Glue 2.0 core. Would you be
interested in testing?
Thanks,
Joe
--
Get Glued!
The Model-Glue
forgive me for butting in but I just want to add a quick 2c
1) metadata percolating up to the client/view:
we had metadata in some areas that changed per request (to drive the
UI/javascript/page logic). the only way to do it (integrated with the
data) was to use XML (with
14 matches
Mail list logo
