|Expected behavior for publish method with lists and nested sets||Elin||12/29/11 5:22 PM|
As people who follow the tracker know, recently we have been doing a lot of difficult work on nested tables. We did find a couple of platform bugs that solve some of these issues, but I think there are still more there.
This post is about one of them. If we could document expected behavior I think we can be that much closer to not constantly responding to issue reports where people expect a different behavior and then switching back and forth. It's a platform issue as well, since much of this is controlled by the JTableNested class, but the platform is just a tool for the CMS and if the CMS wants something different there is no reason it can't have it.
Note: this post is only about changes in state, not about deletion.
Situation:When we are in the backend grids Menus and Categories for tables that extend JTableNested I think we need to set and stick to a specification of behavior in the publish method when multiple items are selected.
On the whole this is the pattern that currently exists.
1. Pick an item with no children. Change state (i.e. click publish, unpublish, trash and archive in categories), that item will change to the new state.
3. Select Shop Site and Staff (a child) and/or Shop Site and A (a grandchild).
I can see valid arguments for the behavior in #3 being as it is and for #3 being wrong (that is since Shop Site is selected everything under it should be changed), I could also see an argument that behavior #2 is wrong and should behave more like 3. From my perspective, either way is fine as long as it is documented and behaves consistently across all user interfaces and JBS doesn't spend time debating it every couple of months.
I do wonder i in the case of behavior #2 it wouldn't make sense for the UI to automatically place check marks in the boxes for all items that are going to be changed. We had a big discussion about that when it came to menu assignment ALL for modules and I do think it is more understandable with all of them being checked in the UI.
|Re: Expected behavior for publish method with lists and nested sets||Kevin||12/29/11 8:35 PM|
My two pennith ...
With that option yes the children would also automatically receive a check mark. The user could deselect any(or all) of the children if they then so desire ?
Would seem correct.
But would add to ' (i.e. click publish, unpublish, trash and archive in categories)' 'Empty trash' as well ?
|Re: [jbs] Re: Expected behavior for publish method with lists and nested sets||Samuel Moffatt||12/29/11 10:37 PM|
My suggestion is by default changing the state using the list select
options should only change those items selected. Changing the
individual item should only change the individual item. If a batch
change state is required, then this should be another batch operation
(change state of this item and all children) through our existing
batch UI at the bottom (though it is slightly different behaviour,
nothing that can't be reasonably explained).
This provides you with the ability to individually change selected
Personally #2 scares me, I can just imagine a large site accidentally
|RE: [jbs] usage of @$ to hide messages||rgjoyce||12/30/11 1:27 AM|
Not sure if it's worth mentioning or not.... But.
Two of my senior developers mentioned to me today that they're seeing a lot
of developers starting to prefix their variables, functions and arrays with
the @ symbol to hide messages.
Eg: echo @$myvar['xyz'];
If this isn't set, then it will display a notice.
They tell me that this will also suppress warnings and fatal errors, which I
I just wonder if this is in the joomla conding standards. There are 133
|Re: [jbs] usage of @$ to hide messages||Samuel Moffatt||12/30/11 1:36 AM|
So if it's in front of a variable in Joomla! then it's likely a
A great example of this was for me today writing a library which
Certainly there are times when it's bad (at the top of an execution
> To post to this group, send email to joomlab...@googlegroups.com.
|RE: [jbs] usage of @$ to hide messages||rgjoyce||12/30/11 1:41 AM|
Well a further problem can be if you're using it to prefix function names so
that you don't see errors they return.
You can be supressing fatal errors too. Eg: if you mistype the function
name, you'll never see it.
|Re: [jbs] usage of @$ to hide messages||Samuel Moffatt||12/30/11 1:45 AM|
The rest of your code stops running after a fatal error as well,
usually easy to notice that your site stops rendering after you just
wrote some code and hit refresh. However the chances that code written
in Joomla! has a mistyped function behind an error suppression
operator and has survived this long seems unlikely. Not to mention
hard to do while developing.
|Re: [jbs] usage of @$ to hide messages||Kevin||12/30/11 6:30 AM|
If a folder on a computer is moved or deleted then all the subfolders are moved/deleted as well.
|Re: usage of @$ to hide messages||James Brice||12/30/11 8:04 AM|
Another contribution of two pennith ... (c) Kevin acknowledged.
Hmmm - there are a number of deep-rooted issues that make this one
difficult to solve in a clean and satisfactory manner without making
some significant changes to the way Joomla works.
Firstly there is the one seriously over-worked property that defines
published/unpublished/archive/trashed. Perhaps there should be at
least two properties to choose for each category (and maybe content
items also?) - e.g. published/unpublished and normal/trashed/archived.
Or should that be three: published/unpublished, trashed/available and
Using this sort of property pattern would make it possible to archive
or trash a branch of categories and recover them (if - say - done so
by mistake) with the pattern of publication status intact.
Secondly Joomla could employ employ inheritance to great effect - e.g.
category publication status could be published/unpublished/inherited -
and this would do away with the decision as to whether subordinate
categories should change status when the parent status is changed.
Make the default publication state "inherited" and let the site
administrator choose by over-riding this to published/unpublished
wherever he/she wished. As Kevin points out, it only makes sense to
trash or archive complete branches of categories.
Wouldn't it also be nice to have available the option of inherited
menu item properties in place of having to rely on global or tedious
individual item settings?
|Re: [jbs] usage of @$ to hide messages||Samuel Moffatt||12/30/11 3:58 PM|
On Fri, Dec 30, 2011 at 6:30 AM, Kevin <in...@weblinksonline.co.uk> wrote:
So there are two things at play here. Moving isn't so much a problem,
I feel you're confusing these two behaviours. The behaviour of the
Because our model is different. In a file system, "deleting" a file is
> If a parent is Trashed but not any of it's children then what happens to the
They remain with their parent. Someone can reassign them if they wish
> Surely if a user creates a hierarchical structure then that structure should
But in a file system, again, they're not necessarily treated as a
> If a child item is not to be moved/deleted/trashed with the parent then why
Unless you're purging the item, then changing the state is something
|Re: [jbs] Re: usage of @$ to hide messages||Samuel Moffatt||12/30/11 5:21 PM|
On Fri, Dec 30, 2011 at 8:04 AM, James Brice <wsj....@gmail.com> wrote:
The side effect is that each of these will require an index for the
Each solution (including our own), has various pros and cons for
> Using this sort of property pattern would make it possible to archive
Having inherited params (versus the much simpler use global) would
Otherwise on each access you need to walk up the tree to access the
Ideally this would be done when an item is saved or updated but also
Sounds good in theory, just need an effective implementation.
|Re: [jbs] usage of @$ to hide messages||Kevin||12/30/11 5:56 PM|
That explains a lot, thanks for taking the time to explain.
|Re: Expected behavior for publish method with lists and nested sets||Elin||12/30/11 8:21 PM|
As stated in the initial post, I'm not asking about delete (empty trash). That's a separate issue--and separate method-- that we also have to resolve but it could possibly be handled with separate logic. Batch processing is also a separate issue.
My question is specifically about the publish method (which despite its name covers all changes in the state/published field i.e. changing to 2 for archive, 1 for published, 0 for unpublished, -1 for trashed, with a few other possibilities).
The publish method actually has an argument that allows you to choose to include children or not. Currently we are using #2 most of the time except in the scenario outlines in #3. However, what is confusing it scenario 3.
We could possibly do that. That is what happens now if click the select all check box (i.e. you can deselect specific items).
|Re: Expected behavior for publish method with lists and nested sets||Kevin||12/31/11 7:24 PM|
But should not 'empty trash' be consistent 'trashing' an item and its children ?
|Re: [jbs] Re: Expected behavior for publish method with lists and nested sets||Samuel Moffatt||12/31/11 10:53 PM|
Emptying the trash purges it from the database, trashing an item from
another state merely changes a single field.
You can't recover from purging, you can however recover from a state
> To view this discussion on the web visit> https://groups.google.com/d/msg/joomlabugsquad/-/xZOdPzaUaUMJ.
|Re: [jbs] Expected behavior for publish method with lists and nested sets||oc666||1/1/12 1:44 AM|
This topic raised in few bugs that I fixed.
IMHO, we should change state only for the items are marked.
In addition, we need to offer shortcut for users that want to select item with all the its nested items. Suggestion: double click on item check-box would select the item and its sub-items. What do you say about that?
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Elin||1/1/12 4:50 AM|
Ofer, I think that a short cut is a great idea and then also as Kevin suggested earlier we could let people uncheck specific items.
Kevin, as Sam said, it's a totally different and much more serious thing to actually delete items from the database than is to change one field which can easily be changed back. Technically it's also a separate method.
In fact experienced users know how to use the trashed state in reorganizing their sites or working on new parts of their sites taking advantage of the fact that the front end will treat anything in a trashed category as trash when it comes to searching and displaying.
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Andrea Tarr||1/1/12 5:44 AM|
The problem with the double click is that I don't believe there is an accessible alternative for those that don't have a mouse.
Sent from mobile
|Re: [jbs] Expected behavior for publish method with lists and nested sets||oc666||1/1/12 6:00 AM|
Thanks for feedback.
Is there accessible shortcut for such behavior? Maybe keyboard shortcut ctrl+space? (space when check-box focused make regular enable/disable)
|Unsubscribe||Farid||1/1/12 6:49 AM|
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Andrea Tarr||1/1/12 7:03 AM|
|Re: [jbs] Unsubscribe||betweenbrain||1/1/12 7:38 AM|
To unsubscribe from this group, send email to joomlabugsqua...@googlegroups.com.
Lead Developer Construct Template Development Framework
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Elin||1/1/12 8:33 AM|
So the concept is good but using double click won't work. What WOULD be a good UI for this functionality? Any one have ideas?
|Re: [jbs] Expected behavior for publish method with lists and nested sets||oc666||1/1/12 9:21 AM|
The regular sequence to triggered check-box is to focus on it and
So the concept is good but using double click won't work. What WOULD be a good UI for this functionality? Any one have ideas?
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Elin||1/1/12 9:25 AM|
That would work for me. What do others have to say?
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Samuel Moffatt||1/1/12 2:29 PM|
What happens if you have a particular max levels set or if all
children are not visible in the list?
On Sun, Jan 1, 2012 at 9:25 AM, Elin <elin....@gmail.com> wrote:
|Re: [jbs] Expected behavior for publish method with lists and nested sets||oc666||1/1/12 2:39 PM|
IMHO, If we are assuming that:
It supposed to be available only for the items that visible and
unvisible items ignored. Means that unvisible nested items would
If it's would be confirmed, I'll make a patch to fix this issue.
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Kevin||1/1/12 6:17 PM|
"Kevin, as Sam said, it's a totally different and much more serious thing to actually delete items from the database than is to change one field which can easily be changed back. Technically it's also a separate method. "Yes I understand what is being said about the 'mechanics' of what actually happens, but that is not what I meant. It is my contention that although the data is handled differently .. that the average use will want the same 'keystroke methods' with emptying Trash as with Trashing the item. I think most of us non-programmers are aware of the difference in that emptying trash is unrecoverable(except by reinstating a backup).
If all child items are select when Trashing (with the option to be deselected individually) .... then surely the average user will expect the same when emptying the Trash ? After all the Empty Trash option is only a safe guard against accidental deletion is it not ? So if the user accidentally Trashes something it can be recovered. But if they wish to delete it then would they really want to mess around selecting individual items rather than than just selecting the Parent like they did in the first place ?
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Elin||1/1/12 9:49 PM|
I think that's why we're thinking about how to do multiselect usefully. However, if it comes to a choice between having some percentage of users potentially permanently and unexpectedly lose their data and some other users have to handle things in a safer but more annoying way then I go with safety.
Remember too that in this case you are looking at a category screen .. you may not be thinking about the fact that are articles (or whatever) in that category.
Offer I think that Sam's point about the issue of more subcategories on the next page is a good one to think about, aren't you going to potentially end up with orphan items if you just ignore them? I guess they will just move up? Maybe we could have a message that says there are more children of that haven't been deleted?
|Re: [jbs] Expected behavior for publish method with lists and nested sets||oc666||1/2/12 1:22 AM|
Could we popup notice with js like the controller->redirect do?
In addition, for 2.5, IMHO, we require to fix the regular bug - publish 1 selected item with nested items change the state of the sub-items. For 3.0 we'll do the auto-select.
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Elin||1/2/12 4:54 AM|
A message would be good.
Do you see how scenario 3 is working right now -- how it changes the behavior by just changing the selected items?
Maybe with a message for the other scenario
|Re: [jbs] Expected behavior for publish method with lists and nested sets||oc666||1/2/12 5:53 AM|
The third scenario is wrong behavior. For all three scenarios - it should change state only for the selected items no matter if they have child-items or not. This will go for 2.5 and I'll make a patch for the three scenarios.
For 3.0 I'll make a feature of magic selection which include shortcut to select sub-items, and popup if there are sub-items in the next-previous page (maybe with UCM implementation :)
|Re: [jbs] Expected behavior for publish method with lists and nested sets||Elin||1/2/12 2:50 PM|
Scenario 3 is actually the current behavior.
|Re: [jbs] Expected behavior for publish method with lists and nested sets||oc666||1/3/12 4:07 PM|
@Elin & JBS,
I've fix all three scenrios. See new patch in the bug tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27499
I notice why this bug was produce. There is a check before publish, to verify that publish item doesn't have parent item unpublish. Here is the code from publish method in tablenested.php line ~#950):
$query = $this->_db->getQuery(true)->select('n.' .
$k)->from($this->_db->quoteName($this->_tbl) . ' AS
That's make sense that all sub-items of unpublish item should be
unpublish also, and this is the reason the update query took all
node and the sub-items (same method, little bit after):
I've removed all the node left&right arguments from the query
and that fixed the problem (in addition of making publish method
consistently in all use cases)
Nevertheless, when parent-item is unpublish and one of its
sub-items is unpublish also, user cannot publish the sub-item
before publish the parent-item. The next error message raised when
doing this action: "Cannot change the published state when the
parent menu item is of a lesser state".
Please advise and test the patch
Scenario 3 is actually the current behavior.