Custom field improvements and hiding admin elements

Bloke · 2009-03-12 16:18:26

wet wrote:

Same API on other tabs is yet to come, suggestions welcome.

I’m still wrapping my head round the pluggable_ui() function but it’s totally awesome that the mechanism to do this admin reshuffle is now in place. You are a God amongst men. I can see someone making a yyy_better_sections_tab plugin just round the corner :-)

I’ve yet to figure out how sed_sf can use the callback mechanism to alter the custom fields via some AJAX parked on the ‘section’ dropdown, but I’m sure with some deep thought it’s possible. Certainly ied_hide_in_admin becomes, like, a 10-line program to do the dirty work, with the bulk of it being the user interface. Hurrah!

On the suggestions front, is it possible to put pluggable_ui() to work in txplib_head/foot/html so that the output from pagetop() etc can be customised? Or is that a little too involved? I’m thinking from the smd_skin perspective it would mean that 90% of my hack could be dispensed with and we could offer a ‘clean’ mechanism for people to override the layout of the tabs and footer. Perhaps I could even put all the TXP files back where they were, so the only mod required would be the skin txp_pref (though I might then have to treat ‘default’ as a special case, which is probably no bad thing).

Just a thought.

Last edited by Bloke (2009-03-12 16:19:46)

thebombsite · 2009-03-12 23:26:53

On the suggestions front, is it possible to put pluggable_ui() to work in txplib_head/foot/html so that the output from pagetop() etc can be customised?

That would be really cool. I’ve been watching the latest developments with a certain amount of excitement.

redbot · 2009-03-13 00:05:30

Bloke wrote:

I’ve yet to figure out how sed_sf can use the callback mechanism to alter the custom fields via some AJAX parked on the ‘section’ dropdown, but I’m sure with some deep thought it’s possible.

Bloke,
excuse me for the silly question, surely I’m missing something as I just know some very basic php and even less js.
Is really sed_section_fields using ajax? And why, given you only need some jquery to perform this operation?
And, excuse me again, what you mean by ‘callback mechanism’? Are you referring to the classic

register_callback('my_plugin', 'article');

?

As far as I know sed_secion simply hides section fields already present in the page so it does not interact with the server after the page is rendered.
I’m not sure this makes sense, if not, sorry for meddling.

Last edited by redbot (2009-03-13 01:44:14)

Bloke · 2009-03-13 08:53:30

redbot wrote:

Is really sed_section_fields using ajax?

I thought it did, maybe I’m wrong.

And why, given you only need some jquery to perform this operation?

jQuery has AJAX support so yes a bit of jQuery is all that’s required if I’ve understood the function of the section fields plugin correctly (see later)

Are you referring to the classic register_callback(‘my_plugin’, ‘article’);

Yes. To register interest in rewriting the admin side you now register a callback on a ‘ui’ element. If you return anything from the given function then your output is rendered instead of the default output. It’s genius.

As far as I know sed_secion simply hides section fields already present in the page so it does not interact with the server after the page is rendered.

Ah, I thought (maybe wrongly) that, during writing an article, if you changed the section from the dropdown the available custom fields automatically changed on the fly. That’s why I couldn’t see how to register interest in the ‘ui’ callback to alter the list of CFs after the page is rendered. If that is the case then it might just need some more thought on my part. If not then you are right, a quick bit of jQuery is all that’s required.

Last edited by Bloke (2009-03-13 08:54:47)

wet · 2009-03-13 09:18:16

Bloke wrote:

Yes. To register interest in rewriting the admin side you now register a callback on a ‘ui’ element. If you return anything from the given function then your output is rendered instead

..or in addition. Extend your users’ profiles if you wish.

Last edited by wet (2009-03-13 09:18:42)

redbot · 2009-03-13 10:57:05

Thanks as always for the clear explanation, now I understand the pluggable_ui thing and its very cool!
Anyway, regarding the sed_section_fields question I meant that yes, it uses jquery but not the jquery ajax functions.
The “write” tab is simply displayed normally and then with jquery (without ajax) a css display:none is added. In other words if you look at the html source hidden custom_fields are still there, they’re just hidden.

Ah, I thought (maybe wrongly) that, during writing an article, if you changed the section from the dropdown the available custom fields automatically changed on the fly.

Once again, while you talk about ‘available custom fields’ I would say ‘visible custom fields’…

At the end I don’t think you’ll have time to waste with this (and rightly so) , but just in case, if you feel a little masochistic, have a look at this plugin I desperately made the same day wet fixed sed_section_fields. It lacks an interface and is configurable adding some values directly in the plugin code but just makes the same thing sed_section does (and even something more) in a few lines.

Bloke · 2009-03-13 12:11:41

redbot wrote:

Anyway, regarding the sed_section_fields question I meant that yes, it uses jquery but not the jquery ajax functions.

Which version are you using? When I change section in the Write tab (using wet’s fixed version) Firebug indicates that the plugin sends a real-time (ajax) request to the server which results in some of the custom fields either hiding or displaying. It might not be using jQuery to do that (haven’t looked at the code).

But anyway, I just thought about it and technically it doesn’t have to do that; it can function exactly as you suggest. Simply set up the various rules server-side as net-carver does now, then download the entire section->CF mapping on the Write tab to a javascript array. Then it’s a simple case of hooking an onchange to the section dropdown, looking up the currently selected section in the js array and applying display:none to the given custom fields. No ajax, just a line or two of jQuery, as you say.

The (minor) downside is that if you change the configuration on the server you’d have to refresh the Write tab for the changes to take effect but that’s a small price to pay for the simplicity.

In fact — my mind’s in freewheel right now — a good use of the pluggable UI could be to initially ‘rewrite’ the custom field area so that the custom fields appeared in a specific order. Sometimes a new requirement appears that results in having to add CF8 about six months after a project started. CF2-CF7 are used in many articles, and I wish I could place CF8 next to CF1 because it’s kind of related. Now we can do that kind of thing really easily — hooray!

Last edited by Bloke (2009-03-13 12:15:12)

redbot · 2009-03-13 13:28:33

Bloke wrote:

… When I change section in the Write tab (using wet’s fixed version) Firebug indicates that the plugin sends a real-time (ajax) request to the server which results in some of the custom fields either hiding or displaying. It might not be using jQuery to do that (haven’t looked at the code).

mmm… yes, probably you are right, I can’t check now, anyway I never understood why it should be sending request to the server as it is completely useless in this case, given that you can achieve the same result with simple server-side jquery.

Though I’m happy to hear about the new pluggable_ui I don’t think it will be so useful for adding a functionality similar to sed_section_fields. In fact this plugin has an unique peculiarity as it depends on a on_change event, related to a select element, which must operate after the actual html is rendered. So I don’t see the advantages of pluggable_ui (which operates server side) in this specific case.
Sure, now you’ll be able to use ajax to send a request everytime you change a section in the dropdown to make the fields disappear (and not simply hide) from the html but it’s worth it? It would be at the expenses of speed and probably the effect wouldn’t be so nice with slower connections.

Conversely, a plugin like ied_hide_in_admin could take great advantage from the new features as – in this case – the plugin can operate before the html page is rendered and you can get a ‘perfect’ html page witout the initial ‘flash’ in which you see the complete page.

…a good use of the pluggable UI could be to initially ‘rewrite’ the custom field area so that the custom fields appeared in a specific order…

Yes, that would be another good use of pluggable_ui, I already do this with an homemade plugin using jquery but, again, taking advantage of pluggable_ui the end result would be a lot faster and cleaner.

Last edited by redbot (2009-03-13 13:29:54)

Textpattern CMS

Textpattern CMS support forum

#13 2009-03-12 16:18:26

Re: Custom field improvements and hiding admin elements

#14 2009-03-12 23:26:53

Re: Custom field improvements and hiding admin elements

#15 2009-03-13 00:05:30

Re: Custom field improvements and hiding admin elements

#16 2009-03-13 08:53:30

Re: Custom field improvements and hiding admin elements

#17 2009-03-13 09:18:16

Re: Custom field improvements and hiding admin elements

#18 2009-03-13 10:57:05

Re: Custom field improvements and hiding admin elements

#19 2009-03-13 12:11:41

Re: Custom field improvements and hiding admin elements

#20 2009-03-13 13:28:33

Re: Custom field improvements and hiding admin elements

Board footer