Application Building

Report · Oct 07, 2009

Good afternoon all,

I've been building this application that will require different areas (modules).

1. Production data entry

2. Defective product data entry

3. Stored Procedures

4. Numerous queries

5. Application.cfc

6. 85 pages of 20 are production / 65 test pages

Lacking areas:

1. User logins are not completed

2. Session ID not set

3. CFID is not set

4. Admin area incomplete

Areas that could benefit the app:

1. cflogin / cfntauthenicate /cfldap

2. cfinvoke

3. Re-install CF8 in Multiserver mode

4. etc.

What I am looking to do is aggregate files to folders, queries to store procedures and functions to cfc. As my application grows, it needs to become more efficient. Anyone out there familar with this and able to shed some light?

Thanks,

DJ Khalif

Report · Oct 12, 2009

"We feel your pain," certainly. But, I'm afraid that this post is so vague that you really haven't given anything specific enough for us to actually latch-on to and comment about. Every application certainly reaches a point where it has to be "straightened up and cleaned up" just to keep it going for a few more decades.

Here are a few general suggestions:

Decide upon a standard "prologue and epilogue" for each page, and put that into a "header.cfm" and "footer.cfm" that you <cfinclude> on every page. In other words, every page needs to have a standardized structure for its beginning and its end, including not only the <html>, <head> and <body> tags, but perhaps also things like session-handling, expired-session traps, login-checking and so forth. If a few pages are "exceptions to the rule," those pages might <cfset> variables that will influence the header/footer.
Sometimes it is very helpful to use <cfinclude> also to provide "standardized parts" that are used in several places within the application. "DRY = Don't Repeat Yourself."
On the server side, put your application logic (including all database queries) into ".cfc" files, even if you only use them once. That way, you always know where they are. (You can, if you like, treat a CFC-file as a sort of ersatz "object.")
The decision of whether to use stored-procedures in a particular situation really depends on how large the data-set is and whether your database engine de jour processes stored-procedures efficiently. (Some are great; some are hideous.) Placing a query into a stored-procedure makes it known to the database-engine, which may prepare an execution-plan in advance for the queries that it contains. Stored procedures may be mandatory in cases where users are not to be given unrestricted (read-only) access to the underlying tables.
When you reach this point in the application's life-cycle, there is quite a bit of it "in production" and you can usually see clearly where the warts are. Carefully identify the problem areas and plan how you will address one issue at a time. The code will always seem "ugly" and you will always wish that you had done it some other way. Those aesthetics may not be action-items. Other things affect the business and these are the ones that are worthy of attention.

Report · Oct 12, 2009

TLC,

I appreciate your response. I plan to read it a 4th time. Also, I don't want to turn this into a vent session but, I believe I was repeating myself in code and query. Thanks again.

Sincerely,

DJ Khalif

Adobe Community

Application Building