Firstly figure out, on paper, exactly what you want to do. Otherwise, you'll just be coding your way around with no real goal. Plan on separating content from logic, it'll always assure cleaner, more maintainable code.
Usually the apps I write are DB-related, so to use that sort of application as an example, the first step would be nailing down, with fairly broad scope, what sort of data needs to be stored. This doesn't have to mean tracking down every possible facet of information that will ever be pertinent, just get a good idea. Part of the app design
may call for it to be extensible anyway, so you don't have to know everything ahead of time.
Once you have a good understanding of what data needs to be stored, design your database. Flow charts are your friend. :) Having a visualization of the structure of the DB will come in handy for subsequent steps.
Now it's time for an interface between your app and the database. I generally avoid putting direct DB calls in my app as much as possible, your feelings may vary. Now that Pear is around, I've been using that for my abstraction. There are other options, of course. I tend to write three functions for each logical grouping of database fields.
For example, if it were a web log, there may be some groups of fields such as Users, Entries, Categories, and Polls. For these, I would write getEntry, setEntry, deleteEntry, getUser, setUser, deleteUser, and so on. I may not find a need to use all these functions, but being able to assume they're there if I come to that point later on is handy.
Usually for me the next step is the administrative portion of the app. The screens involved in (using the web log example) logging in as a user, posting a new entry, and perhaps adding a poll. The admin interface tends to have three components to it: The navigation, the forms for input, and the code for validating/DB access. Since separating content from code is good, I tend to have these three components thoroughly separated.
The navigation can be done any number of ways, I tend to use button menu screens (You log in, get a Main Menu, click on 'Manage Users', get a User Menu, click on 'Add User', get an Add User form, etc.) For form input, I like to make my forms dual-purpose. That is, the same file can be used for adding a user as it can for editing. It's a simple process, and it's handy for keeping maintenance hassles low. These forms, of course, submit their data to the code that does validation and DB access.
So that's the admin side, more or less. Once that's all in place, the only thing left to do is the actual web pages that people will be using. I'm no designer, so I don't relish this part. Thankfully, I work with people who are designers, so often while I'm coding the admin side, they're doing up the templates for the site. Then integration is just a matter of plugging in snippits of PHP to extract a value here, interate through some DB fields there.. Pretty soon, it's all done. (Okay, so it usually doesn't seen like 'pretty soon' when it actually gets finished).
- 12 brukere syntes dette svaret var til hjelp
Relaterte artikler
Powered by WHMCompleteSolution
