Search Results

Search found 34 results on 2 pages for 'adfv'.

Page 2/2 | < Previous Page | 1 2 

• Pretty URL in ADF Faces of JDeveloper 11.1.2.2

  - by Frank Nimphius

  Many features planned for Oracle JDeveloper 12c find their way into current releases of Oracle JDeveloper 11g R1 and JDeveloper 11g R2. One example of such a feature is "pretty URL" - or "clean URL" as the Oracle JDeveloper 11g R2 (11.1.2.2) documentation puts it. "A.2.3.24 Clean URLs Historically, ADF Faces has used URL parameters to hold information, such as window IDs and state. However, URL parameters can prevent search engines from recognizing when URLs are actually the same, and therefore interfere with analytics. URL parameters can also interfere with bookmarking. By default, ADF Faces removes URL parameters using the HTML5 History Management API. If that API is unavailable, then session cookies are used.You can also manually configure how URL parameters are removed using the context parameter oracle.adf.view.rich.prettyURL.OPTIONS. Set the parameter to off so that no parameters are removed. Set the parameter to useHistoryApi to only use the HTML5 History Management API. If a browser does not support this API, then no parameters will be removed. Set the parameter to useCookies to use session cookies to remove parameters. If the browser does not support cookies, then no parameters will be removed." See: http://docs.oracle.com/cd/E26098_01/web.1112/e16181/ap_config.htm#ADFUI12856 So basically, what this part in the documentation says is: In JDeveloper 11g R2 (11.1.2.2), Oracle ADF Faces automatically removes its internally used dynamic parameters from the URL You can influence the setting with the prettyURL.OPTIONS context option, which however is not recommended you to do because the default behavior is able to detect if the browser client supports HTML 5 History management or not. In the latter case it the uses a session cookie and if this doesn't work, falls back to the "old" URL parameter adding. The information that is not so explicit and clearly mentioned in the documentation is that this is only for ADF Faces parameters (such as _afrLoop, Adf-Window-Id, etc.), but not the ADF controller token (_adf.ctrl-state)! Removing the ADF controller token is an enhancement request that will be implemented in Oracle JDeveloper 12c

  Read the article

• PanelCollection Confusion ... or, what is an event root ?

  - by frank.nimphius

  Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} A command button added to the toolbar of a Panel Collection component does not cause field validation in a form when pressed. While this appears confusing it works as designed. Instead of a full page re-rendering, ADF Faces events and components can trigger partial page refresh, in which only portions of a page are refresh upon a request. In addition, some components - including the af:popup and af:subForm - represent event roots. Event roots don't propagated event notification outside of the component tag boundary, which means that the ADF Faces lifecycle only executed on components that are children of the event root component. The PanelCollection component is an event root and therefore only validates and refreshes data of its child components.

  Read the article

• How to detect browser type and version from ADF Faces

  - by Frank Nimphius

  Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} Sometimes ADF applications need to know about the user browser type and version. For this, assuming you need this information in Java, you can use the Trinidad RequestContext object. You could also use the AdfFacesContext object for the same, but since the ADF Faces Agent class is marked as deprecated, using the equivalent Trinidad classes is the better choice. The source code below prints the user browser information to the Oracle JDeveloper message window import org.apache.myfaces.trinidad.context.Agent; import org.apache.myfaces.trinidad.context.RequestContext; … RequestContext requestCtx = RequestContext.getCurrentInstance(); Agent agent = requestCtx.getAgent(); String version = agent.getAgentVersion(); String browser = agent.getAgentName(); String platform = agent.getPlatformName(); String platformVersion = agent.getPlatformVersion(); System.out.println("=================="); System.out.println("Your browser information: "); System.out.println("Browser: "+browser); System.out.println("Browser Version : "+version); System.out.println("Browser Platform: "+platform); System.out.println("Browser Platform Version: "+platformVersion); System.out.println("==================");

  Read the article

• af:inputSlider doesn't render in popup for FF, Safari and Chrome

  - by Frank Nimphius

  A problem reported on OTN is that the af:inputSlider component of Oracle JDeveloper 11.1.2.2 doesn't show on all browsers except IE when the slider is added as the sole component in a popup. The problem reproduces with the ADF Faces component demo and I filed bug 14207690. The work around, posted by OTN user "Tses" is to set the inlineStyle property on the slider to table <af:inputNumberSlider ... inlineStyle="display:table;"/>

  Read the article

• Problem with deleting table rows using ctrl+a for row selection

  - by Frank Nimphius

  Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} The following code is commonly shown and documented for how to access the row key of selected table rows in an ADF Faces table configured for multi row selection. public void onRemoveSelectedTableRows(ActionEvent actionEvent) {    RichTable richTable = … get access to your table instance …    CollectionModel cm =(CollectionModel)richTable.getValue();    RowKeySet rowKeySet = (RowKeySet)richTable.getSelectedRowKeys();             for (Object key : rowKeySet) {       richTable.setRowKey(key);       JUCtrlHierNodeBinding rowData = (JUCtrlHierNodeBinding)cm.getRowData();       // do something with rowData e.g.update, print, copy   }    //optional, if you changed data, refresh the table         AdfFacesContext adfFacesContext = AdfFacesContext.getCurrentInstance(); adfFacesContext.addPartialTarget(richTable);   return null; } The code shown above works for 99.5 % of all use cases that deal with multi row selection enabled ADF Faces tables, except for when users use the ctrl+a key to mark all rows for delete. Just to make sure I am clear: if you use ctrl+a to mark rows to perform any other operation on them – like bulk updating all rows for a specific attribute – then this works with the code shown above. Even for bulk row delete, any other mean of row selection (shift+click and multiple ctrl+click) works like a charm and the rows are deleted. So apparently it is the use of ctrl+a that causes the problem when deleting multiple rows of an ADF Faces table. To implement code that works for all table selection use cases, including the one to delete all table rows in one go, you use the code shown below. public void onRemoveSelectedTableRows(ActionEvent actionEvent) {   RichTable richTable = … get access to your table instance …   CollectionModel cm = (CollectionModel)richTable.getValue();   RowKeySet rowKeySet = (RowKeySet)richTable.getSelectedRowKeys();   Object[] rowKeySetArray = rowKeySet.toArray();      for (Object key : rowKeySetArray){               richTable.setRowKey(key);     JUCtrlHierNodeBinding rowData = (JUCtrlHierNodeBinding)cm.getRowData();                              rowData.getRow().remove();   }   AdfFacesContext adfFacesContext = AdfFacesContext.getCurrentInstance();          adfFacesContext.addPartialTarget(richTable); }

  Read the article

• Iterating selected rows in an ADF Faces table

  - by Frank Nimphius

  In OTN Harvest May 2012; http://www.oracle.com/technetwork/developer-tools/adf/learnmore/may2012-otn-harvest-1652358.pdf I wrote about "Common mistake when iterating <af:table> rows". In this entry I showed code to access the row associated with a selected table row from the binding layer to avoid the problem of having to programmatically change the selected table row. As it turns out, my solution only worked fro selected table rows that are in the current iterator query range. So here's a solution that works for all ranges public String onButtonPress() { RowKeySet rks = table.getSelectedRowKeys(); Iterator it = rks.iterator(); while (it.hasNext()) { List selectedRowKeyPath = (List)it.next(); //table is the JSF component reference created using the table's binding //property Row row = ((JUCtrlHierNodeBinding)table.getRowData(selectedRowKeyPath)).getRow(); System.out.println("Print Test: " + row.getAttribute(1)); } return null; }

  Read the article

• Solving the context menu problem with drag and drop in trees

  - by Frank Nimphius

  Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} The following drag-and-drop problem has been reported on OTN: An ADF Faces tree component is configured with a af:collectionDropTarget tag to handle drop events. The same tree component also has a context menu defined that is shown when users select the tree with the right mouse button. The problem now was - and I could reproduce this - that the context menu stopped working after the first time the tree handled a drop event. The drag and drop use case is to associate employees from a table to a department in the tree using drag and drop. The drop handler code in the managed bean looked up the tree node that received the drop event to determine the department ID to assign to the employee. For this code similar to the one shown below was used List dropRowKey = (List) dropEvent.getDropSite(); //if no dropsite then drop area was not a data area if(dropRowKey == null){    return DnDAction.NONE; }                tree.setRowKey(dropRowKey); JUCtrlHierNodeBinding dropNode = (JUCtrlHierNodeBinding) tree.getRowData(); Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} So what happens in this code? The drop event contains the dropSite reference, which is the row key of the tree node that received the drop event. The code then sets the key to the tree in a call to getRowDate() returns the node information for the drop target (the department). This however causes the tree state to go out of synch with its model (ADF tree binding), which is known to cause issues. In this use case the issue caused by this is that the context menu no longer shows up. To fix the problem, the code needs to be changes to read the current row key from the key, then perform the drop operation and at the end set the origin (or model) row key back //memorize current row key Object currentRowKey = tree.getRowKey();        List dropRowKey = (List) dropEvent.getDropSite(); //if no dropsite then drop area was not a data area if(dropRowKey == null){   return DnDAction.NONE;   }              tree.setRowKey(dropRowKey); JUCtrlHierNodeBinding dropNode = (JUCtrlHierNodeBinding) tree.getRowData(); ... do your stuff here .... //set current row key back tree.setRowKey(currentRowKey); AdfFacesContext.getCurrentInstance().addPartialTarget(tree); Node the code line that sets the row key back to its original value.

  Read the article

• Accessing ADF Faces components that are read-only from JavaScript

  - by Frank Nimphius

  Almost as a note to myself and to justify the time I spent on analyzing aproblem, a quick note on what to watch out for when working trying to access read-only ADF Faces components from JavaScript.  Those who tried JavaScript in ADF Faces probably know that you need to ensure the ADF Faces component  is represented by a JavaScript object on the client. You do this either implicitly by adding an af:clientListener component (in case you want to listen for a component event) or explicitly by setting the ADF Faces component clientComponent property to true. For the use case I looked at in JDeveloper 11g R1 (11.1.1.7) I needed to make an output text component clickable to call a JavaScript function in response. Though I added the af:clientComponent tag to the component I recognized that it also needed the clientComponent property set to true. Though I remember this as not being required in 11.1.1.6, I like the new behavior as it helps preventing read-only components from firing client side events unless you tell it to do so by setting the clientComponent property to true. Note: As the time of writing, JDeveloper 11.1.1.7 is not publicly available and I put the note in this blog as a reminder in case you ever hit a similar challenge so you know what to do.

  Read the article

• How to set the initial component focus

  - by frank.nimphius

  Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;} In ADF Faces, you use the af:document tag's initialFocusId to define the initial component focus. For this, specify the id property value of the component that you want to put the initial focus on. Identifiers are relative to the component, and must account for NamingContainers. You can use a single colon to start the search from the root, or multiple colons to move up through the NamingContainers - "::" will pop out of the component's naming container and begin the search from there, ":::" will pop out of two naming containers and begin the search from there. Alternatively you can add the naming container IDs as a prefix to the component Id, e.g. nc1:nc2:comp1. http://download.oracle.com/docs/cd/E17904_01/apirefs.1111/e12419/tagdoc/af_document.html To set the initial focus to a component located in a page fragment that is exposed through an ADF region, keep in mind that ADF Faces regions - af:region - is a naming container too. To address an input text field with the id "it1" in an ADF region exposed by an af:region tag with the id r1, you use the following reference in af:document: <af:document id="d1" initialFocusId="r1:0:it1"> Note the "0" index in the client Id. Also, make sure the input text component has its clientComponent property set to true as otherwise no client component exist to put focus on.

  Read the article

< Previous Page | 1 2