- Using POG with Flex
- Optimizing your web application
- Regenerating large objects
- PHP4 or PHP5
- New and Improved
- Evolution of a cube
- POG Museum
- POG 3.0 alpha
- Initial Performance results Part 2
- Initial performance results
- Proposal: POG 3.0 object model
- Suggest a feature
- A new year, A new POG release
- Many-Many relations
- POG 2.5 Released
- POG 2.5 beta
- Automatic table alignment
- New version: 2.1.2 released
- RSS should work well now
- RSS feed glitches
- What's new in 2.1.0
- PHP Objects 2.1.0 (preview)
- PHP Object relations FAQ
- PHP Object Relations
- Searching base64 encoded text
- How to debug POG-generated objects
- POG UI Tips
- Featuring Of Interest links
- PHP CRUD
- POG 2.0.1: A better code generator
- A look at the POG SOAP API
- POG 2.0.0 released
- Coming soon: Generate parent-child objects
- Generated abstraction v/s dynamic abstraction
- Zend Framework preview
- Coming soon: Generate Objects through SOAP
- Easily save images and files to a database
- PHP, Paypal & POG
- Five advanced Code Generator tips
- PHP Pagination using generated objects
- PHP Code Generator benchmarks
- Representing database objects using an AJAX Tree interface
- Using SETUP in a production environment
- Description of the generated object package
- Introducing PHP Object Generator version 1.6
- Using AJAX and PHP Object Generator
- When to use Object->SaveNew()
- Generating PHP objects in 2006
- Happy Holidays
- A short video of the POG Setup process
- A sneak peek at POG 1.6
- POG Tip: Field limits
- Previous versions.
- Searching the blog and tutorials sections
- Generating code with "Other" SQL data types
- Five general POG tips
- POG source code locations
- Microsoft SQL 2005 Express Edition
- Impatiently awaiting PHP 5.1 and PDO
- Php Object Generator goes open source
- POG generates PDO compatible code
- Oracle to offer free database
- POG Google group
- Database Wrappers and POG
- The generator blog
- An explanation of the 'Escape' function.
- Mirror, mirror
- Using POG to solve real world problems
- A php object-relational database tool
- A simple and flexible Object Oriented approach to PHP
Back to the Code Generator
The POG Google group
The POG tutorials/code samples
The POG mirror site
There are some exciting changes in the works for the POG 3.0 object model. We know that our original manifesto has been (and still is) POG is a code generator, not a framework. However, to put the new model into context, we cannot avoid but talk about how we think POG objects will be used in the context of a web application and therefore, what follows may sound a litte bit frame-worky. So we apologize in advance about that.
We believe this is the simplest and most traditional way POG objects are used in a project.
<a project> - <generated pog objects> - <generated setup app> - <objects that extend pog objects (optional)>Developers who then wanted to customize the generated code could either:
- Manually edit the POG objects by hand
- Create objects that extend the generated objects and put their custom logic/rules in the extended objects.
Note: we personally have been using #2 up to this point.
The “edge” that this model has over other dynamic ORM frameworks is that since the code is generated, it is:
- clearer/more easily understood by the developer.
- doesn’t need pages of API documentation
- easier to use
- works better with IDEs that support code completion.
- more lightweight
- less coupled with other application code
- extensive changes can be done to one class without effecting everything – i.e. customizing a special class is a breeze, whereas in a framework, adjustments to the framework itself can prove catastrophic for special
The one main drawback was that it was less extensible than dynamic frameworks: if the developer manually modified the generated objects to include custom code, these changes would have to be tracked/updated whenever the objects were regenerated. If the user extended the objects with custom logic, the custom logic would be immune to code regeneration, but could not be used across different projects.
Being more extensible:
In order to achieve a greater level of extensibility and still keep the advantages mentioned above, POG 3.0 will have a slightly modified object model that will allow for POG plugins ...or should we say … Plogins?! . Aaanyways, this is how a project may look like under 3.0
<a project> - <generated pog objects> - <generated setup app> - <objects that extend pog objects (optional)> - <pog plugins (optional)>
Plugins will allow developers to have a larger set of available features from which they can pick and choose the ones needed on a project level and not have unnecessary things bundled to their project. The basic POG Essentials and POG Relations methods will be generated as usual, but additional functions such as those used for data transformation, reporting, data manipulation etc can be added/removed at will through plugins. This model thus provides extensibility while keeping things as light as possible.
In the new model:
1. All generated objects will inherit from a POG_Base object which will provide general abilities to all POG generated classes
2. What used to be in the database object will be moved to the POG_Base object (i.e all the db connection handling methods), which will simplify and minimize the code in each object
3. The POG_Base object will also contain common methods that can be used across objects and which can be used by POG Plugins
4. Plugins are objects that reside in a special plugin directory.
5. Plugins can inherit from the POG_Base object. (optional)
6. Plugins can be used across projects and shared among developers.
7. Plugins objects must have unique class names that are different from the built-in generated methods (e.g. Save, Delete etc)
8. Plugins must implement an Execute() function, but everything else is fair game.
To summarize, in addition to the performance enhancements and other cool suggestions by other POG developers, the main thing we wanted to take into incorporate in 3.0 is
- How to make POG more extensible
- How to encourage more developers to contribute
- How to make the overall POG functionality more useful. and finally
- Was there a model change needed to achieve the goals above. The answer to this question was obviously yes, and the bottom line is, we hope that this model makes POG more useful and appealing to developers.
As a last note, we’d like to thank all current POG “hardcore” developers who have been giving us great feedback in our forum, in particular, Andy Law, whose ideas kind-of inspired this new model for 3.0. Thanks Andy!
This is a weblog about the Php Object Generator (POG) project, OO PHP, databases and Php code generators in general.
Php Object Generator, (POG) is an open source PHP code generator which automatically generates clean & tested Object Oriented code for your PHP4/PHP5 application.
Subscribe to our RSS feed
Feedback, Feature Requests, Bugs to:
The POG Google group
Send us a Hello through email