Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: New sections tab, multi-edit control block
philwareham wrote:
Is a class placed on the table row if it is in selected state? If so let me know the class name and I’ll make sure the core themes have support for it. And yes, the multi-edit checkboxes were moved for usability reasons.
Yes. I’ve currently named it as .highlight. Any better suggestions? .active perhaps?
Anyways, the .multi-edit block hosting the select field, currently a paragraph, needs to be changed a div. Even now (with the current code) it produces invalid HTML when we take JS DOM work into account. Even the current (old) script inserts block elements inside that paragraph.
The main (footer’s) .multi-edit block would kinda require a unique class selector so that one can target the submit button in there w/ targeting each and every (i.e. 3rd-party plugin panel) button. Currently it shares the selector with the columns, which may or may not host buttons (plugins, eh). Do you (Phil, Stef, Robert) have any suggestions of naming? Is the current markup and naming ok? E.g. .multi-action, .multi-option?
<div class="multi-edit multi-action">
<select name="edit_method">
<option value="" selected="selected">With selected...</option>
<option value="changepage">Uses page</option>
<option value="changecss">Uses style</option>
<option value="changeonfrontpage">On front page</option>
<option value="changesyndicate">Syndicate</option>
<option value="changesearchable">Include in site search</option>
<option value="delete">Delete</option>
</select>
<div class="multi-option" id="multi-option-changepage">
<select name="page">
<option value=""></option>
<option value="default">default</option>
<option value="error_404">error_404</option>
</select>
</div>
<div class="multi-option" id="multi-option-changecss">
<select name="css">
<option value=""></option>
<option value="bootstrap">bootstrap</option>
<option value="default">default</option>
<option value="formalize">formalize</option>
<option value="styles.min">styles.min</option>
</select>
</div>
<div class="multi-option" id="multi-option-changeonfrontpage">
<input type="radio" id="on_front_page_0" name="on_front_page" value="0" class="radio" />
<label for="on_front_page_0">No</label>
<input type="radio" id="on_front_page_1" name="on_front_page" value="1" class="radio active" checked="checked" />
<label for="on_front_page_1">Yes</label>
</div>
<div class="multi-option" id="multi-option-changesyndicate">
<input type="radio" id="syndicate_0" name="syndicate" value="0" class="radio" />
<label for="syndicate_0">No</label>
<input type="radio" id="syndicate_1" name="syndicate" value="1" class="radio active" checked="checked" />
<label for="syndicate_1">Yes</label>
</div>
<div class="multi-option" id="multi-option-changesearchable">
<input type="radio" id="searchable_0" name="searchable" value="0" class="radio" />
<label for="searchable_0">No</label>
<input type="radio" id="searchable_1" name="searchable" value="1" class="radio active" checked="checked" />
<label for="searchable_1">Yes</label>
</div>
<input type="submit" value="Go" />
</div>For instance, should the Go button have it’s own container? Anyways, the .multi-option elements are removed with JS. They are HTML nodes used for generating objects which are then attacked to the multi-editor’s options. I.e.
$this.find('.multi-option').each(function() {
methods.addOption({
'label' : '',
'html' : $(this),
'value' : $(this).attr('id').substring(13)
});
}).remove();Where addOption method pretty much just does (well, in essence at least);
option.data('options', settings.html)Today I’ve been playing with multiple instance support, wrote a instance cacher (which is required since the thing does what it does) and opened all internal methods for plugin/core use.
Currently useable methods (in public scope) are select and addOption. Since the code is instance/jQuery driven and relies to events, there is certain need for methods. E.g. selecting, so that plugins can add buttons that select random articles for deleting, and what have we. Select method in it’s current format works like this:
$('form').txpMultiEditForm('select', {
'index' : [1, 2, 3, 4...] // selects by row index (i.e. row number)
'range' : [min, max], // from index to index
'value' : [value1, value2, value3, ...] // selects rows by value
'checked' : true // boolean, un/check
});Selecting all rows from a plugin is as easy as:
$('form').txpMultiEditForm('select', {'checked' : true});The selector (I.e. $('form')) can be a form which will be turned into one with multi-edit functionality or a any child element inside the form. The selector is normalized so the target doesn’t really matter. All methods are enclosed in the same jQuery plugin method/scope (it sounds the best idea (pretty much required really), plus that’s what jQuery’s developer guidelines direct/order us to do).
Of course a manual interaction w/o methods is possible too, but as multi-edit thing does use events, it would involve manually firing said events:
$('checkbox').prop('checked', true).change();When the JavaScript is done, then comes probably time to valuate it and then somehow someone should do a PHP wrappers for it. And potentially make up a really good Textpattern callback event name for the .multi-edits and stuff. Does everything sound okay?
Last edited by Gocom (2012-06-26 16:29:34)
Offline
Re: New sections tab, multi-edit control block
Sounds great. Phil may chime in on markup and class names.
If we could get rid of this magic number 13 …
substring(13)…or find another way to link the option template to its owning edit_method it would reduce headwear for the next guy who reads this code. Alas, rel is not a valid attribute for div.
Offline
Re: New sections tab, multi-edit control block
wet wrote:
…or find another way to link the option template to its owning
edit_methodit would reduce headwear for the next guy who reads this code. Alas,relis not a valid attribute fordiv.
There isn’t much else that can be done is there? Unless writing JavaScript and mixing it with PHP is your suggestion. Which is even worst if you ask me. Open to any suggestions how to link the nodes without involving any JavaScript on each panel. The whole point of was to strip off the current JavaScript object thing hosting the edit_methods, right?
The other option is to write JavaScript instead of HTML which would (obviously) involve mixing presentation and the code. I.e.
$('.txp-list').txpMultiEditForm('addOption', {
'label' : textpattern.gTxt('change_css'),
'value' : 'changecss',
'html' : '<select name="css"></select>'
});Last edited by Gocom (2012-06-26 17:34:30)
Offline
Re: New sections tab, multi-edit control block
Gocom wrote:
There isn’t much else that can be done is there?
Nope.
Offline
Re: New sections tab, multi-edit control block
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-*?
Offline
Re: New sections tab, multi-edit control block
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.
Offline
Re: New sections tab, multi-edit control block
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)
Offline
Re: New sections tab, multi-edit control block
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.
Offline
Re: New sections tab, multi-edit control block
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.
Offline
Re: New sections tab, multi-edit control block
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 thetxp-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)
Offline
Re: New sections tab, multi-edit control block
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?
Offline
Re: New sections tab, multi-edit control block
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-editand 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)
Offline