Proposal: POG 3.0 object model

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)>

1. Manually edit the POG objects by hand
2. 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.
• faster
• 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
  cases.

  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!