Five general POG tips

1. More Planning
Since POG will generate your database access layer in less than a day’s work, consider spending more time designing other aspects of your project.

If you’re building a website:

• spend more time on the content, layout and design of the pages themselves. Don’t worry about the code for now. When you’re done designing the web forms, POG will generate the code for you. For example, we have a tutorial that shows how to generate PHP code to create a registration system that you can use as an example.

If you’re building a web application:

• is the work flow of your application complete?
• what framework/design pattern will you use? MVC? Factory? Take the time to plan your entire project more thoroughly, because now, you can afford to!

In other words, feel free to ‘forget’ about how you’re going to store/retrieve/update things to/from your database for now. Let us take care of that for you

2. Incremental Programming
Once you have a pretty good idea on what type of objects to generate, go ahead and do it. Don’t wait for everything to be finalized. There’s a balance to strike between being thorough in the design/analysis part of your project and choosing when to start implementation. Let’s face it, requirements will inevitably evolve at some point, your objects will have to change, but you can’t wait for everything to be set in stone before you start coding. We’ve got you covered though. Whenever you need to make a change to your object, simply use the @link tag found in the header of every object generated by POG. After all, getting a prototype up and running fast is what POG is all about.

3. Naming Conventions
POG lets you name your object and attributes any way you want. However, for best results, we suggest you generate all your objects using the same naming conventions. For example, for our own projects, we follow these naming guidelines for POG:

• Capitalize the first letter of the object name.
• Use camel casing for your attributes. You don’t have to use these exact naming conventions, but if you do, you’ll achieve consistency between your different objects. This will make your code cleaner and easier to maintain.

4. Smaller Objects Equals Faster Code
Keep your objects relatively small. Having smaller objects equals faster code. For example, if you’re designing a registration system where users can upload a picture of themselves, the easiest way to do this is to create a User object with a picture attribute. There’s nothing wrong with that, and it works fine. However, if you want faster code, you should split your object into a User and an Image object. In this case, you would have an image id attribute that links the user object to the image object. This way, whenever you’re trying to get a list of user names from the User table in the database, you’re not retrieving large amounts of data unnecessarily.

The rule of thumb is: Whenever you’re storing multimedia files as such as video, pictures and music, do not store them as attributes of another object. Instead, store them as objects themselves.

5. Ask For Help
Finally, in case you have a question for which you can’t find an answer to in the POG Blog or POG tutorials, feel free to post it at the POG Google group. You’ll usually get an answer within 24 hours.