Intended Audience and Goals

[ryanguill]

Maybe some context about your intended audience and goals for the book would better inform us about what kind of feedback you are looking for. I'm sure we all have differing opinions about what should go in a book like this, but it is your book and vision you're after.

For example, are you targeting new programmers? Programmers experienced in other languages but new to CFML? Existing but perhaps novice CFML programmers?

When done reading this book, what do you want someone to be able to do? Read existing (potentially legacy) CFML code? Write proficient and modern CFML? Do you want organizations to use this book as part of the training of new devs? The majority of the training?

[cfjedimaster]

Huge plus one. :)

[adamcameron]

You've read the 0th chapter, right? Because that does kinda cover a bunch of this. Not all of it, but given you're asking about the "bunch of this" side of things, I wonder whether that's a good place to start. If that needs enhancing... yeah, fair enough.

That 0th chapter is not at all a fait accompli either. So there's scope to elucidate where the content is lacking or vague, too.

Oh, and that's not to say I think I have addressed everything you mention above, or have even thought about it... I'll get there. Currently I want to get some momentum going with the technical writing, and "other stuff" can be back-filled once I've worked out WTF.

[cfjedimaster]

I'm going to now - honestly I thought just the chapters.md was done.

[cfjedimaster]

Is this a fair assessment: The idea is to learn syntax (ie, how CF shit is written), how to do it w/ best practices, and don't worry about shit like, "How do I resize an image", since you will have learned by the end how to structure a MVC web app and you know how to check the reference to see the particular function.

[ryanguill]

I had skimmed it but just read it now. A few thoughts:

Is the "in 24 hours" thing not trademarked by Sams Publishing? Do you intend to publish with them?

If this is an "introduction to the language and concepts w/ best practices":

• I def don't think that websocket belongs
• ORM should be much later in the book
• Custom tags should be much later in the book

[adamcameron]

Exactly that.

(you're making me think about this now).

Perhaps its aim is to be a guide as to how start doing CFML properly from the outset (the definition of "properly" is "according to how I say, damn you!"), and cover the stuff that's not immediately obvious from the docs, blogs, other training material - which tends towards "what" not "how". Other stuff can be gleaned from the docs.

This is why I intend to focus on ORM first (@ryanguill mentioned it) and queryExecute() later. To start with, ORM is a more appropriate approach to getting objects from the DB. Doing it "by hand" is an advanced topic. I will caveat all this with Sean's "ORM is the Viet Nam of..." warning.

[ryanguill]

"This is why I intend to focus on ORM first (@ryanguill mentioned it) and queryExecute() later. To start with, ORM is a more appropriate approach to getting objects from the DB"

Um, you probably aren't interested in my opinions then... :)

[adamcameron]

@ryanguill your commet came in whilst I was replying to @cfjedimaster.

Yeah, I'm not convinced WebSockets belong either.

Disagree re ORM (as per comment above). SQL has no place in a CFML application if it can be avoided. That said, HQL has even less place ;-)

I'd put custom tags before built-in tags if I could!

Not sure re the trademark. I'm not sure how they could trademark a time frame, but I'll look into it. "24h to CFML" or something, perhaps. Shrug. This is not at all important @ this point.

[cfjedimaster]

Ryan, I think websockets would be appropriate if the idea is to show CF working as a good back end server to a cient-side app.

Speaking of - Adam - you do cover using components via HTTP, right? (For Ajax/Rest I mean, not web services/SOAP.)

On Sun, Jan 18, 2015 at 10:38 AM, Ryan Guill notifications@github.com wrote:

"This is why I intend to focus on ORM first (@ryanguill https://github.com/ryanguill mentioned it) and queryExecute() later. To start with, ORM is a more appropriate approach to getting objects from the DB"

Um, you probably aren't interested in my opinions then... :)

— Reply to this email directly or view it on GitHub https://github.com/daccfml/cfml24h/issues/5#issuecomment-70414989.

Raymond Camden, Web Standards Evangelist

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

[adamcameron]

@cfjedimaster it had not occurred to me re components over HTTP. Let's ignore SOAP completely, but does accessing CFCs remotely have a benefit over a RESTful approach? I think the industry is more behind /rest/sort/of/access/points than /cfmlspecific.cfc?method=ones

[ryanguill]

So we can agree to disagree here re: ORM and websockets. In this light, I will bow out of content discussions and focus on just proofreading and technical editing.

[cfjedimaster]

When it comes to REST, my opinion is, it's cool, but it sometimes feels like its being anal just to be anal.

If you have a service that makes beer and tell me I can do this

your.com/beer/make

or

your.com/beer.cfc?method=makebeer

I honestly wouldn't care. The first one IS cleaner but I'm going to type that URL one time in my JS code and not think of it again.

If you are discussing what the syntax supports, I think you should cover hitting CFCs via HTTP as it is a core part of the language imo. Heck, you want to be sure that folks know - at minimum - that using access=remote 'exposes' shit to the world.

On Sun, Jan 18, 2015 at 10:43 AM, Adam notifications@github.com wrote:

@cfjedimaster https://github.com/cfjedimaster it had not occurred to me re components over HTTP. Let's ignore SOAP completely, but does accessing CFCs remotely have a benefit over a RESTful approach? I think the industry is more behind /rest/sort/of/access/points than /cfmlspecific.cfc?method=ones

— Reply to this email directly or view it on GitHub https://github.com/daccfml/cfml24h/issues/5#issuecomment-70415193.

Raymond Camden, Web Standards Evangelist

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

[adamcameron]

@ryanguill I'm always interested in your opinions. Well: at least the ones that are right ;-) (joking)

IMO most SQL you sound like you write in the CFML app ought to be written in the DB as views, and then ORM should query those. Writing SQL directly in CFML is like writing inline JS in a CFM file. The best I'd go is to use <cfstoredproc>. CFML is not a DB querying tool, and should not be used as one.

(just saw your latest comment appear) You must have observations about other areas of the technical side of CFML!?

[adamcameron]

I should release a transcript of this as a blog article!

@cfjedimaster re REST: you'd not be calling "makebeer". You'd be POSTing to the /beer/ end point. POST = create, after all. If you wanted to get a beer, then GET /beer/1, etc (and what format comes back is determined by what MIME type you ask for, etc). REST is about API uniformity and predictability of the communication more than anything else. It also means the underlying system is completely irrelevant to the consumer.

If you have a CFC-based solution... uniformity and predictability is out the window, as is system agnosticism.

You're right though, the "REMOTE" side of things does need to be discussed.

[ryanguill]

I don't think any argument between us re ORM and SQL will be productive for this project, so honestly I will refrain. I've got nothing but love for the both of you, but its obvious we have some pretty differing opinions.

"You must have observations about other areas of the technical side of CFML!?" - Im not certain what you mean by this, but im just saying I will only focus on proofreading and mentioning if anything that you write is correct / complete, not worrying about what you choose to write about.

[cfjedimaster]

Adam, I do know REST - was just typing quickly (maybe too quickly).

"If you have a CFC-based solution... uniformity and predictability is out the window, as is system agnosticism."

I guess we will have to agree to disagree about how practical of an issue that is in the real world. To be clear, I'm definitely not anti-REST, I just don't think the benefits everyone brings up are actually that much of a big deal in the real world. I speak from having worked with loads of APIs (for some reason I tend to like working with APIs the most) so perhaps my experience is just that - my experience.

On Sun, Jan 18, 2015 at 10:52 AM, Adam notifications@github.com wrote:

I should release a transcript of this as a blog article!

@cfjedimaster https://github.com/cfjedimaster re REST: you'd not be calling "makebeer". You'd be POSTing to the /beer/ end point. POST = create, after all. If you wanted to get a beer, then GET /beer/1, etc (and what format comes back is determined by what MIME type you ask for, etc). REST is about API uniformity and predictability of the communication more than anything else. It also means the underlying system is completely irrelevant to the consumer.

If you have a CFC-based solution... uniformity and predictability is out the window, as is system agnosticism.

You're right though, the "REMOTE" side of things does need to be discussed.

— Reply to this email directly or view it on GitHub https://github.com/daccfml/cfml24h/issues/5#issuecomment-70415567.

Raymond Camden, Web Standards Evangelist

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

[cfjedimaster]

"but its obvious we have some pretty differing opinions" - all three of us ;)

Like Ryan - I'm going to try to not harp on stuff I don't agree with as it won't help. :)

On Sun, Jan 18, 2015 at 10:57 AM, Raymond Camden raymondcamden@gmail.com wrote:

Adam, I do know REST - was just typing quickly (maybe too quickly).

"If you have a CFC-based solution... uniformity and predictability is out the window, as is system agnosticism."

I guess we will have to agree to disagree about how practical of an issue that is in the real world. To be clear, I'm definitely not anti-REST, I just don't think the benefits everyone brings up are actually that much of a big deal in the real world. I speak from having worked with loads of APIs (for some reason I tend to like working with APIs the most) so perhaps my experience is just that - my experience.

On Sun, Jan 18, 2015 at 10:52 AM, Adam notifications@github.com wrote:

I should release a transcript of this as a blog article!

@cfjedimaster https://github.com/cfjedimaster re REST: you'd not be calling "makebeer". You'd be POSTing to the /beer/ end point. POST = create, after all. If you wanted to get a beer, then GET /beer/1, etc (and what format comes back is determined by what MIME type you ask for, etc). REST is about API uniformity and predictability of the communication more than anything else. It also means the underlying system is completely irrelevant to the consumer.

If you have a CFC-based solution... uniformity and predictability is out the window, as is system agnosticism.

You're right though, the "REMOTE" side of things does need to be discussed.

— Reply to this email directly or view it on GitHub https://github.com/daccfml/cfml24h/issues/5#issuecomment-70415567.

Raymond Camden, Web Standards Evangelist

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

Raymond Camden, Web Standards Evangelist

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

[adamcameron]

Well it'd help if one makes a case, rather than simple saying "I disagree with that", to which all a sensible person can really say is "OK. Duly noted".

My opinion on ORM - for example - changes monthly. But the change is due to someone stating their case. Not simply telling me they disagree.

I have never not changed (our at least strongly reconsidered) my position on something when presented with a good case. On the other hand: I've never changed it simply due to someone claiming they disagree. I don't give a shit about people not agreeing with me.

(Speaking generally here... your example of ORM is just a good example, Ryan)

[ryanguill]

If you want to have a conversation about my opinions on ORM sometime I'd be happy to have it, but my point is that I am not trying to change your mind about it. I mostly just don't feel this is an appropriate forum for the argument and I don't intend to try to change your mind about something you feel you have enough of an opinion on and experience with to write a book about.

[cfjedimaster]

I'm with Ryan here. This is your project, Adam, and while I don't agree with some of what you are saying, I think both Ryan and I feel it is better if we just help technically. (Hope I didn't put words in your mouth there Ryan.)

On Sun, Jan 18, 2015 at 12:01 PM, Ryan Guill notifications@github.com wrote:

If you want to have a conversation about my opinions on ORM sometime I'd be happy to have it, but my point is that I am not trying to change your mind about it. I mostly just don't feel this is an appropriate forum for the argument and I don't intend to try to change your mind about something you feel you have enough of an opinion on and experience with to write a book about.

— Reply to this email directly or view it on GitHub https://github.com/daccfml/cfml24h/issues/5#issuecomment-70418221.

Raymond Camden, Web Standards Evangelist

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden

[gpickin]

While you guys butt out, I’ll butt in with my 2 cents :)

The ORM and SQL stuff is an interesting point.

I know you have DBAs Adam, working in large teams, so you rarely have to deal with it, but in small teams, ORM and/or SQL is key to an app… and they would be touching it, all the time, even for the simplest of apps. Not everyone works with Stored Procs, Views, and even then, you have to interface.

Although you don’t need to focus on all of it, I think if you didn’t have DAOs with some SQL, it would leave a large hole in most apps. You might cover it in the MVC of course… but I think it is important.

Of course, we have to remember you are trying to cover a language in a book… and you cannot cover everything. It could be a start of a bigger series of content, with each part of the MVC being broken up… DAO could be its own book, with SQL / ORM and how to arrange your DAO and calling from your services.

My point of view comes from a small team, where I largely control of influence what we do and how we do it, although it is slow to be adopted by everyone, but we have been reaching for best practices, and how we separate the concerns, structure our DAO etc has been a big part of it.

Anyways, just my input on the conversation :) PS: I enjoy seeing the smart people talk :)

Gavin Pickin

On Jan 18, 2015, at 10:32 AM, Raymond Camden notifications@github.com wrote:

I'm with Ryan here. This is your project, Adam, and while I don't agree with some of what you are saying, I think both Ryan and I feel it is better if we just help technically. (Hope I didn't put words in your mouth there Ryan.)

On Sun, Jan 18, 2015 at 12:01 PM, Ryan Guill notifications@github.com wrote:

If you want to have a conversation about my opinions on ORM sometime I'd be happy to have it, but my point is that I am not trying to change your mind about it. I mostly just don't feel this is an appropriate forum for the argument and I don't intend to try to change your mind about something you feel you have enough of an opinion on and experience with to write a book about.

— Reply to this email directly or view it on GitHub https://github.com/daccfml/cfml24h/issues/5#issuecomment-70418221.

Raymond Camden, Web Standards Evangelist

Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden — Reply to this email directly or view it on GitHub.

[adamcameron]

@ryanguill / @cfjedimaster beyond a point, I just saw this thread as a conversation; it'd moved on from the specific "issue" at hand. Don't worry about "off topic" stuff.

@gpickin: I'll get back to you on this... I'm within office hours now so need to crack on with some... PHP.

[adamcameron]

@gpickin sure. I'm not saying "don't write SQL", I'm saying "write it in the correct place". and in a CFML file is not the correct place. Any SELECT sort of thing can be created as a view in the DB and then have an entity mapped to it. This makes more sense from an application perspective anyhow.

If there's a situation in which there'd be a proc returning multiple recordsets? possibly something hierarchical within entities. Or perhaps not. Situation specific.

Updates and deletes can be done via ORM.

Large scale reporting where using ORM to manipulate the data is not feasible? Almost certainly should not be being done by CFML at all. Just the results of the report processing ought to be exposed via a CFML app... again via a report line entity mapped over a view (possibly a materialised view, depends, obviously).

Bear in mind this book isn't "how to mess up your CFML app by riddling it with inline SQL", it's how to use CFML. The default approach for general DB interaction can easily be done via ORM and sensibly homed SQL. There's also a chapter on when one "needs" to interact with a DB via the more old-school mechanisms. I'm just burying that later on as it ought to be the exception, rather than the rule. But even then it'll be along the lines of "stick this shit in a DAO and hide it away from the rest of the app".

Bottom line: IMO it's a misuse of CFML to be doing data manipulation. It's for data presentation.

Closing this as it's now just a conversation not an "issue", I think