> -----Original Message----- > From: Tom MacKean [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 15 December 2004 9:50 AM > To: CFAussie Mailing List > Subject: [cfaussie] Best practice? > > Hi all, > > I'm starting to doubt myself. After doing the basic FastTrack > to CF course I raced off and started building a new web site. > Although I eventually got all my apps working well enough, > I've read so much lately that I'm thinking about scrapping > everything over Christmas and starting again. Before I do, I > wanted to get opinions from you guys about the best ways to > do things... > > Before I start, please bear in mind that I have no prior > programming experience before starting CF and have only be > doing CF on and off for about a year, so if my questions seem > basic then I apologise... > > 1) Dreamweaver templates - Yes or No
No - Reason, its better to learn the old skool approach vs letting an IDE dictate how you bring it all together. > > I'm working in Dreamweaver. I see lots of people talking > about HomeSite and others (Eclipse?) but I'm comfortable in > DW. When I started I automatically assumed that templates > were the way to go. Then I discovered cfinclude and thought > that breaking my page into bits, then including those bits > was a better way. A page might then look like... > <cfinclude url="beforethehead.cfm"> > <head> > <cfinclude url="metas_and_stylesheets.cfm"> <title> > <description> </head> <body> <cfinclude url="navigation and > stuff.cfm"> <...all the page code that changes...> <cfinclude > url="footer.cfm"> </body> </html> CFINCLUDE can be a tag that's easily abused. Don't always include a file for the sake of it, factor in as to why your including files? Not saying too many of them are bad, hell if it solves problems use it? But just don't abuse the use. Also the example you've given, where you have "beforeTheHead.cfm" and then another "metas_and_stylesheets.cfm" etc, now the question can be asked? As to what gains are you getting by fragmenting your code into files? In that could you safely use a "header.cfm" and use that instead. I'm only illustrating this as a case point for potential hazards with CFINCLUDE.. "Am I overlapping here? Hmm..could I wrap this into one CFINCLUDE Container and so on". On that, keep in mind you also have CFIMPORT which has its uses as well (have a read on that one, it can be dawnting at first but is a boon to CFMX at times). > > Then I look at Peter's CFUG site and see that every page says > fuseaction=blahblah. Looks like you have one page and call > content as needed depending on the value of the fusebox > variable. Yeah? This might work well for my site as most > pages will look identical just with different content. Is > this a common way to work? Yeah, peters using fusebox which is basically a framework setup to accommodate most overlap situations. Theres kind of two flavours in that regard, FuseBox4 (which I think is more suited to your needs - based on the current info) or Mach-II. Mach-II is my personal favourite as its more tailored to an OO approach (if its possible). Having said that FB4 in itself is not exactly a cutdown version as it appears. Get to know the framework if you want to do this, as it will not only save you some time in what I call "pioneering" but it will be a good start to learn from, in that get a perspective on how others write code and make use of various "patterns" in their code. Most importantly though it will open your mindset into code-reuse. > > 2) Application variables > > Before I dicovered application variables, I had queries on each page. > Then I started putting queries into the Application.cfm file > and doing QoQ on them. Is this a good thing? When is it too > much? I know that Application.cfm "loads" on every page. If > your Application.cfm is 20K does that mean each page is 20K > bigger and slower to load? How does this work? Application.cfm is basically hit per page request, in that it's like a "pre-Process" event which will be executed once you begin a pages request process. Its typically not recommended to overload your application scope with variables unless you forsee a reason to do so. In your example, you stated that there are queries that you stored in there. Now what payoffs will you gain by storing say 50 queries in application scope vs per page request (ie are these queries used on every single page? Or 3/22 pages? Etc). Furthermore, if these queries hold mountains of information (1000+ rows per query) it can get a bit of an overkill. Then you throw in QoQ into the equation and things could start stacking up. So in this case, I'd realistically ask "what are my gains" and to a quick load test and see what the overall differences are. Typically if your have a system that has a high load of Query traffic, you'd start looking at concepts like Stored Procedures (why let coldfusion take on the burden of a DB load.. Put that back onto the DB server where it typically is in its own element) that or "pooling" data blocks like this.. Ie (do you need all 50 queries in memory at any given time? Or can you keep max 10? (ie userX request query11, so query1 gets removed, query11 gets added). If you have a 20k application.cfm it will be condesed at compile time. I at this point cannot say for certain, but I'm pretty sure that the application.cfm is basically converted to a java based class of some kind which will cut away a lot of the fat - basically its condesed to binary as opposed to a open ASCII file. Also in a application scope scenario, if you have single instances of "stuff" you want to keep for the life of the application, make sure you implement some kind of "IF already Exists ignore, else create" procedure. > > 3) Security > > What are some specific things I can do to protect myself from > hackers? Minimize your arguments via FORM/URL scope for starters. eg Use CFQUEYRPARAM tag when updating databases as this will also prevent "hackers" from doing a UPDATE TABLE XYZ SET FIELD = '1 GO DELETE FROM TABLE XYZ' which was an old trick. Just be mindful that anything you expose to a browser, can be adjusted so always rely on server-side validation and never just client-side - UI validation is nothing more then a Usability filter.. Ie if ask for a number, don't let me enter a string etc.. But always check that logic server-side. Another hot tip I guess, is if you make use of CFC's; utilise either the "roles" or at least limit what you want to expose as "public/remote". I think there is heaps of ways to lock down an application and its more instance based (ie whats your app) > > ----- > If you can think of any other advice, I'm all ears. Pretty much just read. Blogs are useful (www.fullasagoog.com) for information. Scope forums out as much as possible, and never assume you know something, always keep an open mind about it and even if you "DO" know it, still stop and listen as the worst enemy for a coder is ignorance and ego. Ask questions all the time, even if they are dumb - I do it (more so lateley), if people call you a dumbass for it, so be it but atleast you're being proactive in your programming. --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
