Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
#1 2005-05-26 18:55:08
- Andrew
- Plugin Author
- Registered: 2004-02-23
- Posts: 730
Textpattern interface DOM hooks
Throught the course of developing the Workflow plugin, I became aware of an internal lack of DOM structure in the Textpattern interface that makes it hard to develop admin-side plugins. Truth be told, I was very lucky that the only ID’d element (afaik) in the entire textpattern interface is the right column <td id="articleside"> on the Content>Write tab because this was precisely where I had planned to place the plugin content. Without that ID, I would have had to resort to a very unstable DOM guessing game.
I’m not a very experience javascripter, so perhaps I’m mistaken, but it seems that developing a standard ID set for major interface structural elements would allow for much easier scripting of admin-side plugins that rely on DOM jiggery-pokery, such as glx_admin_image_resize or rss_admin_resize. Then you wouldn’t have to loop thru this many <p>’s or <td>’s in order to grab what you need, you could just rely on getElementById() (something that wouldn’t change between updates).
What say you, developers?
Last edited by Andrew (2005-05-26 18:55:22)
Offline
#2 2005-05-26 20:00:58
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Textpattern interface DOM hooks
Yes. Its been… interesting.
How could what gets id’ed be decided?
Offline
#3 2005-05-26 20:11:09
- Andrew
- Plugin Author
- Registered: 2004-02-23
- Posts: 730
Re: Textpattern interface DOM hooks
Well, it’d probably be up to us to draft & agree on some sort of naming convention. Then we could just pass that along as a patch/proposal to zem so that the primary devs wouldn’t have to waste their time thinking too much about it. Although their input on the matter would probably be very helpful; it’s likely that this may all become moot if zem is planning on dedicated page locations for plugin hooks.
Offline
#4 2005-05-26 20:26:56
- zem
- Developer Emeritus
- From: Melbourne, Australia
- Registered: 2004-04-08
- Posts: 2,579
Re: Textpattern interface DOM hooks
Patches good. Committees bad.
I’d rather see a solution that automagically adds id/class attributes (via changes to certain key functions in txplib_html, for example), than something that requires attributes to be specified explicitly. But I’m not sure whether that’s feasible given the current design of those functions.
Alex
Offline
#5 2005-05-26 20:44:36
- Andrew
- Plugin Author
- Registered: 2004-02-23
- Posts: 730
Re: Textpattern interface DOM hooks
Agreed that a group discussion on this would likely be a mess.
As far as hooks go, I know the way MT solves it is to allocate space on each (all?) page(s) for associated plugin interface elements. I’m not too fond of that system though because it forces interaction in one area, where for plugins like the image resize it would make for really poor usability.
I mean, in current state it’s entirely possible to create plugins that traverse the DOM & insert elements at will, it’s just not very easy or stable to base the stability of a plugin on the fact that the interface page layout to stays the same. And if a user is employing more than one plugin that interacts with that page’s admin interface, it is impossible to anticipate what the DOM structure would be. Also, it leads to developers having to provide multiple versions of plugins, based on what version/revision of Txp a user has.
Offline
Re: Textpattern interface DOM hooks
I am very pro this idea. What if different people took different pages of the “content” area (which is probably the most desired to be hacked), created patches for their page, made sure no ID’s are overlapping (though like “image_” and “category_” would probably be better), and then submitted them? There might need to be some changes made to txplib_html to allow for easier additions of ID’s, but if the load was split up, those working on a single page could use a new version of txplib_html and fix any problems that arise from the subtle additions.
Offline
Re: Textpattern interface DOM hooks
I agree that this is a much needed addition. Plugins are bound to start stomping on each other (if they haven’t already) and the scripting is quote messy without being able to use a getElementById.
Would it be possible to make some changes to txplib_html and txplib_forms to automagically add IDs to form fields and html elements? For form elements at least this could be based on the name of the element.
Offline
Re: Textpattern interface DOM hooks
Bump. Anyone made any moves on this front? (beyond r1293 obviously)
Offline
Pages: 1