Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
soo_txp_obj: OOP library for plugin development
soo_txp_obj
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.
Requires:
PHP 5
Details:
Learn more and download the thing here: soo_txp_obj
Version History
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).
- soo_txp_select::distinct() for
SELECT DISTINCTqueries - Bugfix: soo_txp_left_join now works with database table prefixes
1.1.b.1, released 9/12/2010
- New class, soo_txp_left_join for
SELECT ... LEFT JOINqueries - soo_txp_upsert new features:
- properties and methods for
VALUES()syntax - can be initialized with a soo_txp_rowset or soo_txp_row object
- properties and methods for
- soo_txp_rowset new features:
- can be initialized with a query result resource
- new function
subset()to create a new rowset object from an existing one
- New class, soo_nested_set for Celko nested sets (modified preorder tree)
- soo_html_form, new features and related classes:
- Constructor’s
attsargument can include anactionarray for adding query parameters to the form’sactionattribute - New classes:
- soo_html_label for labeling form controls
- soo_html_input for input elements
- soo_html_select for select elements (can be initialized with an array which will auto-create appropriate
optionelements) - soo_html_option (see above)
- soo_html_textarea for textarea elements
- Constructor’s
- soo_html_img bugfix for pre Txp 4.2 compatibility
- soo_html_table can now be initialized with an array of values or table cells; these will automatically be formatted into rows and cells appropriately
- New class, *soo_html_caption for table captions
- soo_html_ol and soo_html_ul can be initialized with nested arrays, automatically generating nested lists (see soo_nested_set for a possible source of the nested array)
1.0.b.8, released 7/9/2010
- Documentation updates (DoxyGen compatibility)
1.0.b.7, released 7/4/2010
- soo_html_img now adds thumbnail
heightandwidthattributes (Txp 4.2.0 or later)
1.0.b.6, released 7/1/2010
- New class: soo_util, for static utility methods
1.0.b.5, released 1/27/2010
- new method:
where_clause()in soo_txp_query, a catch-all for complex clauses - minor HTML formatting change to
tag()method in soo_html
1.0.b.4, released 10/3/2009
- soo_uri updated for correct behavior in Txp sub-dir installations
1.0.b.3, released 9/22/2009
- soo_uri now gets query params by parsing $_SERVER[‘QUERY_STRING’] instead of $_GET
1.0.b.2, released 9/16/2009
- New callback function for MLP Pack compatibility with soo_uri
- New classes:
- soo_txp_upsert for SQL insert/update statements
- soo_txp_delete for SQL delete statements
- soo_html_form for form elements
- soo_txp_rowset overrides parent::__get() method
1.0.b.1
- Major re-organization and re-write of most classes.
- The old Soo_Txp_Data family has been divided into separate classes for queries and data.
- There are no longer separate classes for each Txp table.
- All class names now lowercase (these aren’t case sensitive anyway).
- Generic setting is now in the form
obj->property()instead ofobj->set_property(). - Various renaming, code cleaning, etc.
1.0.a.6, released 6/2/2009
- Added Soo_Txp_Uri class, for URI query string manipulation
- Soo_Html_P and soo_html_th can now have contents set during instantiation. Note that this will break compatibility with some previous uses, e.g.
new Soo_Html_P($atts). - Added
$inargument towhere_in()method (Soo_Txp_Data) to allow “NOT IN” queries
1.0.a5, released 5/13/2009
- Corrected SQL syntax in
order_by_field()function ofSoo_Txp_Dataclass - Modified
tag()function ofSoo_Htmlclass to handle a PHP 5.2.0 bug
1.0.a4, released 5/1/2009
- Added
count()andfield()methods to the abstractSoo_Txp_Dataclass.
1.0.a3, released 2/19/2009
- Added “Expires” property to
Soo_Txp_Articleand “load_order” property toSoo_Txp_Plugin. These fields were added in Textpattern version 4.0.7.
h3. 1.0.a2, released 2/5/2009
- No significant functional changes, but added generic getters and setters (thanks to jm for the hint), making the file about 35% smaller.
h3. 1.0.a1, released 2/4/2009
- Initial public release
Last edited by jsoo (2011-01-07 19:54:34)
Code is topiary
Offline
#2 2009-02-04 23:36:07
- Logoleptic
- Plugin Author
- From: Kansas, USA
- Registered: 2004-02-29
- Posts: 482
Re: soo_txp_obj: OOP library for plugin development
Interesting idea. I look forward to watching this develop.
Offline
Re: soo_txp_obj: OOP library for plugin development
I’m not sure if an Object Oriented Approach is wise to plugin development.
Offline
Re: soo_txp_obj: OOP library for plugin development
Haven’t looked at it too closely, but wouldn’t PHP’s __get|set methods simplify most of the getters and setters?
Offline
Re: soo_txp_obj: OOP library for plugin development
jm wrote:
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.
TheEric wrote:
I’m not sure if an Object Oriented Approach is wise to plugin development.
Please share — I want to know.
Code is topiary
Offline
Re: soo_txp_obj: OOP library for plugin development
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!
Code is topiary
Offline
Re: soo_txp_obj: OOP library for plugin development
jsoo wrote:
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.
Offline
Re: soo_txp_obj: OOP library for plugin development
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.
Code is topiary
Offline
Re: soo_txp_obj: OOP library for plugin development
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)
Code is topiary
Offline
Re: soo_txp_obj: OOP library for plugin development
My above comment still holds.
Offline
Re: soo_txp_obj: OOP library for plugin development
In response to this issue, soo_uri in v1.0.b.3 no longer relies on $_GET.
Code is topiary
Offline
Re: soo_txp_obj: OOP library for plugin development
In response to this issue, soo_uri now plays better with Txp subdirectory installations.
Code is topiary
Offline
Re: soo_txp_obj: OOP library for plugin development
Hi jsoo,
I’m having an issue I hope I will be able to explain.
Short version: on one server (the production server), if soo_txp_obj is installed, I get a blank screen on Preferences tab. On a similar server (my local server), the thing works flawlessly.
Large version: I’m developing a site on my local server and I’m not installing the plugins directly on the database , but loading them from the plugin_cache_dir. This approach works, although from time to time, there are plugins that may raise an error because it seems that TXP loads them (from filesystem) in alphabetical order (differently to the way it loads them when installed on the database, that uses the Order column value).
When one of this error appears, the solution is to usually rename (using numbers, or whatever) the one that has to be loaded so it’s loaded at the very beginning.
This “issue” applies to soo_txp_obj + soo_multidoc. As a quick side note, it’s weird, because the error is triggered if the plugins keep their “original” name:
soo_multidoc_v1.0.b.2.php
soo_txp_obj_v1.0.b.4.php
But then, if I just rename “soo_txp_obj_v1.0.b.4.php” to “soo_txp_obj.php”, the error disappears, even if “soo_txp_obj.php” still comes after “soo_multidoc_v1.0.b.2.php” if sorted alphabetically.
Not sure why, but the same “workaround” also works with other plugins that work in tandem.
Anyway, this may or may not be related to the Preferences blank page.
Let’s go on: after renaming (on the filesystem) the plugin to “soo_txp_obj.php”, everything seems to work as expected on my local environment. The two plugins load from the filesystem, and no errors on the admin side.
But when I move this setup to the live server, I get the blank screen on Preferences.
Moving soo_txp_obj.php from the plugin cache dir fixes the issue (of course, I also have to remove soo_multidoc, precisely to avoid the error of Multidoc not finding txp_obj).
The only “workaround” I’ve found to this is installing soo_txp_obj on the database, and remove it from the filesystem. Not a big deal, I can live with that.
But I’m still very curious about why it works ok on my local server but I get the blank screen on the production server…
Thanks.
Offline
Re: soo_txp_obj: OOP library for plugin development
Juliàn, thanks for the very thorough description of the issues! As to the first, when you rename the plugin files, soo_multidoc won’t load soo_txp_obj when it calls it with require_plugin(). So this can be solved by putting soo_txp_obj first alphabetically, or by giving it the name that soo_multidoc expects, or by changing soo_multidoc’s require_plugin() statement to match the new filename.
The blank preferences screen I can’t even guess about just now, but I’ll give it some thought.
Edit: just a guess, but:
are you using (or have you ever installed) soo_plugin_pref (or its precursor)? I’m wondering if corrupted soo_multidoc preferences could be involved in the blank screen issue.
Last edited by jsoo (2009-10-24 01:17:36)
Code is topiary
Offline
Re: soo_txp_obj: OOP library for plugin development
Hi Jeff,
thanks for your reply.
jsoo wrote:
Juliàn, thanks for the very thorough description of the issues! As to the first, when you rename the plugin files, soo_multidoc won’t load soo_txp_obj when it calls it with
require_plugin(). So this can be solved by putting soo_txp_obj first alphabetically, or by giving it the name that soo_multidoc expects, or by changing soo_multidoc’srequire_plugin()statement to match the new filename.
Ah, thanks! That explains why a library-type plugin will work even if it comes alphabetically after the one that requires the library. Cool.
are you using (or have you ever installed) soo_plugin_pref (or its precursor)? I’m wondering if corrupted soo_multidoc preferences could be involved in the blank screen issue.
I’ve installed soo_plugin_pref before any other soo_ plugin, as you suggest at your site. But it’s working on local copy but not in remote (an exact copy of the local one, using the same database dump), unless I install soo_txp_obj directly to the database..
If you have any idea what could I test, please, let me know. Thanks.
Offline