Some notes on the task example
seancorfield
figured I'd provide some notes about it.
First off, the CFML side is intended to demonstrate and extremely
simple page-based application that calls into the Clojure model to
retrieve and update data in the task table. I planned to create a FW/1-
based contact manager (based on Javier Julio's userManager example in
FW/1) and I will probably still do this at some point because the
application I intend to use Clojure within will ultimately use FW/1.
However, it will take a back seat until I'm ready to start using
cfmljure with FW/1 which probably means not until FW/1 2.0 and DI/1
1.0 are available (later this year / early next year).
Second, the Clojure code is evolving rather organically so it's a bit
of a mess right now. The database connection details are in task/
db.clj and use Apache Derby. You'll see [org.apache.derby/derby
"10.6.1.0"] as a dependency in project.clj and task/create.clj has
functions to drop and create the entire database (all one table of
it). In task/core.clj, you'll see all the other code. It started out
simple - add-task, get-by-id and get-all - but then I ran into a bug
with clj-sql and Apache Derby which was hard to fix without pulling in
several methods from that project (and excluding them from the :use
clause in the (ns) declaration). The clj-sql library should get
updated soon with Apache Derby as part of its test cases and then I
can clean that part up. You can see the bug report and response here:
http://github.com/alienscience/clj-sql/issues#issue/1
I've started to pull apart the task-specific functions and the generic
CRUD functions but I haven't finished yet so it's in a state of flux.
I'm also currently relying on task.db being accessible implicitly via
(:use [task.db]) so the generic CRUD code can simply refer to db -
essentially a global variable. That has to be abstracted out - either
as an argument or via a (binding) and I haven't decided which yet.
Given that most applications I build have a single datasource, I'm
leaning toward the (binding) right now but, that said, I'm working
with Continuent's Tungsten and have already split my data access into
readonly datasources (which can be load balanced) and read/write
datasources (which always go through the master DB connection). My
current approach (in CFML) dynamically picks the datasource based on
whether the query is a select or not so that may play into my ultimate
decision.
I'm send out more updates once I've finished my refactoring and I
*may* post details on how to get the task example working (basically
update your container's class path to contain task/lib, task/lib/
*.jar, task/src - as well as wherever the clj/ folder ends up... but
that may well change (see my previous email about classpath issues).
Sean
Sean Corfield
> However, it will take a back seat until I'm ready to start using
> cfmljure with FW/1 which probably means not until FW/1 2.0 and DI/1
> 1.0 are available (later this year / early next year).
As it turns out I've started using Clojure with ColdSpring and ColdBox
(and a little with FW/1) so I have some CFML/Clojure code now - which
I can't share - which is driving development of cfmljure (see my
recent post on the classpathonly option).
> Second, the Clojure code is evolving rather organically so it's a bit
> of a mess right now.
The app I'm using Clojure in is pretty DB-heavy so I'm finding a good
pattern for keeping things layered and separated (hinted at in the
classpathonly post) and I'll come back and retrofit the task example
to match once I'm more comfortable that the code organization really
works (I'm finding, for example, that I really only need to install
one or two namespaces to expose a solid API and that all the rest of
the Clojure model code can be in lower-level namespaces that are
':use'd by the API code and not exposed to CFML).
Since I will need it for my current project, I'll probably build out
an environment control / settings module in Clojure to abstract dev /
test / staging / production settings and I should be able to make that
open source (probably as part of cfmljure since I suspect any serious
projects built with cfmljure will need something like that).
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
seancorfield
> it). In task/core.clj, you'll see all the other code. It started out
> simple - add-task, get-by-id and get-all - but then I ran into a bug
> with clj-sql and Apache Derby which was hard to fix without pulling in
> several methods from that project (and excluding them from the :use
> clause in the (ns) declaration). The clj-sql library should get
> updated soon with Apache Derby as part of its test cases and then I
> can clean that part up. You can see the bug report and response here:
committed it. I had to adjust the Clojure dependencies back to 1.2.0
but the task.core file is radically simplified so it gives a better
idea of what CRUD looks like in Clojure.
Sean