Ike... you rock
Gerald Guido
using Data Faucet at work and it rocks the hizzous.
s. isaac dealey
> using Data Faucet at work and it rocks the hizzous.
Thank you Gerald. I'll have to put this in a testimonials section
somewhere. :)
What are you getting the most use out of if you don't mind my asking?
ActiveRecord? And/or search in Gateway objects? Building your own
queries with the sql library? Or something entirely different?
Oh and where are you working btw? Is it a company we would recognize?
--
[ ike ] founder - onTap framework
phone: 781.769.0723
Gerald Guido
I saw you made mention of Gert/Railo on one of your posts. Which got me thinking. I read your article on CFDJ and I know that you use Adobe's runtime to tease out the DB metatdata. Now that I am gearing toward developing CF runtime agnostic apps, one of the things on my wish list is a runtime agnostic ORM.
I was wondering what your thoughts on that were.
~G~
"If everything seems under control, you're not going fast enough"
-- Mario Andretti
Isaac Dealey
> digging into it really. But so far I haven't had to write a lick of
> SQL on my last project.
Cool, thanks... Speaking of which, there's actually a datafaucet google
group also. :)
> I saw you made mention of Gert/Railo on one of your posts. Which got me
> thinking. I read your article on CFDJ and I know that you use Adobe's
> runtime to tease out the DB metatdata. Now that I am gearing toward
> developing CF runtime agnostic apps, one of the things on my wish list is a
> runtime agnostic ORM.
>
> I was wondering what your thoughts on that were.
I have the same thoughts about a CFML agnostic ORM as I do about a CFML
agnostic onTap framework. Would be great. :) I've never been able to get
the onTap framework to run on BlueDragon and I suspect that having
either or both be CFML agnostic would require a fair amount of
contribution from folks who do more work with those engines, and may
even require branching the code. I'm all for it, just don't think I can
do it by myself.
Matt Woodward
> I've never been able to get
> the onTap framework to run on BlueDragon and I suspect that having
> either or both be CFML agnostic would require a fair amount of
> contribution from folks who do more work with those engines, and may
> even require branching the code. I'm all for it, just don't think I can
> do it by myself.
comparison, Mach-II, Fusebox, and Model-Glue all run on OpenBD with no
changes. IMO it would be worth looking into how to genericize the
Adobe CF specific parts of onTap as opposed to branching and
maintaining multiple versions.
It's still early days for the open CFML engines but IMO you'd be wise
to make onTap run on them.
Brian Meloche
I'd say getting onTap running on OpenBD and Railo should be a priority.
Sincerely,
Brian Meloche
brianmeloche at gmail dot com
Producer and Host, CFConversations Podcast
http://www.cfconversations.com
Blog: http://www.brianmeloche.com/blog/
Adobe Community Expert:
http://www.adobe.com/communities/experts/members/BrianMeloche.html
Twitter: http://twitter.com/coofuushun
Pownce: http://pownce.com/bmeloche
User Group Manager,
Cleveland ColdFusion Users Group,
http://www.clevelandcfug.org
Isaac Dealey
> comparison, Mach-II, Fusebox, and Model-Glue all run on OpenBD with no
> changes. IMO it would be worth looking into how to genericize the
> Adobe CF specific parts of onTap as opposed to branching and
> maintaining multiple versions.
>
> It's still early days for the open CFML engines but IMO you'd be wise
> to make onTap run on them.
That actually would be my preference.
I'm just not entirely convinced it's possible...
With previous versions (and I'm talking about from a few years ago), the
list-function variations in BD were one of the things that prevented me
from making it run on that engine at the time... There were just too
many instances of the use of a list function in the core framework...
and while that may not be the case now, this latest version allows
webservices to be homed in any directory under the root, yet depends on
an onRequest method... It turns out the way that works to achieve that
fails on BD because where Adobe's CF engine handles .cfc files as "CFML"
files and is fairly agnostic to what gets put into them, the BD engine
requires that they contain the cfcomponent tags directly.
I think I need more input from folks who have more experience with BD
and Railo really... and of course who have more time to analyze the code
and contribute suggestions.
I know you're pretty swamped and so not likely to have the time to
contribute much. Although I do really appreciate your contributing in an
"advisory" capacity. :)
Matt Woodward
> once OpenBD comes out
> of beta
as the commercial J2EE edition of BlueDragon, so I don't think people
should think of it as "beta." We're adding and tweaking features and
will have an official 7.1 release soon, but from the standpoint of the
core engine there's nothing beta about it. :-)
Matt Woodward
> the
> list-function variations in BD were one of the things that prevented me
> from making it run on that engine at the time
manipulation functionality of some sort. That being said, we're always
interested in hearing about behavioral differences between Adobe CF
and OpenBD even if they're edge cases. Do you know specifically what
you were doing with lists that wasn't working?
> where Adobe's CF engine handles .cfc files as "CFML"
> files and is fairly agnostic to what gets put into them, the BD engine
> requires that they contain the cfcomponent tags directly.
there's a bit of non-standard code in the mix that may just happen to
work on Adobe CF even though it "shouldn't" (if that makes sense). How
are you using .cfc files that aren't really components? Any examples I
could take a peek at?
> I know you're pretty swamped and so not likely to have the time to
> contribute much. Although I do really appreciate your contributing in an
> "advisory" capacity. :)
download would be representative of onTap in general. Any one in
particular I should try running?
Brian Meloche
Matt Woodward
> Sorry to commandeer the thread on OpenBD, but I'll correct the correction:
> Understood on the core engine, but it's beta as long as you don't have an
> official release out. We can't touch it at my company until there's an
> official release.
official numbered release out soon, but the release that's available
now is not beta. To reiterate, it's the same as the commercial J2EE
edition of BlueDragon. The word "beta" doesn't appear on the download
page, so my point is that you're calling/considering it a beta, we
aren't. The initial release was an official release, we're just still
ironing out the version numbering. Beta has a completely different
meaning and isn't applicable in this case. Granted this is a bit of a
unique case since it was a commercial product (with a final non-beta
version number) that was open sourced. None of this may change your
situation, but for all intents and purposes the initial release was a
"7.0 final" release (since the next release will be 7.1).
Not picking on you, just saying that the fact that we're currently
lacking an official version number designation doesn't make the
product itself beta. All this being said I appreciate the feedback
that version numbering is important to people, and it's something
we'll rectify soon. I just get a bit irked when people run around
saying OpenBD is a "beta" when it's far from it.
Matt Woodward
response to Brian came off as harsh. The sentiment is what I wanted to
get across, but my wording could have been much more diplomatic, so my
apologies to Brian and others.
I'll grab a sample app, drop it on OpenBD version null ;-), and see
how it works. I probably won't have any time at the moment to do much
more than say "it blew up here" and give some ideas as to why, but if
that will be helpful I'll give things a shot.
Isaac Dealey
> manipulation functionality of some sort. That being said, we're always
> interested in hearing about behavioral differences between Adobe CF
> and OpenBD even if they're edge cases. Do you know specifically what
> you were doing with lists that wasn't working?
Yeah, it's been a few years and I just never got around to installing
any of the more recent versions of BD to try it after that. I would bet
the list issue is well resolved at this point. I did have someone else
tell me they got a previous version of it working on BD, so at this
point it may only be the onRequest issue that's the problem... and
mostly I think I would want to know what other folks opinions are on how
to address that issue, I can think of a couple different approaches that
could be taken, but none that are without side-effects. If I knew of a
side-effect free method, I'd have already implemented it. :) So I think
I'd prefer to know which side effects people consider to be the most
important to address.
> Guess I'd have to hear more about this as well. Again it sounds like
> there's a bit of non-standard code in the mix that may just happen to
> work on Adobe CF even though it "shouldn't" (if that makes sense). How
> are you using .cfc files that aren't really components? Any examples I
> could take a peek at?
Here's the enclosure I added to the blog that shows a simplified copy of
it http://ontap.riaforge.org/blog/enclosures/test1%2Ezip
And here's the blog entry
http://ontap.riaforge.org/blog/index.cfm/2008/5/27/trick
> I'm happy to at least take a look--I'm assuming the sample apps I can
> download would be representative of onTap in general. Any one in
> particular I should try running?
Well don't get too far ahead of yourself. :P See about the core
framework first... if you can install the latest core distro, which
includes the plugin manager, then you can just go into the plugin
manager (/admin/plugins/) and under the more tab hit "search" and click
"install" on the DataFaucet plugin and then after DataFaucet is
installed you can install Members onTap the same way. I've not done
anything with TapMCE in a while and am thinking about moving to NiceEdit
for my own projects... But DataFaucet and Members onTap are the only two
plugins really being worked on currently. I'm hoping to put up a small
scaffolding tool shortly though. DF and the framework already to most of
the work, so I should be able to bang it out in a few hours.
Isaac Dealey
> Understood on the core engine, but it's beta as long as you don't have an
> official release out. We can't touch it at my company until there's an
> official release. Our infrastructure team won't let us install it. I wanted
> to put it on VMWare, but... no go until there's a release, or at least a
> release candidate.
Actually that's useful info for the framework community also. Does that
also apply to things like the onTap framework or frameworks in general
or does it only apply to the server?
I'm pretty close to considering this latest release of onTap +
DataFaucet as "release candidates". I've been using them both for a long
time and they're finally supporting the webservice for installing
plugins that I'd always wanted. And I feel they're stable in spite of
the fact that there may still be questions surrounding support of
various non-standard server configurations, different or newer database
servers, etc.
They work for me, "rock solid" on SQL Server with standard so it seems
to me like whatever remains really is just cleaning up things like I
discovered that the aggressive whitespace management on HostMySite's
server was causing the documentation samples for DataFaucet to be all
out of whack (stripping whitespace from pre tags) and had to use
cfprocessingdirective to resolve that issue.
Thanks Brian,