In Joomla 3.1, I tried to change the published state of an item, but had an error:
Cannot change the published state when the parent item is of a lesser state.
But my item doesn't have a parent, so why am I getting this error?
Make sure your column for state (published, unpublished, trashed...) is "published".
See https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/table/table.php#L1538
Related
I have created a custom module (actually I have created a handful in recent years, and this same obstacle frustrates me every time) following the Kentico documentation:
https://docs.kentico.com/display/K9/Creating+custom+modules
The problem I end up with every time, is in developing the User Interface for Parent/Child classes. I create a Vertical Tab node, and beneath it I add an edit tab and a Binding tab for the child class. This all works, and I can add and remove bindings at will, but what I can't do is ADD a new child class and bind it.
Using the Standard Edit Binding template, I am able to bind EXISTING Job Titles to the selected Category, but I cannot CREATE a new one from that page:
To solve this, I created a custom Edit Binding template, and added a New Child Class Header Action that points to a New / Edit Object child:
Which gives me a button that I can use to add a new child class (Job Title):
This approach works per se, in that I can click the New Job Title button and create a new item on the subsequent page:
But no binding is created to link the child object (Job Title) to the selected parent object (Category), An even bigger problem is that once I click Save, I am presented with the following:
The new object DOES SAVE, but the post-save navigation is somehow failing. The event log offers little in the way of diagnostics:
So I thought to create a completely custom interface to accomplish my needs here, according to the Kentico documentation:
https://docs.kentico.com/display/K9/Manually+creating+the+interface+for+custom+modules
So I change the Element Content of the New Job Title page to a custom page that I created to post a DataForm for the new object:
Taking care to assign the proper Object Types on the Properties Tab:
The intent was to programmatically create the binding upon save and also handle the correct navigation to avoid the ambiguous parameter error above, but when this page loads, the UIContext.ObjectID and UIContext.ParentObjectID are both 0:
So I cannot create the binding programmatically. I was able however to solve the error that I received by manually assigning the redirect. The experience is still lacking even with this hack, since it returns to the listing page, but the user still has to click "Add Items" to assign the binding after successfully creating it with the custom page I built.
This cannot be the proper way to do this, so any help with getting me on the right track would be greatly appreciated.
In order for the EditedObject to have a value you have to either decorate the page with the EditedObjectAtribute e.g. like this:
[EditedObject("<custom.objecttype>", "<objectid>", ...)]
or set the object yourself:
int objectId = QueryHelper.GetInteger("objectid", 0);
EditedObject = SomeInfoProvider.GetSomeInfo(objectId);
In your case, I'd recommend exploring what query parameters are available on the page and using them to fetch appropriate object(s). Also, make sure "JobCategoryId" is passed to the "New Job Title" dialog so that you can create the binding.
Btw - kudos for well asked question!
I'm trying to bind a UITableView to an ObservableCollection<MyTypeViewModel> using MvxStandardTableViewSource, and I'm getting weird behavior and bindings that aren't working
The (partial) code is this:
tblFeatures = new UITableView ();
mSource = new MvxStandardTableViewSource(tblFeatures, "TitleText Name");
var set = this.CreateBindingSet<MyTypeView, MyTypeViewModel> ();
set.Bind(mSource).To (vm => vm.Objects);
set.Bind(mSource).For(s => s.SelectedItem).To (vm => vm.SelectedObject);
set.Apply ();
What I'm seeing is that when I select an item in the table, it does update SelectedObject with the new value. But when I change SelectedObject by some other means, the table does not update the displayed selected item. I have verified that the SelectedObject really is being changed, by setting a breakpoint and by binding another control to it; the other control (a label) does change as the selection changes, but the UITableView does not.
Am I doing something wrong, or could this be an issue in MVVMCross?
The selecteditem binding was requested as a 'nice to have' and was mainly requested for the user story where a user clicks on a list item - so this is currently a 'one way to source' implementation.
The very basic details and some code can be found via - https://github.com/slodge/MvvmCross/issues/278
In truth, the current binding is abusing the 'selected' paradigm - as it doesn't really reflect the selection state of the cell and also has no handling of mutiselect - instead it just lets the viewmodel know the latest tapped item.
If there are genuine user stories/requirements for full two'way binding, then these should be addable - eg if the user story were for scrolling the item into view then 'scrollToRowAt' could be used - see How to scroll UITableView to specific position - but this again might not be true 'selection' within the uitableview.
if you wanted to implement this yourself it should be fairly straight-forward to override the binding with your own one (see the custom binding n+1 in http://mvvmcross.wordpress.com for an intro on custom bindings).
could this be an issue in MVVMCross?
Overall I think I'd categorise it as a known limitation of that particular binding caused by lack of user demand and by some confusion over whether selection genuinely means selection in the touch screen era.
if it was logged as a bug I'd say it wasn't.. If it was logged ss a feature request I'd try getting as much user input as i could about what devs really want from this, whether they want true cell selection or scroll into view, both or something more.
By other means you mean not from UI thread I presume. Please try by invoking the change on UI thread.
Sometimes there are actions one wants to take on a Node but one needs access to the Scene or for other reasons needs it to be added to the Scene first.
In Swing, I could use a hierarchy change listener to do this. Is there some type of notification or event when a Node is added to the hierarchy so that getScene will return non-null?
Add a ChangeListener to the node's sceneProperty to be notified to changes of the scene the node is attached to, including when the scene property changes from null to some value.
There appears to be a difference between managed bean state and component tree state. You can control managed bean state by using annotations like #RequestScoped and #SessionScoped, but it seems you don't have a choice in whether the component tree state is saved or not (although you can choose whether it is saved on the server or client).
It seems like component tree state should only be needed for the duration of a single request as a temporary data structure to help process a request. It should be rebuilt from scratch for each request. With JSF 2.0 partial state saving makes the situation better because only form data is saved, but I don't understand why having even form data from the previous request is useful.
If your application uses only request scope managed beans then it especially doesn't make sense to save component tree state between requests. Even if your application has session scope managed beans I would assume that the managed beans would hold the state and the component tree still wouldn't need to have any state between requests.
Adding to the previous answer, ever since JSF 2.0 something called partial state saving is used by default.
The default view description language in JSF (Facelets) creates the whole component tree from the original Facelet after every request and initializes the components from their corresponding tag attributes. It then marks the state.
Every subsequent state change is then remembered as a delta change, and it's this state that is actually being saved. It might just well turn out that there simply are no such changes, and then the view state is empty (because of a bug, the state was never truly empty, but that has been recently fixed. See http://java.net/jira/browse/JAVASERVERFACES-2203 for details)
So the big question is, what's actually in this state then when it's non-empty?
As BalusC already remarked, this could hold dynamic changes to the component tree. Those changes can either be initiated from backing beans, or from within static components. A simple example of the kind of component that does this dynamic changing is a table component that creates child column components based on the actual number of columns in a data set.
Another important usage for the view state is remembering values that have been changed inside components, but have not been pushed into the model. This can be such things as flicking a switch in a switch component, moving a slider in a dial component etc.
One particular example is the viewParam component, which remembers the request parameter (query string parameter for GET or non-faces POST parameter) with which it was initialized. See this for some more info about that: http://arjan-tijms.omnifaces.org/2011/07/stateless-vs-stateful-jsf-view.html
There is also a strong relation with stateful components remembering UI state and conversion or validation that fails. In this case, the UI components will remember the values entered by the user, and will remember that there was a conversion/validation error.
Yet another usage for the state is optimization. Some components calculate values that they deem to be expensive to calculate and store these in the view state. For instance, UIInput components do this after the first post-back:
private boolean validateEmptyFields(FacesContext ctx) {
if (validateEmptyFields == null) {
ExternalContext extCtx = ctx.getExternalContext();
String val = extCtx.getInitParameter(VALIDATE_EMPTY_FIELDS_PARAM_NAME);
if (val == null) {
val = (String) extCtx.getApplicationMap().get(VALIDATE_EMPTY_FIELDS_PARAM_NAME);
}
if (val == null || "auto".equals(val)) {
validateEmptyFields = isBeansValidationAvailable(ctx);
} else {
validateEmptyFields = Boolean.valueOf(val);
}
}
return validateEmptyFields;
}
After this validateEmptyFields is stored in the view state so it doesn't have to be calculated again upon the following form submits. An improvement would be if users can choose between re-calculating or storing (the well know time-space optimization).
The very concept of state is what has plagued web application development since its early conception. Everyone wants to have interactions that are essentially stateful, yet almost nobody wants to handle it or even think about it.
JSF has been trying to provide an answer here, but it's obviously not perfect and there's room for improvement. JSF's insistence on being able to restore view state (even empty view state) can be troublesome, although as was mentioned in another answer it does provide an implicit protection against CSRF. JSF 2.2 will get more explicit CSRF protection (see e.g. http://arjan-tijms.omnifaces.org/p/jsf-22.html#869), so maybe we will see some change here in the future.
Having an option to turn off state per component and having an easy hook to restore state incase the framework can't (as in ASP.NET) might also be helpful.
Because the component tree can be altered programmatically depending on the initial request. This is not necessarily reproduceable on the subsequent request whenever the form data has to be processed.
Further I have the impression that you think that the component tree also holds the model values. This is not true. It only holds references (by expression language) to the model values (the managed bean properties). The view state does not copy/duplicate/contain the model state. It's just a pure UI component tree. Perhaps your confusion is based on this. Note that the term "form data" is to be interpreted as submitted values and model values.
See also:
Why JSF saves the state of UI components on server?
First I apologize for the length but I want to ensure I get enough information out. I have an interesting problem that really shouldn't be difficult. I know that if you want to have the NSOutlineView scroll to and want display a specific row you simply use this pattern:
NSInteger row = [self.myOutlineView rowForItem:myItem];
[self.myOutlineView scrollRowToVisible:row];
I am not using a NSTreeController in favor of using delegation.
I am using an adapter pattern class to act as my data. The adapter wraps a number of different types. It is a simple structure:
[adapter children] ----- *[adapter parent]
So the adapter takes care of dealing with child count, can add, can remove, can expand, etc. and also acts like a data transport object.
So with that all out of the way here is the crux of the problem. When I add a new item to the NSOutlineView I start by adding a new child adapter to the adapter that is selected in the outline view. Then I reload the item with the children using:
[self.myOutlineView reloadItem:selectedAdapter reloadChildren:YES];
I then display the view for this object and attempt to synchronize the NSOutlineView so the selected row relates to the newly displayed view. So in a simple way the steps are:
Initially load the NSOutlineView with data utilizing the NSOutlineDataSource protocol
User selects an item (adapter) that can add child items
User clicks "Add" button
A new empty represented object is created
The new represented object is wrapped in an adapter
The newly created adapter is added to the children of the selected adapter
A new view is created using the new represented object and displayed
The selected (parent) node and its children is reloaded in the NSOutlineView
The newly created row in the NSOutlineView is scrolled to view which synchronizes the view and the selection of the NSOutlineView
So here is the problem. The NSOutlineView will not find the newly added item if you use the rowForItem method. Yet after I reload I can expand the parent node and select the newly added item and everything works fine. In an attempt to fix the problem I have programmatically expanded the parent node (exposing the new item) then attempt to scroll to the new item and it still cannot find the row. The rowForItem returns -1.
Have I missed something when adding a new item that I am not updating something in the NSOutlineView? I've tried many different things without success and any help will be greatly appreciated.
Thanks in advance,
Rob
Solved my own problem...finally.
Since I was adding my first child to that node and it was changing from non-expandable to expandable it needed to be expanded first, then scroll to view, then select the item. No more problem.