COAL:Appology and a Question of ColdSpring...
ryan...@gmail.com
I want to start out by sincerely appologizing for the lack of
development or action lately. I am truly sorry for this, and it is
something I hope to remedy soon.
With that said, here is an update on the current state of affairs.
As you know, the vision of COAL is really two fold. First, the idea
was to create a library full or components, reusable, lightweight and
extensable, to keep us as coldfusion developers from reinventing the
wheel (or even rewriting the wheel they had already reinvented!) every
time they needed to do something. It would also serve as a way to
standardize some of the code that we all do, but all do differently.
If someone was having trouble working with some of the components,
other developers using COAL would instantly be on the same page and
would be able to help. Documentation would be importaint and testing
as well. It would also be a good way for others to learn some of the
more advanced ideas behind object oriented programming and coldfusion.
Secondly, there was the framework itself. It was my goal for this to
become a great representation of the service factory pattern, and that
it would be able to be used for component organization inside of
applications, irregardless of the component libraries. It was my hope
that it would be a strong, lightweight framework that would allow us to
organize the COAL library efficiently (and maybe even move things
around as they matured) and have that completely seperated from they
way they were used in the applications themselves.
It was this second part that I have spent the majority of time on when
working with the framework so far. I put a lot of work into it, and it
worked quite well. But it always felt like there was something more
that could be, and should be done with it.
So, lately, I have been hearing a lot about ColdSpring. I admit, I
have not had a good chance to sit and get into it yet, but from the
things I have been hearing, it has a lot in common with the framework I
built for COAL. Basically, all COAL needs is a solid framework to
offer up the components in the library, from wherever they may be. But
some of the other features of ColdSpring sound enticing as well such as
AOP (although I haven't fully gotten my head around that one yet...).
So here is the question. Those of you that have worked with ColdSpring
and understand it, does it sound like it could replace the COAL
framework? That would free up development time to work on the actual
components for COAL themselves and to work on documentation and
commissioning (read bribing) other developers to author components for
the framework as well.
So those of you that are in the know, what do you think? Im sure there
are Pros and Cons, but from what I understand, ColdSpring is designed
to fix this problem.
Phillip Senn
Ryan Guill
thinking stage currently, and even if I do decide that development of
COAL should go this route with ColdSpring, the current implementation
of the COAL "framework" would still function and I would still support
it if necessary. This is something I forgot in my original message.
On 5/1/06, Phillip Senn <ps...@alexlee.com> wrote:
>
> I, I... got nothing.
>
>
> >
>
--
Ryan Guill
A Deep Blue
ryan...@gmail.com
www.ryanguill.com
(270) 217.2399
got google talk? Chat me at ryan...@gmail.com
The Coldfusion Open Application Library - COAL - http://coal.ryanguill.com
Use CF and SQL? Try qBrowser - http://www.ryanguill.com/docs/
www.ryanguill.com/
The Roman Empire: www.ryanguill.com/blog/
Sean Tierney
have you tried the other angle of coming at this question (asking it
on the ColdSpring listserv of anyone who's familiar w/ COAL)? I have
only peripheral understanding of both projects and from what I know of
ColdSpring it's an IOC container to take care of the plumbing
associated with calling cfcs- you plop a cfc into the coldspring
framework and it knows how to grab its settings from the container and
doesn't need explicit config from within the object. COAL seems to be
more like bundling common functionality for reuse across projects and
developers like you said. There may be overlap in terms of what
happens under the hood to make things happen but my impression is that
they solve two different problems for the developer.
just my mostly-uninformed take on things at this point
sean
--
Grid7.com - Build something. BIGGER.
Ryan Guill
You may be right, but I dont necessarily think its a bad thing (tm).
As long as coldspring will do what we need it to, bascially serve up
the objects when requested, from wherever they exist, then the other
things that coldspring does, such as dependancy injection, could be a
great thing to have with some of the components that could go into
COAL.
I haven't asked on the coldspring list yet, I just signed up yesterday
and I replied back to the list to subscribe but not sure if it worked
or not. I haven't gotten any emails from that list yet so im not
sure, but I do plan on asking the question there as well.
On 5/1/06, Sean Tierney <lega...@gmail.com> wrote:
>
> Ryan,
> have you tried the other angle of coming at this question (asking it
> on the ColdSpring listserv of anyone who's familiar w/ COAL)? I have
> only peripheral understanding of both projects and from what I know of
> ColdSpring it's an IOC container to take care of the plumbing
> associated with calling cfcs- you plop a cfc into the coldspring
> framework and it knows how to grab its settings from the container and
> doesn't need explicit config from within the object. COAL seems to be
> more like bundling common functionality for reuse across projects and
> developers like you said. There may be overlap in terms of what
> happens under the hood to make things happen but my impression is that
> they solve two different problems for the developer.
> just my mostly-uninformed take on things at this point
>
> sean
>