Intended Audience and Goals #5
Comments
|
Huge plus one. :) |
|
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. |
|
I'm going to now - honestly I thought just the chapters.md was done. |
|
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. |
|
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":
|
|
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 |
|
"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... :) |
|
@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. |
|
Ryan, I think websockets would be appropriate if the idea is to show CF Speaking of - Adam - you do cover using components via HTTP, right? (For On Sun, Jan 18, 2015 at 10:38 AM, Ryan Guill notifications@github.com
Raymond Camden, Web Standards Evangelist Email : raymondcamden@gmail.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 |
|
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. |
|
When it comes to REST, my opinion is, it's cool, but it sometimes feels 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 If you are discussing what the syntax supports, I think you should cover On Sun, Jan 18, 2015 at 10:43 AM, Adam notifications@github.com wrote:
Raymond Camden, Web Standards Evangelist Email : raymondcamden@gmail.com |
|
@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 (just saw your latest comment appear) You must have observations about other areas of the technical side of CFML!? |
|
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. |
|
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. |
|
Adam, I do know REST - was just typing quickly (maybe too quickly). "If you have a CFC-based solution... uniformity and predictability is out I guess we will have to agree to disagree about how practical of an issue On Sun, Jan 18, 2015 at 10:52 AM, Adam notifications@github.com wrote:
Raymond Camden, Web Standards Evangelist Email : raymondcamden@gmail.com |
|
"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 On Sun, Jan 18, 2015 at 10:57 AM, Raymond Camden raymondcamden@gmail.com
Raymond Camden, Web Standards Evangelist Email : raymondcamden@gmail.com |
|
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) |
|
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. |
|
I'm with Ryan here. This is your project, Adam, and while I don't agree On Sun, Jan 18, 2015 at 12:01 PM, Ryan Guill notifications@github.com
Raymond Camden, Web Standards Evangelist Email : raymondcamden@gmail.com |
|
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. 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. Of course, we have to remember you are trying to cover a language in a book… and you cannot cover everything. 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 :) Gavin Pickin On Jan 18, 2015, at 10:32 AM, Raymond Camden notifications@github.com wrote:
|
|
@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. |
|
@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 |
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?
The text was updated successfully, but these errors were encountered: