Accessing global custom attributes in WebCenter Portal 12c

Global Attributes can be declared to share variables and information between all the Portals.

Out of the box, one of the attributes is the wcSessionTimeoutPeriod responsible for the session timeout. My friend Daniel already blogged about
accessing this on his blog entry.http://blog.vassit.co.uk/knowledge/access-global-custom-attributes

Way of accessing in EL is still working as following

HOW CAN BE ACCESSED USING EL EXPRESSIONS?

#{WCAppContext.application.applicationConfig.customAttributes[‘wcSessionTimeoutPeriod’]}

If you want to use Java API, one way to use

ADFUtils.evaluateEL("#{WCAppContext.application.applicationConfig.customAttributes['wcSessionTimeoutPeriod']}")

But if you are concern about performance, it’s not best practices to use evaluate EL in the java class. It is better to use OOTB API to access this. in 12c you can use following way

WCApplicationContext wcAppCtx = WCApplicationContext.getCurrentInstance();
WCApplication wcApp = wcAppCtx.getApplication();
WebCenterType wcMeta = wcApp.getApplicationConfig();
CustomAttributes customAttr = wcMeta.getCustomAttributes();
...

This will work in 12c.

Happy learning

Get value of the outputtext in javascript and access to backing bean in Oracle ADF

Requirement -Get value of the outputtext in javascript and send it to backing bean in Oracle ADF
Solution – We will use clientListener to call java script function and Serverlistener for calling java function

Below is the code for accomplish this

– page code

    <af:outputText value="value outputText" id="ot32" clientComponent="true"
                    shortDesc="shortDesc">
        <af:clientListener type="mouseOver"
                method="customJsFunction"/>
        <af:serverListener type="mycustomserverEvent" method="#{OutputTextCase11.handleServerEvent}"/>                
    </af:outputText>
    <br></br>
    <af:outputText value="Init" shortDesc="shortDesc" id="ot1" clientComponent="true"/>
 

– find javascript function code

   var customJsFunction = function(event)
   {
      var exceptiondata = event.getSource().findComponent("ot32").getValue();
      AdfCustomEvent.queue(event.getSource(),
                       "mycustomserverEvent",
                       {param1:exceptiondata},
                       true);
      return true;
   }
 

– method in bean

  public void handleServerEvent(ClientEvent ce)
  {
    String param = (String)ce.getParameters().get("param1");
    RichOutputText outputText=(RichOutputText)ce.getComponent().findComponent("ot1");
    outputText.setShortDesc(param);
    outputText.setValue(param);
    AdfFacesContext.getCurrentInstance().addPartialTarget(outputText);
  }
 

happy coding with Vinay in techartifact….

Access one Managed Bean from another in JSF 2.0 | Techartifact

Requirement- Access one Managed Bean from another in JSF

Solution- There are two ways-

Dependency Injection

We can use JSF 2 @ManagedProperty annotation

In the managed bean add a @ManagedProperty annotation to the related property

@ManagedBean(name="currentBean")
@RequestScoped
public class CurrentBean 
{

    @ManagedProperty(value="#{requiredBean}")
    private RequiredBean requiredBean;

    public RequiredBean getRequiredBean()
    {
        return requiredBean;
    }

    public void setRequiredBean(RequiredBean requiredBean)
    {
        this.requiredBean= requiredBean;
    }

    // ....


}

Usingthrough faces-config.xml

<managed-bean>
   <managed-bean-name>requiredbBean</managed-bean-name>
   <managed-bean-class>vinay.common.RequiredBean</managed-bean-class>
   <managed-bean-scope>session</managed-bean-scope>
 </managed-bean>

 <managed-bean>
   <managed-bean-name>currentBean</managed-bean-name>
   <managed-bean-class>vinay.common.CurrentBean</managed-bean-class>
   <managed-bean-scope>request</managed-bean-scope>
   <managed-property>
     <property-name>requiredbBean</property-name>
     <value>#{requiredbBean}</value>
   </managed-property>
 </managed-bean>

Following are the constraints:

-> The current bean must have scope which is the same as or shorter than the required bean
-> The using bean must have a property-setter method which takes the required bean as a parameter
-> The beans cannot have managed dependencies on each other.