Nov 10 2005

Slow Blogging Ahead

Posted by Joe Rinehart at 8:01 AM
10 comments - Categories: Site News

I'm going to be light on posts for a while (maybe even until the end of December), as I'm going to be pretty busy with some other things going on in my life. Nothing bad happening, just time-consuming.

I *will* do another Arf! TV session sometime this week, though!

Comments

Sean Corfield

Sean Corfield wrote on 11/10/05 11:17 AM

Busy with something more important than blogging? How can that be? :)
SOSensible

SOSensible wrote on 11/10/05 11:33 AM

Hey... work for a living, don't live to work. Certainly it would be cool to have a completed product this Friday in RC status... but that update is a good encouragement. It's good to know the status even if the status is "holding". So again, thanks and looking foward to the effort as you get more time.

P.S.
Plug... the exception dictionary, are you going to make it so it returns the standard exception and the human readable version both? (or rather, either... heh)
Nando

Nando wrote on 11/11/05 11:31 AM

If you have a little time to explain more about how hasOne, hasMany, belongsTo, and belongsToMany should be used ... i haven't got my head wrapped around that yet. :)
Sean Corfield

Sean Corfield wrote on 11/11/05 11:42 AM

Nando, the belongsTo / hasMany stuff is pretty well explained in any of the Ruby on Rails tutorials - in terms of the concept. Does that help you?
Sam Clement

Sam Clement wrote on 11/11/05 12:35 PM

Enjoy the break... I'm loving using ARF by the way.
Nando

Nando wrote on 11/11/05 2:51 PM

Sean, i looked for some tutorials, and found a few scant references so far, but nothing very directly to the point yet. But i do see now that these concepts are present in Rails and in Hibernate ...

In any case, i get the general idea. I'm not sure i understand exactly how to implement them all when your relationships get a little complex though.
Sean Corfield

Sean Corfield wrote on 11/11/05 7:29 PM

Nando, yeah, that's kind of my point about Rails not scaling in terms of application complexity...
Nando

Nando wrote on 11/12/05 3:43 AM

Sean,

I'm wondering if we might look into developing a "best practice" or "suggested practice" for using ARF! I'm still not sure of myself when using OO terminology, probably never will be, but what i'm thinking is that the use of ARF should preferably be packaged within an interface of some sort, so that you can replace its usage at a particular point in an application with something that scales out better, either in terms of performance or complexity, And do that at any time down the line, without affecting anything else in the application. Am i communicating clearly? Does this make sense? And yes, this is probably very obvious for some people already.

We've got a prototype we've developed for a client, working just on the interaction design layer. The actual development, which we are not doing, is months behind schedule.

I could probably wire it all together using ARF in a matter of a week or two and get it live for the client, which might save his skin at this point. But i'd like to do it in such a way that once the application goes live, someone could come in and swap out the ARF stuff at a few critical junctures as needed, and perhaps implement Gateways using stored procedures there. Or as the application requirements change, ARF!'s Active Record object gets swapped out for a more complex Business object. Doing so would not affect the rest of the app.

In other words, using ARF!, we can be more in tune with the "Ready, Fire, Aim" approach that the fast paced businesses we are catering to most often need to employ to stay on top of their game. In this regard, i see ARF! as a huge asset to the CF community. The only thing is perhaps we'll need to learn to use it in a forward thinking way.
Sean Corfield

Sean Corfield wrote on 11/12/05 11:04 AM

I guess with Arf! it would be Aim, Ready, Fire! :)

An Arf! record is a bean to all intents and purposes. The only difference is the creation method (recordFactory.createRecord("typename") instead of objectFactory.getBean("alias") if you're using ChiliBeans / ColdSpring).

I would certainly consider creating a DAO layer (as usual) that implemented persistence internally with Arf! I'm not sure yet whether I would also want to add a bean layer that wrapped Arf! records.

As with most issues in OO design, "it depends" - I don't think there are any hard and fast rules.

Is that at all helpful?

As for speed of development, I just built a quick Model-Glue / ColdSpring / Arf! admin for a small website and using Arf! definitely sped things up. The most tedious part of writing the app was writing the forms - although the CF7 XML forms make it a lot less tedious (since I only have to write cfinput tags and not all of the table layout to make the form look 'nice').
Steven Ross

Steven Ross wrote on 11/14/05 10:30 AM

Joe, can you include in your video how you would do an insert on relator table?

In an app I'm building (trying to use Arf! now) I have a Contact, ContactProperty, and ContactPropertyValue table. This is designed so that a user can dynamically add properties to a contact (name, gender, phone) and their resulting values on the fly.

tables:
Contacts - ContactID, EmailAddress
ContactProperty - PropertyID, PropertyName
ContactPropertyValue - ContactID, PropertyID, ContactPropertyValue

Write your comment



(it will not be displayed)







Categories

Monthly Archives

Search Archives

Favorite Links