I have a page with a PXTab control and want to show or hide individual tabs on the page dynamically. How can I control visibility of tabs at runtime?
You can do it in one of the following two ways:
By setting a VisibleExp property on PXTabItem in ASPX page
By
enabling/disabling AllowSelect property of the view that serves as a
DataMember of the grid that is displayed on that tab
Method 1 – VisibleExp
In this method, you directly write the conditions under which the tab should be visible in the screen's ASPX code.
<px:PXTabItem Text="Tax Agency Settings" BindingContext="tab"
VisibleExp="DataControls["chkTaxAgency"].Value = 1">
Note that the binding context is important as it specifies which element's DataControls you want to access in the VisibleExp.
Also DataControls is collection of values for user interface fields, so you need to specify there IDs of controls (not data access class fields).
However, this method is extremely limited in many ways:
The condition checking is restricted to controls available in the UI,
so it is not possible to condition visibility upon the internal state
of the system.
Sometimes this method will require you to include
"fake" data controls into ASPX that will only be checked in
VisibleExp, but won't actually be ever seen by the user.
There seem to be no support for complex conditions including AND/OR.
Ugly " entities instead of normal quotes in the expression – not
particularly readable.
Most importantly, if you need to disable the tab for a particular document type, there is no way around hard - coding a constant into a VisibleExp. You would be explicitly writing something like: VisibleExp="DataControls["edDocumentType"].Value != CHK"
Hard-coding is generally considered a very poor development practice. It poses a significant threat to code maintainability: probably the above code is going to break something in the future. For example if you decide to rename the document codes form CHK to CHQ.
In addition to that, this solution is not easily generalized to situations when you suddenly discover the need to hide the tab not only for checks, but also for other document types. This is due to lack of complex conditional expressions mentioned above.
Method 2 – AllowSelect
Idea of this method is - if you hide all controls from the tab item, than Acumatica will automatically hide tab with no visible controls.
Lets do an example: assume that you need to hide a tab named Applications depending on the document type selected in SO303000 (Invoices):
The tab that we're interested in has a grid control with a data member set to Adjustments:
<px:PXTabItem Text="Applications" RepaintOnDemand="false">
<Template>
<px:PXGrid ID="detgrid" DataSourceID="ds" SkinID="Details">
<Levels>
<px:PXGridLevel DataMember="Adjustments">
............
</px:PXGridLevel>
</Levels>
</px:PXGrid>
</Template>
</px:PXTabItem>
And not that this tab item has only one control - PXGrid.
Also note required property here - RepaintOnDemand="false". This property indicates whether the control refresh tab items content (and select data) after the item becomes visible. Unfortunately, setting it to false incurs certain performance losses. In particular, the Adjustments view' Select will be called much more frequently.
Currently, the Tab is "smart" in the way that it understands that when its child control (PXGridLevel) cannot perform a select on its data member; in this case, the tab hides itself from the UI. This is why you can control the visibility of the tab by setting the AllowSelect property of the cache that corresponds to the Adjustments:
Adjustments.Cache.AllowSelect =
doc.DocType != ARDocType.CashSale
&& doc.DocType != ARDocType.CashReturn;
The above code is written in the ARInvoice_RowSelected handler of the graph, where ARInvoice is the primary DAC and the type of the master records of the page. So, every time ARInvoice is selected, the tab item will become visible or invisible depending on the document type.
This method has its own limitations too:
You should always remember that it is not enough to disable
AllowSelect, you should also enable it when needed. So you need to
evaluate this property every time when event is called.
This method doesn't seem to work without setting the PXTabItem's RepaintOnDemand
property to false (see above).
Source: http://asiablog.acumatica.com/2016/05/hiding-tab-from-user-interface.html
Related
Okay... this is a little difficult to explain but I will try my best.
In Custom Control while adding properties in Property Definition we can set "Allow multiple instances" which allows us to add multiple instances of that property when the control is embedded in XPage.
Similarly, I need to know whether it is possible to add (and remove) Editable Areas in a custom control when it is embedded in XPage? What I plan is that I would have a repeat control inside my custom control and I would be able to put the contents in each editable area in every loop of that repeat.
Is this the right way to go about or am I looking at this problem incorrectly? Any solution not involving editable areas is also welcome :)
Update 4 Apr 2013:
A use case context I am looking for is a simple carousel where contents of each screen in carousel can have different contents. These contents would be put into each (dynamically added) editable area. The contents can be very different from each other with one screen containing only text, other only image and another both image and text.
Look at the table walker example in the 26 original exercises. It does mostly what you are looking for (conceptually). You won't need multiple editable areas. Whatever is inside the repeat gets repeated.
What you want to do is to give the control a custom property "boolean editMode" so you can render that one line to be edited - if that's the UI pattern you want to follow.
You also could consider a dojo table with Ajax which allows for a familiar spreadsheet UI
I am working on a large, worldwide application, which includes access from areas of low bandwidth. As such, I want to use a minimum of SSJS or partial refreshes for all the complex hide/when calculations. Here is what I have so far for a simple "hide/when":
A Yes/No radio button, with CSJS to show a panel ("Yes") or hide the
panel ("No").
The panel has a formTable inside it, and the values are shown or hidden, as per #1.
In the XPage's onClientLoad, the following code is run:
// "getRadioValue" is a simple script to return the value of a radio button
var v_value = getRadioValue("#{id:radioButton}");
v_div = '#{javascript:getClientId("radioButtonPanel")}';
// show or hide div simply use dojo to change the display of the panel
if (v_value == 'Yes') {
showDiv(v_div);
} else {
hideDiv(v_div);
};
For a new document, the onClientLoad script will hide the "radioButtonPanel" successfully. Changing the radio button to "Yes" will show the radioButtonPanel, just as clicking "No" will hide it. It works great! :-)
Once the document is saved and reopened in read mode, though, the onClientLoad CSJS event should read the saved value in the document, and decide to show the panel or not. When the document is opened in edit mode, the onClientLoad fires, reads the radioButton value and successfully shows or hides the panel.
This is what I've tried so far, to get it to work in read mode:
In CSJS, using "#{javascript:currentDocument.getItemValueString('radioButton'}" to get the value,
Doing some calculations in the "rendered" or "visible" properties, but that's SSJS and, if hidden, prevents any of the "show/hideDiv" CSJS visibility style changes.
Adding an old fashioned "div" to compute the style (which is what I used to do before XPages), but since I can't do pass-thru html any more, I can't seem to get a CSJS calculation for the style. Ideally, I can do something like this:
<div id="radioButtonPanel" style="<ComputedValue>">
Where the ComputedValue would read the back end value of the document, and decide to add nothing or "display:none".
Note that I don't want to use viewScopes, since this long form would need many of them for all the other hide/when's.
Is there any way to make this 100% CSJS? I feel like I'm very close, but I wonder if there's something I'm just missing in this whole process.
First, rather than computing style, I'd recommend computing the CSS class instead -- just define a class called hidden that applies the display:none; rule. Then toggling visibility becomes as simple as a call to dojo.addClass or dojo.removeClass.
Second, I see that you're using the #{id:component} syntax to get the client ID of the radio button but using SSJS to get the client ID of the panel. Use the id: syntax for both; this is still just a server-side optimization, but if there are many instances of these calculations, it adds up. Similarly, replace #{javascript:currentDocument.getItemValueString('radioButton'} with #{currentDocument.radioButton}. Both will return the same value, but the latter will be faster.
Finally, any attribute of a pass-thru tag (any component with no namespace, like xp: or xc:) can still be computed, but you'll need to populate the expression by hand, since the editor doesn't know which attributes for valid for these tags, and therefore doesn't provide a graphical expression editor. So if the ideal way to evaluate the initial display is by wrapping the content in a div, the result might look something like this:
<div class="#{javascript:return (currentDocument.getValue('radioButton') == 'Yes' ? 'visible' : 'hidden');}">
<xp:panel>
...
</xp:panel>
</div>
Think "computed subform", but in Xpages.
On one of my custom controls, depending on a certain value, I want to either present a custom control that renders a drop-down list using a combobox or renders an input box with a type-ahead.
This is on a custom control that renders a view, with all view configuration choices handled by a document rather than design, so several different views utilize the same custom control.
For example: I have a By Status view using the custom control that has status as the first column and we use a combobox to allow the user to select which Status value to filter by. Another view is sorted by Requisition number and I want to use a type-ahead instead of the combobox.
My preference is to use the same dynamic view custom control for both and have a formula that determines which of the two (comboBox or inputText) to use. How do I compute which custom control to load?
(Credit for the dynamic view control goes to Scott Good's folks over at Teamworks Solutions.)
During it's life cycle, an XPage exists in two places. First of all a representation of the XPage's relevant components is stored on the server. Then the page goes through a lifecycle, retrieving properties from documents, checking which components should be rendered, retrieving the data for any repeating control such as a View Panel etc., and passing the relevant HTML to the browser. The browser is the second place it exists.
So you can't compute a custom control as such. All you can do is set the loaded property, and loaded needs to be based on a non-dynamic calculation such as a viewScope variable, the current XPage name, a view name stored on the XPage etc. What you would have difficulty doing would be using a different custom control based on data on that row entry.
The other option is the Dynamic Content control or Switch control from the Extension Library. Both are similar to using the loaded property, in that you're putting both custom controls on the page and choosing which to display.
From what you're describing, the loaded property should cover what you need.
Some time back I saw this question on StackOverflow where the author had used Include Page control (xp:include) to include custom controls using pageName attribute based on formula.
<xp:include>
<xp:this.pageName><![CDATA[${javascript:sessionScope.ccPageName + ".xsp";}]]> </xp:this.pageName>
</xp:include>
Similar to the technique described by Paul Withers in his answer the attribute of pageName is also computed on page load.
I have an application that makes use of the Application Layout Control. The UI has two tabs defined in the Title Bar section. The UI also contains a Navigator control in the sidebar that allows users to select links to open other pages. What I am having troubles with is keeping the current tab set as the active tab when users click on links in the current navigator.
The "configuration" property of the Application Layout Control is a complex type, which in turn supports all the properties that define the layout itself. One of those properties is "navigationPath". If Netflix used this control on their site, the value of that property when viewing the movie information page for Ghostbusters might look something like:
/home/genres/comedies/541018
So this property can be thought of as a way of describing the page's current location in the "site map" using *nix filepath syntax.
Each titleBarTab is also a complex type; one of its properties is "selection". This property is intended to be given a value that matches part or all of the current navigationPath for the overall layout. So, continuing the Netflix example, you might define your tabs like this:
<xe:this.titleBarTabs>
<xe:pageTreeNode
page="/genre.xsp"
label="Action"
queryString="genre=action"
selection="/home/genres/action/*" />
<xe:pageTreeNode
page="/genre.xsp"
label="Comedy"
queryString="genre=comedies"
selection="/home/genres/comedies/*" />
<xe:pageTreeNode
page="/genre.xsp"
label="Drama"
queryString="genre=dramas"
selection="/home/genres/dramas/*" />
</xe:this.titleBarTabs>
On the page for Ghostbusters, then, because navigationPath property for the layout matches the pattern defined for the selection property of the pageTreeNode with a label of "Comedy", that tab will appear selected, but the others will not.
Also perhaps worthy of note is that the layout configuration also includes a property called "defaultNavigationPath". The value of this property will be compared against the selection property of each titleBarTab if the navigationPath property has no value. So you typically want to set this to a path that would cause the first tab to appear selected.
Bruce, if I am reading this right, I ran into a similar problem a while back. Does this help at all? Setting a sessionScope variable for a TitleBar tab
I've spent days trying to figure this out and I give up.
I am a LotusScript programmer and have been trying to learn XPages. All of the examples and sample programs I've studied only touch on pieces of this.
Can someone explain to me step by step how to use the Selected property of the Extension Library Navigator control?
I have created my own custom control based on the layout control from the Extension Library and created a custom property called navigationPath. I also created a navigator custom control that has 5 Page Link Nodes. In the "Selected" property of each Page Link Node, I put the following SSJS:
if(compositeData.navigationPath == "/Home/ApplicationPool"){
return true
}else{
return false
}
/Home/ApplicationPool corresponds to the value I put in the "Selection" property of the particular Page Link Node.
In each layout custom control, I set the "navigationPath" property to compositeData.navigationPath.
What did I miss?
there is a selected and selection property and they mean very different things and can't be used at the same time. In the code example in your question above you are using the selected property which is the wrong one in this case.
Your treeNodes in the navigator should be setup to use the selection property, this is a RegEx value that is used to see if it matches the value passed into the application layout via the custom property.
<xe:navigator id="navigator1" expandable="true" expandEffect="wipe">
<xe:this.treeNodes>
<xe:pageTreeNode label="nodeName" page="/page.xsp" selection="/Home/ApplicationPool" />
</xe:this.treeNodes>
</xe:navigator>
As you can see you don't need to use any SSJS to evaluate a true/false outcome. Just match the value in the treeNode to the one in the XPage's applicationLayout control.
If your using tabs in the layout titleBar then you can set a selection property there also that uses the format /Home/.* which will make that tab highlighted for every XPage that have /Home/ at the start of it's navigationpath custom property. Don;t forget it is RegEx so any valid RegEx statement can be used here adding more power to this particular property.
For the tree nodes in the navigator control you define the name of the xpage to open and then the related selection. Example:
<xe:pageTreeNode page="/text.xsp" selection="/Home/Test" label="Test page">
</xe:pageTreeNode>
For the individual xpages using the applicationLayout you define a value for navigationPath. If this value matches an entry in one of the tree nodes the naviagor control, then the corresponding menu item will be highlighted in the browser. The best way to define the value of the navigationPath is by using a custom property (as you are using). Here's an example of that:
<xe:applicationLayout id="applicationLayout1">
<xe:this.configuration>
<xe:oneuiApplication navigationPath="${javascript:compositeData.navigationPath}" ...
You can see examples of using all this in the Extension Library Teamroom and Discussion templates.
Based on my explanation on how to use it, I can see that you are not using the selection property on the navigation control correct. You just need to define a unique value for each tree node (which then will be used if it matches navigationPath on the individual xpages).
So for your specific example change your selection property to just return: "/Home/ApplicationPool"