New sections tab, multi-edit control block

wet · 2012-06-26 17:32:33

Gocom wrote:

There isn’t much else that can be done is there?

Nope.

Gocom · 2012-06-26 17:40:52

wet wrote:

Nope.

I can change the id prefixes so it doesn’t use the number 13 ;) Or I can slice it or use regular expression. Phil, any better selector names? (note that the IDs that link the nodes need to use unique prefix). Maybe #txp_multi-option-*?

Gocom · 2012-06-26 17:55:27

Anyways, if there is or will be some sort of PHP wrapper that spawns the option and its node with one function call, that can help at understanding the code. Well, from PHP perspective. But no matter what the code is, the markup needs to be somehow passed to the client.

Which ever that final method is, there will be added markup on the page. Either some strange JavaScript blocks with long blocks of HTML, or some more readable HTML which can be understood by designers and likes too (both via Ajax or directly on the page). Problems, problems.

philwareham · 2012-06-26 19:18:21

This all looks brilliant, can’t wait to test it.

Class names:

I’d like to use a class other than .highlight for these rows if we can, and .active is already over-used in the admin side. A better and more semantic class might be .selected – I’ve checked the system and that is not used anywhere at present.

The column within the table itself could probably be a class name of .multi-select (because that’s what it is), the div surrounding the edit options could just be .multi-edit and the inner divs as .multi-option – so not far off what you’ve already proposed.

Only thing I’m not so keen on are the inner <div>s as they are naturally a block type element – I’d have to put some inline-block rules on those to get them inline. How about <span> tags for those inner containers instead, as they are naturally inline elements?

Last edited by philwareham (2012-06-26 19:20:37)

philwareham · 2012-06-26 19:31:08

IDs:

#txp-multi-option-* would be fine I guess, might be rather long ID selectors though, but at least that definitely won’t clash with anything else. Maybe even drop the txp- prefix and it should still be safe to use – #multi-option-* is not used anywhere else within the system.

Gocom · 2012-06-26 19:50:50

philwareham wrote:

The column within the table itself could probably be a class name of .multi-select (because that’s what it is), the div surrounding the edit options could just be .multi-edit

Shouldn’t that be other way around for backwards compatibility reasons. Otherwise the script is targeting exactly the wrong elements it’s supposed on instances where older markup structure is present (i.e. plugin added content). But yeah, can change it target those selectors (well, .multi-edit, the otherone will just search for a checkbox with supplied name).

Only thing I’m not so keen on are the inner <div>s as they are naturally a block type element – I’d have to put some inline-block rules on those to get them inline. How about <span> tags for those inner containers instead, as they are naturally inline elements?

Well, the inner blocks can technically contain anything, e.g. several sets of controls and block elements. There can various uses for such multi-editor. Limiting the space to tiny single line, will not do any good and just limits possibilities. At least using divs prevents from generating invalid markup which is otherwise bound to happen (for example I have multi-editors in my plugins that use several paragraphs of controls). Although, the JavaScript thing I’ve been working on doesn’t really care much more than about the class. The element is irrelevant in its eyes.

Anyhow, I’ve changed the default active class to selected, and changed the button node finder to target .multi-edit container.

Wait, defaults? Yup. On the first hook to a particular form, you can set certain different values. Mainly meant for plugins which may use different markup (same can’t work for everything). E.g.

$('form').txpMultiEditForm({
	'checkbox' : 'input[name="selected[]"][type=checkbox]',
	'rows' : 'tbody td',
	'activeClass' : 'selected',
	'actions' : 'select[name=edit_method]'
});

Are the current main options and defaults.

Gocom · 2012-06-26 19:53:56

philwareham wrote:

#txp-multi-option-* would be fine I guess, might be rather long ID selectors though, but at least that definitely won’t clash with anything else. Maybe even drop the txp- prefix and it should still be safe to use – #multi-option-* is not used anywhere else within the system.

Heh, the txp- prefix was joke to the number 13 ;) Sweet seventeen… (and that sounded freshly creepy, eh).

Last edited by Gocom (2012-06-26 19:54:23)

philwareham · 2012-06-26 20:14:48

Ah OK, so this multi-edit thing can be used for many different tasks. Until I see it as a working example I’m having difficulty visualising it, leave the inner <div>s in place and once it’s in the codebase I can see how it all will render.

Hmmm, multi-select and multi-edit – I liked the semantics of the way I’d proposed and was feel quite smug about it but you’re right about the backwards compatibility with plugins, don’t want to break things any more than we have to. If they’re are round the other way is that safer? So table columns stays as .multi-edit and the controls div wrapper is .multi-select?

Gocom · 2012-06-26 20:24:07

philwareham wrote:

Ah OK, so this multi-edit thing can be used for many different tasks. Until I see it as a working example I’m having difficulty visualising it, leave the inner <div>s in place and once it’s in the codebase I can see how it all will render.

I’m not sure we will have such sort of working example, not at least about multiple controls. But plugins can benefit from it. Who is to say that all multi-options will only have a single select field or Yes/No radios.

As far as the inner divs go, there will be only a one present at time. Those divs will be gone, non-existant. The block and it’s inner markup is converted to a object and stored in safe place. When an option is select that markup is then added after the edit_method select field, wrapped in a div supplied with classes multi-option and multi-step (multi-step is used to remove it element from document, it’s just an internal selector).

Hmmm, multi-select and multi-edit – I liked the semantics of the way I’d proposed and was feel quite smug about it but you’re right about the backwards compatibility with plugins, don’t want to break things any more than we have to. If they’re are round the other way is that safer? So table columns stays as .multi-edit and the controls div wrapper is .multi-select?

Probably, since .multi-select wasn’t used previously. It’s a new selector, while .multi-edit was for the columns.

Last edited by Gocom (2012-06-26 20:25:13)

philwareham · 2012-06-26 20:38:47

Well, I’ve put a .selected class into Hive theme in readiness for this, I’ll do the same for other core themes soon.

Last edited by philwareham (2012-06-26 20:39:05)

Gocom · 2012-06-26 20:40:54

Since I didn’t come up better way of putting it out there for a feedback and so on, I threw the written multi-edit jQuery plugin to a git repository on GitHub; jquery.txpMultiEditForm.js. Temporarily of course, just for a feedback and so on. Plus I need a place to commit to.

Gocom · 2012-06-26 21:10:50

Phil, Robert, Stef, and all, if you want to see it in action, you can just throw the two files to your /textpattern directory. For example clone the repository somewhere and then symlink the two files. After done (symlinked, copied or outright cloned to the textpattern dir), just open up the html file.

Yeah, yeah. I could have just cloned the whole textpattern repository for a two static files, but meh. I’m price winning idiot.

Last edited by Gocom (2012-06-26 21:12:38)

Bloke · 2012-06-26 21:54:38

Gocom

Looooooooooooovely.

Feels so good to get rid of the select_buttons(). And I love the fact that it auto-submits if you choose ‘delete’. One less unnecessary click is always welcome.

For some reason in my version the Show details works backwards (checked = hide stuff) but it’s not part of the demo (is it?) so that’s probably just a quirk of being a potted HTML file.

Question: will it work on the Categories panel as it stands today and, if not, what markup do we need to change on the panel to enable this? If we can work up a patch to stuff this masterpiece into core in the next few days I can work on moving all the panels over to the new tfoot / multi-edit structure and then I’d love to use the power of the new multi-edit tool to add changeparent to the four category multi-edits. It’s the last missing piece of multi-edit goodness imo.

Also, does this render all the horrible $edit['blahblah'] multi-edit code in txplib_head redundant?

Hats off to you, sir. An awesome bit of work.

Last edited by Bloke (2012-06-26 21:56:07)

Gocom · 2012-06-26 22:41:43

Bloke wrote:

For some reason in my version the Show details works backwards (checked = hide stuff) but it’s not part of the demo (is it?) so that’s probably just a quirk of being a potted HTML file.

Yeah. The checkbox is checked in the HTML file.

Question: will it work on the Categories panel as it stands today and, if not, what markup do we need to change on the panel to enable this?

Each and every panel will need the new editing method options markup. As of the latest commit I’ve increased the scripts supports to paragraphs from just tables rows. Also I’ve added an option for changing the element that makes a row. So now it should probably work.

Also, does this render all the horrible $edit['blahblah'] multi-edit code in txplib_head redundant?

That’s essentially why the .multi-option things are there. Those should work as replacement to those. Each panel needs new markup tho.

Bloke · 2012-06-26 22:50:08

Gocom wrote:

I’ve added an option for changing the element that makes a row. So now it should probably work.

Sweet, thanks.

Each panel needs new markup tho.

I’m not averse to some graft in this area. As long as I’ve seen it working on one page I can replicate the functionality fairly quickly throughout the admin side. Should give me something to do as the country slides towards a post-Olympics financial abyss!

Textpattern CMS

Textpattern CMS support forum

#16 2012-06-26 17:32:33

Re: New sections tab, multi-edit control block

#17 2012-06-26 17:40:52

Re: New sections tab, multi-edit control block

#18 2012-06-26 17:55:27

Re: New sections tab, multi-edit control block

#19 2012-06-26 19:18:21

Re: New sections tab, multi-edit control block

#20 2012-06-26 19:31:08

Re: New sections tab, multi-edit control block

#21 2012-06-26 19:50:50

Re: New sections tab, multi-edit control block

#22 2012-06-26 19:53:56

Re: New sections tab, multi-edit control block

#23 2012-06-26 20:14:48

Re: New sections tab, multi-edit control block

#24 2012-06-26 20:24:07

Re: New sections tab, multi-edit control block

#25 2012-06-26 20:38:47

Re: New sections tab, multi-edit control block

#26 2012-06-26 20:40:54

Re: New sections tab, multi-edit control block

#27 2012-06-26 21:10:50

Re: New sections tab, multi-edit control block

#28 2012-06-26 21:54:38

Re: New sections tab, multi-edit control block

#29 2012-06-26 22:41:43

Re: New sections tab, multi-edit control block

#30 2012-06-26 22:50:08

Re: New sections tab, multi-edit control block

Board footer