Szukaj…


Wprowadzenie

Ten podręcznik zawiera różne sposoby, w jakie portlet może koordynować lub komunikować się między sobą, oraz różne scenariusze, w których stosowane jest określone podejście.

Uwagi

Bibliografia:

  1. Publiczny parametr renderowania
  2. JSR 286 dane techniczne
  3. Sesja portletowa

Korzystanie z publicznego parametru renderowania

Takie podejście wprowadzono w JSR 286.

W JSR 168 parametry renderowania ustawione w procesieAkcja portletu były dostępne tylko w tym portlecie. Dzięki funkcji Publiczne parametry renderowania parametry renderowania ustawione w procesieAkcja jednego portletu będą dostępne również w renderowaniu innych portletów. Aby skonfigurować to dla wszystkich portletów obsługujących to:

Dodaj tag <supported-public-render-parameter> tuż przed końcem tagu portlet w portlet.xml

<security-role-ref>
    <role-name>user</role-name>
</security-role-ref>
<supported-public-render-parameter>{param-name}</supported-public-render-parameter>
</portlet>

Dodaj tag <public-render-parameter> tuż przed końcem tagu <portlet-app>

  <public-render-parameter>
    <identifier>{param-name}</identifier>
    <qname xmlns:x="localhost">x:{param-name}</qname>
  </public-render-parameter>
</portlet-app>

W metodzie processAction wartość parametru musi być ustawiona w odpowiedzi

res.setRenderParameter({param-name},{param-value});

Po zakończeniu konfiguracji tego dla wszystkich wymaganych portletów, po wykonaniu fazy akcji danego portletu, parametry powinny być dostępne w fazie renderowania dla wszystkich portletów wspierających na stronie, niezależnie od tego, czy są częścią tej samej lub innej aplikacji (wojna ).

Korzystanie z sesji portletu

Jest to jedno podejście, które istnieje od czasów JSR 168. Pozwala nam udostępniać atrybuty za pomocą sesji portletu. Sesja portletu może mieć różne typy zakresów:

  1. Zakres portletu (atrybuty dostępne tylko w obrębie portletu)
  2. Zakres aplikacji (atrybuty dostępne w całej aplikacji [wojna])

Aby zastosować to podejście, nie musimy wprowadzać żadnych wpisów w konfiguracji portletu, ponieważ sesja portletu jest łatwo dostępna w żądaniu portletu:

PortletSession session = renderRequest.getPortletSession();
session.setAttribute("attribute-name","attribute-value", PortletSession.APPLICATION_SCOPE);

lub

PortletSession session = renderRequest.getPortletSession();
session.setAttribute("attribute-name","attribute-value", PortletSession.PORTLET_SCOPE);

Atrybut można pobrać tylko z odpowiedniego zakresu. Podobnie jak w przypadku zestawu atrybutów w zakresie portletu, musimy go pobrać za pomocą

PortletSession session = renderRequest.getPortletSession();
String attributeValue = (String) session.getAttribute("attribute-name", PortletSession.PORTLET_SCOPE);

Głównym ograniczeniem tego podejścia jest brak udostępniania innym portletom poza zakresem aplikacji. Aby temu zaradzić, istnieje specjalne podejście do dodawania <private-session-attributes liferay-portlet.xml > do liferay-portlet.xml

    <private-session-attributes>false</private-session-attributes>
    <header-portlet-css>/css/main.css</header-portlet-css>
    <footer-portlet-javascript>/js/main.js</footer-portlet-javascript>
    <css-class-wrapper>{portlet-name}</css-class-wrapper>
</portlet>

dla wszystkich portletów, w których atrybuty są ustawiane i pobierane.

Korzystanie z funkcji eventing

Mechanizm zdarzeń jest rozszerzoną wersją publicznego parametru wyświetlania, z dodatkową funkcją przekazywania niestandardowych obiektów do innych portletów, ale z narzutem fazy zdarzenia.

Aby to osiągnąć, mechanizm ten składa się z

  1. Portlet wydawcy
  2. Portlet Procesor (konsument), gdzie oba mogą być częścią różnych aplikacji portletowych.

Zacząć z,

Dodaj <supported-publishing-event> do portletu wydawcy w portlet.xml

    <security-role-ref>
        <role-name>user</role-name>
    </security-role-ref>
    <supported-publishing-event>
         <qname xmlns:x="http:sun.com/events">x:Employee</qname>
    </supported-publishing-event>
  </portlet>

Dodaj <supported-processing-event> do portletu procesora w portlet.xml

<security-role-ref>
        <role-name>user</role-name>
    </security-role-ref>
    <supported-processing-event>
        <qname xmlns:x="http:sun.com/events">x:Employee</qname>
     </supported-processing-event>
</portlet>

Dodaj <event-definition> do obu portletów, definiując nazwę zdarzenia i wpisz portlet.xml

<event-definition>   
  <qname xmlns:x="http:sun.com/events">x:Employee</qname>
  <value-type>com.sun.portal.portlet.users.Employee</value-type>
</event-definition>
   </portlet-app>

Następnie musimy utworzyć klasę dla typu zdarzenia (w przypadku typu niestandardowego)

public class Employee implements Serializable {
  public Employee() {
  }
  private String name;
  private int userId; 

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public int getUserId() {
    return userId;
  }
  public void setUserId(int id)
  {
    this.userId = id;
  }

}

Teraz w portlecie wydawcy wydarzenie musi zostać opublikowane w fazie akcji

    QName qname = new QName("http:sun.com/events" , "Employee");
    Employee emp = new Employee();
    emp.setName("Rahul");
    emp.setUserId(4567);
    res.setEvent(qname, emp);

Po opublikowaniu wydarzenia wydarzenie musi zostać przetworzone przez portlet wydawcy w fazie wydarzenia.

Faza zdarzenia została wprowadzona w JSR 286 i jest wykonywana przed fazą renderowania portletu, jeśli ma to zastosowanie

@ProcessEvent(qname = "{http:sun.com/events}Employee")
public void processEvent(EventRequest request, EventResponse response) {

    Event event = request.getEvent();
    if(event.getName().equals("Employee")){
      Employee payload = (Employee)event.getValue();
      response.setRenderParameter("EmpName",
      payload.getName());
    }

}

które można następnie pobrać z parametru renderowania za pomocą żądania renderowania.



Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow