Closed (fixed)
Project:
sIFR
Version:
master
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
1 Mar 2007 at 13:01 UTC
Updated:
17 Sep 2007 at 15:43 UTC
Jump to comment: Most recent file
As proposed in this and this issue, and in conjunction with a new, ground-breaking text replacement technology developed at our agency, sIFR should turn into a generic text replacement API that supports different techniques.
To achieve that, we will outsource all sIFR specific code into a sIFR plugin. Each technique will get its own plugin and contributors will be able to create new techniques for this module. At first sight it seems that we will need to serialize each plugin rule in the database, so each plugin is able to support custom rule sets.
For each plugin we will need a new Component for the issue tracker. The module itself has to be renamed to Text replacement or the like (not sure yet; suggestions are welcome).
These are my first thoughts. Any other input is greatly appreciated.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | sifr_5.patch | 61.39 KB | sun |
| #4 | sifr_4.patch | 58.4 KB | sun |
| #3 | sifr_3.patch | 30.3 KB | sun |
Comments
Comment #1
alanburke commentedSounds Interesting..
Any update?
Alan
Comment #2
guardian commentedsubscribing
Comment #3
sunAttached patch introduces a plugin system for sIFR module. Since this is a complete API change in sIFR module, this could be released as sIFR module v2. However, previously created rules will work like before. You need to update your copy of sIFR to the latest development snapshot of DRUPAL-5 or HEAD to apply this patch. Or download the latest release.
Each plugin defines its internal name, human-readable title, homepage, file dependencies and font file mask in one array. That information is used to introduce a plugin to the text replacement api. The api tries to invoke plugin-specific implementations of functions at the appropriate places. Those implementations are always named like the invoking function, f.e.
sifr_render_rule_js()invokessifr_sifr_render_rule_js().Don't get obscured by the function names. I was not able to rename api functions, because I did not yet have an idea for a short and well module name. To clarify this point, if the module name was Text replacement, above example would be:
textreplacement_render_rule_js()invokessifr_textreplacement_render_rule_js(), but that name is obviously too long.Besides renaming module functions, it seems that it is required to implement different forms for rule definitions. F.e., proposed support for sIFR lite would need a field to enter a HTML tag instead of a CSS selector and might not support all tweaking possibilities like regular sIFR. We need to store rule definitions as serialized arrays in the database, as outlined in my first post.
The sIFR (v2) plugin should work as before. Tests and patch reviews are greatly appreciated.
Comment #4
sunNew patch implementing different rule properties for each plugin and a new operation to duplicate a rule. You need to run update.php after applying this patch to update the database table.
Comment #5
sunNew patch with additional PHPdoc in sifr.inc.
Comment #6
izaak commentedHm, I tried applying this to HEAD but there were a few pieces that wouldn't match against sifr.module. Is this my problem?
Comment #7
sunThanks for trying to review the patch!
Fortunately, you do not need to apply the patch anymore. sIFR has turned into Dynamic Rendering module. However, as already mentioned in the project description, be careful and do not yet use the new module on production sites. The module upgrade path is not yet completely ready, so if you like to, you may start from scratch with the new module.
Comment #8
(not verified) commented