You are not logged in.
An object-oriented library for developing Textpattern plugins. Mainly for making database calls, dealing with the ensuing data, and generating HTML output therefrom. Also has a URI class for query string manipulation.
Learn more and download the thing here: soo_txp_obj
1.1.0, released 2011-01-07
Minor update, mainly needed only for sites running Multidoc and using the latest version of the admin plugin (0.1.1).
1.1.b.1, released 9/12/2010
SELECT ... LEFT JOINqueries
subset()to create a new rowset object from an existing one
attsargument can include an
actionarray for adding query parameters to the form’s
1.0.b.8, released 7/9/2010
1.0.b.7, released 7/4/2010
widthattributes (Txp 4.2.0 or later)
1.0.b.6, released 7/1/2010
1.0.b.5, released 1/27/2010
where_clause()in soo_txp_query, a catch-all for complex clauses
tag()method in soo_html
1.0.b.4, released 10/3/2009
1.0.b.3, released 9/22/2009
1.0.b.2, released 9/16/2009
1.0.a.6, released 6/2/2009
where_in()method (Soo_Txp_Data) to allow “NOT IN” queries
1.0.a5, released 5/13/2009
Soo_Htmlclass to handle a PHP 5.2.0 bug
1.0.a4, released 5/1/2009
field()methods to the abstract
1.0.a3, released 2/19/2009
Soo_Txp_Articleand “load_order” property to
Soo_Txp_Plugin. These fields were added in Textpattern version 4.0.7.
h3. 1.0.a2, released 2/5/2009
h3. 1.0.a1, released 2/4/2009
Last edited by jsoo (2011-01-07 19:54:34)
Interesting idea. I look forward to watching this develop.
“Never attribute to malice that which can be adequately explained by stupidity.”
— Hanlon’s Razor
Haven’t looked at it too closely, but wouldn’t PHP’s
__get|setmethods simplify most of the getters and setters?
I didn’t know about those. Thanks. Certainly I’ll make use of
__get(). That is going to shorten some of those classes quite a bit. At this point I prefer having separate specific setters, if nothing else for the method chaining.
I’m not sure if an Object Oriented Approach is wise to plugin development.
Please share — I want to know.
Following jm’s hint, I replaced all the generic getters with a
__get() in the super-parent class. Then I made a
__call() to handle the generic setters, so I still get method chaining. The file’s now about 35% smaller, and extending the base class is much less tedious. Thanks jm!
Please share — I want to know.
This framework is redundant and doesn’t ease development. Everything needed for plugin development already exists within TXP. Adding an additional OOP layer on top of a procedural based app just doesn’t seem all that …efficient. I would be all for it if there were the slightest speed benefit, but there is none. While I think this is an interesting concept to consider, I don’t think any sort of OOP approach to plugin-programming is currently practical.
Thanks for the insight. Certainly there is no performance benefit. In my limited trials I have found it makes it easier for me to write plugins, but that may simply be a reflection of my limited skills.
There is now a soo_txp_obj github repo. At the moment there is an experimental branch taking a quite different approach to query and data classes. If I go this route, and I probably will, any plugins based on the current release will require some editing. I know there aren’t many if any other plugin devs using this, but wanted to give fair warning — now is the time to give input.
Last edited by jsoo (2009-09-22 21:02:27)