Conversions de portlets HCL Digital Experience (AIX® IBM® i Linux™ Solaris Windows™)

Vous pouvez convertir vos portlets HCL de base et les portlets HCL qui utilisent la structure de portlet Struts en API de portlet standard.

Conversion de portlets HCL de base en portlets standard
Conversion de portlets HCL Digital Experience utilisant la structure de portlets Struts

Conversion de portlets HCL de base en portlets standard

Cette rubrique décrit certaines des modifications les plus courantes requises pour convertir un portlet HCL en un portlet standard. De nombreuses tâches de conversion dépendent de la complexité du code du portlet. Vous devez vous familiariser avec les spécifications Java Portlet Specification pour établir quelles sont les autres modifications non traitées dans cette rubrique.

Modification de la source Java
Modification de la source JSP
Modification du descripteur de déploiement de portlet

Modification de la source Java

Modification des instructions d'importation afin d'utiliser les packages standard.

Modifiez ce qui suit :

    import org.apache.jetspeed.portlet.*; 
    import org.apache.jetspeed.service.*;

en le remplaçant par :

    import javax.portlet.*;
    import com.ibm.portal.portlet.service.*;

Modification de l'héritage de classe pour utiliser GenericPortlet. Il est à noter que ActionListener n'est pas implémenté.

Modifiez ce qui suit :

    public class SamplePortlet extends PortletAdapter implements ActionListener{  
    ...
    }

en le remplaçant par :

    public class SamplePortlet extends GenericPortlet{
    ...
    }

Modification des objets utilisés pour toutes les méthodes d'affichage. Dans l'API de portlet standard, PortletRequest et PortletResponse définissent des fonctions communes aux sous-classes RenderRequest et RenderResponse. Ces sous-classes constituent les arguments de toutes les implémentations de la méthode d'affichage(), y compris doView(), doEdit() et doHelp().
Modifiez ce qui suit :
```
  public void doView(PortletRequest request, PortletResponse response) {  
     ...
  }
    
```
en le remplaçant par :
```
  public void doView(RenderRequest request, RenderResponse response)
       throws PortletException, IOException{
       ...
  }
```
Modification de la méthode actionPerformed(). Dans l'API de portlet standard, cette méthode est remplacée par la méthode processAction(), qui ne nécessite pas d'implémentation d'un module d'écoute de la part du portlet. La méthode processAction() accepte ActionRequest et ActionResponse comme arguments, qui étendent PortletRequest et PortletResponse.
Modifiez ce qui suit :
```
    public void actionPerformed(ActionEvent event) throws PortletException{  
    ...
    }
    
```
en le remplaçant par :
```
  public void processAction(ActionRequest request, ActionResponse response)  
       throws PortletException, IOException{
       ...
  }     
```
Modifiez la manière dont le type de contenu de réponse est défini. Dans l'API de portlet standard, le type MIME de la sortie renvoyée dans la réponse doit être défini avant d'inclure le JSP. Les portlets HCL déclarent le type MIME dans les instructions de la page JSP. Par conséquent, ce changement rend superflue l'installation de contentType dans le JSP.
Ajoutez le code suivant avant d'inclure le JSP :
```
response.setContentType("text/html");
```

Modification des insertions JSP. Dans l'API de portlet standard, les JSP sont insérés à l'aide de la méthode include() d'un répartiteur de requêtes. Dans la méthode d'affichage du portlet, définissez le type de MIME de sortie avant de le transmettre dans la réponse.

Modifiez ce qui suit :



    PortletContext context = getPortletConfig().getContext();
    context.include("/jsp/View.jsp", request, response);

en le remplaçant par :



    response.setContentType("text/html");
    PortletContext context = getPortletConfig().getPortletContext();
    context.getRequestDispatcher("/jsp/View.jsp").include( request, response);

Modification des classes dans lesquelles sont conservées des données utilisateur. Dans l'API de portlet standard, les données utilisateur sont conservées dans un objet PortletPreferences, plutôt que dans l'objet PortletData disponible à l'aide de l'API de portlet HCL. Nous attirons votre attention sur les différentes méthodes getter (accesseur) utilisées avec l'objet de requête et les méthodes SET utilisées pour l'objet de données.
Modifiez ce qui suit :
```
        PortletData portData = request.getData();
        portData.setAttribute("userName", userName);
        portData.store();
    
```
en le remplaçant par :
```
        PortletPreferences prefs = request.getPreferences();
        prefs.setValue("userName",request.getParameter("username"));  
        prefs.store();
```
Certaines préférences sont uniquement en lecture seule et ne peuvent être modifiées que par un administrateur. Voir Modification des paramètres de configuration en fonction des préférences pour de plus amples informations.
Modification de la méthode employée pour le codage de l'espace-nom. Par exemple, si le portlet utilise encodeNamespace() pour renvoyer une chaîne unique devant servir de préfixe à un nom de variable JavaScript dans le contenu généré par le portlet, le portlet peut utiliser getNamespace().
Modifiez ce qui suit :
```
        PortletResponse.encodeNamespace()   
    
```
en le remplaçant par :
```
        RenderResponse.getNamespace()
```

Modification de la manière dont les URL de portlet sont générées. Par exemple, la méthode doEdit() d'un portlet peut sauvegarder l'URI en mode édition afin de la passer au JSP. Le portlet doit instancier un objet PortletURL à l'aide de la méthode createRenderURL().

Modifiez ce qui suit :



      // Save URI for the edit page
      PortletURI editURI = response.createURI();
      ...
      // Preserve the edit page URI in the request to make 
      // it accessible by the edit JSP  
      request.setAttribute("editURI", editURI.toString());

en le remplaçant par :



      // Save URI for the edit page
      PortletURL editURL = response.createRenderURL();
      ...
      // Preserve the edit page URI in the request 
      // to make it accessible by the edit JSP  
      request.setAttribute("editURL", editURL.toString());

L'API de portlet standard ne dispose pas de méthode équivalente à createReturnURI(). Si l'URL est destinée à appeler la méthode d'action des portlets, cependant, le portlet doit utiliser la méthode createActionURL().

Modification de la source JSP

Modifiez la bibliothèque des balises au format de balise standard.

Modifiez ce qui suit :



    <%@ taglib uri="/WEB-INF/tld/portlet.tld" prefix="portletAPI" %>

en le remplaçant par :



    <%@ taglib uri="http://java.sun.com/portlet" prefix="portlet" %>

Modification des références aux objets API. Dans l'API de portlet standard, la balise JSP <portlet:defineObjects /> rend les objets RenderRequest, RenderResponse et PortletConfig accessibles aux fichiers JSP. Une fois ce changement effectué, toutes les références à PortletRequest et à PortletResponse de JSP doivent être modifiées en faveur des RenderRequest et RenderResponse correspondants.
Modifiez ce qui suit :
```
    <portletAPI:init /> 
    ...
    <%
    PortletData prefs = portletRequest.getData();
    %>    
```
en le remplaçant par :
```
   <portlet:defineObjects /> 
   ...
   <%
   PortletPreferences prefs = renderRequest.getPreferences();
   %>    
```
Modification des balises JSP utilisées pour le codage de l'espace-nom. Par exemple, si le portlet utilise <portletAPI:encodeNamespace/> pour qualifier de manière unique le nom d'une zone d'entrée de texte, cette balise doit être modifiée comme suit.
Modifiez ce qui suit :
```
   <input name="<portletAPI:encodeNamespace value='name'/>"  type="text" >   
```
en le remplaçant par :
```
   <input name="<portlet:namespace/>name"  type="text" >   
```
Modification de la manière dont les URL de portlet sont générées. Si le JSP de portlet crée une URL vers lui-même, il doit préciser quelle méthode prend le contrôle à l'aide des balises <portlet:actionURL/> ou <portlet:renderURL/>. Tout paramètre transmis à l'URL est spécifié à l'aide de la balise <portlet:param/>.
Modifiez ce qui suit :
```
   <a href="<portletAPI:createURI>
               <portlet:URIParameter name='action' value='search'/>   
            </portlet:createURI>" >
```
en le remplaçant par :
```
   <a href="<portlet:actionURL>
               <portlet:param name='action' value='search'/>
            </portlet:actionURL>" >  
```
Modification des regroupements de ressources. La balise <portletAPI:text/> de l'API de portlet HCL est déconseillée et doit être remplacée dans tous les portlets par l'équivalent JSTL. Voir Utilisation de JSTL dans les JSP de portlet pour plus de détails.
Modifiez ce qui suit :
```
    <portletAPI:text key="my.label" bundle="nls.myproperties"/>  
```
en le remplaçant par :
```
    <fmt:setBundle basename="nls.myproperties"/>
    ...
    <fmt:message key="my.label"/>
```
Modification de la manière dont les ressources sont invoquées à partir du JSP. Si, par exemple, le JSP affiche une image, il doit utiliser la méthode encodeURL() de l'objet de réponse qui convient mais aussi ajouter le chemin de contexte du portlet à partir de la requête.
Modifiez ce qui suit :
```
  <img src='<%= portletResponse.encodeURL("images/photo01.jpg") %>' 
    alt="photo">   
```
en le remplaçant par :
```
<img src='<%= renderResponse.encodeURL(renderRequest.getContextPath() + 
              "/images/photo01.jpg") %>' alt="photo">
```

Modification du descripteur de déploiement de portlet

Les étapes suivantes décrivent certaines des différences entre les descripteurs de déploiement de portlet de l'API de portlet HCL et la spécification de portlet Java. Toutefois, l'ordre des éléments du descripteur de portlet standard est important et appliqué de manière stricte durant ce déploiement. Vous devez utiliser un outil (Rational® Application Developer, par exemple) effectuant la validation lorsque vous développez le descripteur de déploiement de portlet.

Supprimez la déclaration DOCTYPE. Le descripteur de portlet des portlets standard utilise un schéma XML, qui est ajouté à la prochaine étape.
Supprimez ce qui suit :
```
<!DOCTYPE portlet-app-def PUBLIC "-//IBM//DTD Portlet Application 1.1//EN"
              "portlet_1.1.dtd "> 
```
Supprimez l'élément <portlet-app-def/>. L'élément de premier niveau du descripteur de portlet standard est <portlet-app/>.
Supprimez le code suivant :
```
    <portlet-app-def>    
    ....
    </portlet-app-def>
```

Modifiez l'élément <portlet-app/>.

Ajoutez la définition de schéma et les déclarations des espaces de noms.
Supprimez les attributs minor-version et major-version.
Définissez l'attribut version sur la valeur correspondant à la version de la spécification de portlet Java requise. Actuellement, la version 1.0 est la seule prise en charge.
Modifiez l'attribut uid en id.

Remplacez ce code :



   <portlet-app uid="com.mycompany.samples.MyPortletApp.001c" 
                major-version="1" minor-version="0">

par le code suivant :



<portlet-app 
     xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd" 
     version="1.0" 
     id="com.mycompany.samples.MyPortletApp.001c"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation=
        "http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd 
         http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">

Supprimez tous les éléments <concrete-portlet-app/> et leur contenu. Sauvegardez toutes les informations nécessaires, telle que les paramètres de configuration et les définitions linguistiques, afin de les utiliser dans la définition de portlet.

Modifiez l'élément <portlet/>. Supprimez les attributs href, minor-version et major-version.

Remplacez ce code :



   <portlet id="com.mycompany.samples.MyPortlet.110x" 
            href="WEB-INF/web.xml#com.mycompany.samples.MyPortlet.href110x"   
            major-version="1" minor-version="0">

par le code suivant :



   <portlet id="com.mycompany.samples.MyPortlet.110x">

Modifiez la définition de la classe de portlet de web.xml à portlet.xml.

Supprimez ce code du fichier web.xml :



    <servlet id="com.mycompany.samples.MyPortlet.001c">
        <servlet-name>MyPortlet</servlet-name>
        <servlet-class>com.mycompany.samples.MyPortlet</servlet-class>
    </servlet>
    <servlet-mapping 
             id="ServletMapping_com.mycompany.samples.MyPortlet.001c">  
        <servlet-name>MyPortlet</servlet-name>
        <url-pattern>/MyPortlet/*</url-pattern>
    </servlet-mapping>

Ajoutez ce code au fichier portlet.xml :



        <portlet-class>com.mycompany.samples.MyPortlet</portlet-class>

Modifiez la manière dont la mise en cache est définie. Utilisez la valeur <expires/> du descripteur de portlet HCL comme valeur pour l'élément <expiration-cache/> du descripteur standard. Ce dernier ne contient pas d'équivalent de l'élément <shared/>.
Remplacez ce code :
```
    <cache>
       <expires>-1</expires>
       <shared>no</shared>
    </cache> 
```
par le code suivant :
```
    <expiration-cache>-1</expiration-cache>     
```
Modifiez le contenu de l'élément <supports/>.
- Modifiez les marquages pris en charge au profit du type MIME.
- Utilisez l'élément <portlet-mode/>.
Le descripteur de portlet standard vous permet de déclarer uniquement des types MIME. Dans certains cas, deux types de marquages utilisent le même type MIME. Par exemple, les formats HTML et cHTML utilisent tous deux 'text/html' comme type MIME. Pour les portlets standard, HCL Portlet accepte la valeur d'un paramètre d'initialisation wps.markup comme type de marquage.
Remplacez ce code :
```
    <supports>
       <markup name="html">
          <view />
          <edit />
       </markup>
    </supports> 
```
par le code suivant :
```
    <init-param>
       <name>wps.markup</name>
       <value>html,chtml</value>
    </init-param>
    ...
    <supports>
       <mime-type>text/html</mime-type>
       <portlet-mode>VIEW</portlet-mode>   
       <portlet-mode>EDIT</portlet-mode>
    </supports> 
```
Assurez-vous de positionner les paramètres d'initialisation avant l'élément <expiration-cache>.
Suppression des éléments d'état de fenêtre. Les états de fenêtre Normal, Agrandi et Réduit sont gérés par défaut et ne sont pas déclarés dans le descripteur de déploiement de portlet standard.
Supprimez ce qui suit :
```
    <allows>
       <maximized/>   
       <minimized/>
    </allows> 
```

Modifiez les paramètres de configuration sur les préférences. Dans le descripteur de portlet standard, les utilisateurs peuvent modifier les préférences dans n'importe lequel des modes classiques mais ils peuvent aussi les déclarer comme étant en lecture seule et modifiables uniquement par un administrateur.

Modifiez ce qui suit :



          <config-param>
              <param-name>Location</param-name>
              <param-value>Antartica</param-value>
          </config-param>

en le remplaçant par :



      <portlet-preferences>
            <preference>
                <name>Location</name>
                <value>Antartica</value>
                <read-only>true</read-only>
            </preference>
      </portlet-preferences>

Modification des paramètres localisés.
1. Supprimez l'élément <default-locale/>. Dans le descripteur de portlet standard, le premier environnement local figurant dans le descripteur est l'élément par défaut. Si aucun environnement local n'est défini, l'anglais est utilisé par défaut.
2. Créez, pour chaque langue prise en charge, des regroupements de ressources contenant le titre, le titre abrégé et les mots clés du portlet. Utilisez les noms de paramètres suivants :
```
    javax.portlet.title = My Portlet Title
    javax.portlet.short-title = Title
    javax.portlet.keywords = portlets, JSR 168, portal
  
```
3. Déclarez le regroupement de ressources dans le descripteur de portlet comme indiqué dans l'exemple suivant.
```
    <resource-bundle>nls.MyPortlet</resource-bundle>
  
```
  Dans cet exemple, le regroupement de ressources par défaut MyPortlet.properties se situe dans le sous-répertoire /WEB-INF/nls du fichier WAR et tous les regroupements de ressources propres à l'environnement local associent ce dernier au nom de fichier (par exemple, MyPortlet_ja.properties pour le japonais).
4. Déclarez chaque environnement local pris en charge comme dans l'exemple suivant :
```
    <supported-locale>en</supported-locale>
    <supported-locale>de</supported-locale>  

  
```
5. Définissez les valeurs localisées pour la description de portlet et le nom affiché comme dans l'exemple suivant.
```
<description xml:lang="EN">
   English description
</description>
<display-name xml:lang="EN">
   English display name
</display>-name>
<description xml:lang="DE">
   German description
</description>
<display-name xml:lang="DE">
   German display name
</display>-name>

  
```
  Remarque : Le nom affiché doit être défini pour des questions de compatibilité. Cependant, il n'est actuellement pas utilisé par HCL Portal.

Conversion de portlets HCL Digital Experience utilisant la structure de portlets Struts

Les versions existantes de la structure de portlet Struts prenaient en charge l'API du conteneur de portail HCL ou le conteneur existant. Cette édition utilise une version plus récente de la structure de portlet Struts qui prend en charge le conteneur de portlet standard. Cette édition sera encore fournie avec une version prenant en charge le conteneur existant et une nouvelle version pour le conteneur standard. La structure de portlet Struts est toujours fournie en tant que fichiers war d'exemple pouvant être utilisés pour la création de l'application Struts. Les fichiers war de chaque conteneur peuvent être différenciés par leurs noms. Les exemples SPFLegacy prennent en charge le conteneur existant, et les exemples SPFStandard prennent en charge le conteneur standard. Le fichier SPFLegacyBlank.war est le point de départ pour les applications Struts pour le conteneur existant, et SPFStandardBlank est le point de départ pour les applications Struts pour le conteneur standard.

Structure de portlet Struts pour le conteneur existant

Le fichier SPFLegacyBlank.war contient les fichiers à inclure dans l'application Struts. Les répertoires concernés sont WEB-INF/lib et WEB-INF/tld. Voici la liste des bibliothèques à utiliser dans l'application depuis le répertoire WEB-INF/lib :

PortalStruts.jar
PortalStrutsCommon.jar
PortalStrutsTags.jar
StrutsUpdateForPortal.jar
wp.struts-commons-logging.jar
commons-beanutils.jar
commons-collections.jar
commons-fileupload.jar
commons-lang.jar
commons-validator.jar
struts-legacy.jar
struts.jar

Les fichiers du répertoire TLD sont

struts-bean.tld
struts-chtml.tld
struts-html.tld
struts-logic.tld
struts-nested.tld
struts-portal-html.tld
struts-portal-wml.tld
struts-template.tld
struts-tiles.tld
struts-wml.tld

Fichiers communs aux conteneurs de portlet standard et HCL

Les fichiers suivants sont les fichiers binaires Jakarta Struts 1.1, identiques dans les versions standard et existantes de la structure de portlet Struts :

commons-beanutils.jar
commons-collections.jar
commons-fileupload.jar
commons-lang.jar
commons-validator.jar
struts-legacy.jar
struts.jar

Les fichiers suivants issus du répertoire TLD sont identiques pour les deux conteneurs. Cela est susceptible de changer dans les éditions futures. Il est donc vivement conseillé d'utiliser les fichiers de l'obturateur pour le conteneur souhaité.

struts-bean.tld
struts-chtml.tld
struts-html.tld
struts-logic.tld
struts-nested.tld
struts-portal-html.tld
struts-portal-wml.tld
struts-template.tld
struts-tiles.tld
struts-wml.tld

Conversion en la version standard de la structure de portlet Struts depuis les versions précédentes de la structure de portlet Struts

La conversion depuis la version existante de la structure de portlet Struts vers les versions standard commence par la mise à jour des fichiers jar et des TLD fournis avec le fichier SPFStandardBlank.war.

Voici une liste des fichiers qui devraient être mis à jour dans le répertoire WEB-INF/lib de l'application :

wp.struts.standard.framework.jar
PortalStrutsCommon.jar
PortalStrutsTags.jar
StrutsUpdateForPortal.jar
wp.struts-commons-logging.jar
commons-beanutils.jar
commons-collections.jar
commons-fileupload.jar
commons-lang.jar
commons-validator.jar
struts-legacy.jar
struts.jar
commons-digester.jar
commons-logging.jar
jakarta-oro.jar

Voici une liste des fichiers TLD qui devraient être mis à jour avec les TLD du fichier SPFStandardBlank.war :

struts-bean.tld
struts-chtml.tld
struts-html.tld
struts-logic.tld
struts-nested.tld
struts-portal-html.tld
struts-portal-wml.tld
struts-template.tld
struts-tiles.tld
struts-wml.tld

Le fichier PortalStruts.jar n'est requis que sur le conteneur HCL et doit être supprimé :

Descripteur de déploiement Web

Le conteneur standard nécessite un descripteur de déploiement Web car l'application est groupée sous la forme d'un fichier war. Toutefois, la plupart des paramètres d'initialisation sont désormais configurés à l'aide du descripteur de déploiement de portlet.

Retirez la classe de servlet du descripteur de déploiement Web. La classe de servlet n'est plus utilisée pour spécifier la classe de portlet pour l'application dans le conteneur standard. Le portlet est désormais spécifié en tant que classe de portlet dans le descripteur de déploiement de portlet.
Déplacez les paramètres init du descripteur de déploiement Web vers le descripteur de déploiement de portlet. Comme la classe de portlet est définie dans le descripteur de déploiement de portlet, les paramètres init sont également spécifiés dans le descripteur de déploiement de portlet. Remarquez que les paramètres init sont spécifiés en tant que nom et valeur dans le descripteur de déploiement de portlet, pas en tant que nom de paramètre et valeur de paramètre comme ils sont nommés dans le descripteur de déploiement Web.
Les éléments taglib restent dans le descripteur de déploiement Web. Aucune modification n'est nécessaire.
Les éléments du fichier welcome restent dans le descripteur de déploiement Web. Aucune modification n'est nécessaire.

Descripteur de déploiement de portlet

La définition du descripteur de déploiement de portlet pour le conteneur standard est différente de celle du conteneur existant. Certaines modifications sont nécessaires pour l'exemple converti à déployer dans le conteneur standard. Le centre d'aide contient des informations détaillées concernant la sémantique du descripteur de déploiement de portlet pour le conteneur standard.

Le conteneur standard introduit l'élément de classe de portlet pour spécifier la classe du portlet. La classe de portlet pour la structure de portlet Struts est com.ibm.portal.struts.portlet.StrutsPortlet.
Les paramètres init pour le portlet sont définis dans le descripteur de déploiement de portlet. Les paramètres d'initialisation doivent être convertis depuis le descripteur de déploiement Web.
Le conteneur standard n'a pas la séparation concrète et abstraite dans le descripteur de déploiement de portlet. L'élément portlet définit les modes pris en charge et les préférences du portlet.
La structure de portlet Struts n'utilise plus de filtre de portlet. Le paramètre init FilterChain ne doit pas être converti.

Fichier de configuration Struts

La structure de portlet Struts définit le processeur de requêtes qui doit être configuré dans le fichier de configuration Struts. L'attribut du contrôleur processClass doit être converti dans la valeur suivante pour être déployé sur le conteneur standard : <controller processorClass="com.ibm.portal.struts.portlet.WpRequestProcessor"> Si l'application Struts utilise le processeur de requêtes Struts qui prend en charge Tiles, le plug-in Struts doit également être converti : <plug-in className="com.ibm.portal.struts.plugins.WpTilesPlugin">

Action Struts

La classe d'action Struts est transférée à un objet HttpServletRequest, de telle sorte que l'application peut ne pas avoir de dépendance sur le conteneur de portail. Toutefois, de nombreuses applications utilisent PortletApiUtils pour obtenir l'interface et la requête de portlet directement avec l'API de portlet. Si tel est le cas, l'application doit remplacer les interfaces org.apache.jetspeed avec les interfaces javax.portlet interfaces équivalentes. Les nouvelles interfaces sont présentées dans le centre d'aide.

Remarque : L'exemple suivant illustre la modification pour obtenir l'objet PortletApiUtils :

Nouveau : PortletApiUtils portletUtils = PortletApiUtils.getInstance();
Ancien : PortletApiUtils portletUtils = PortletApiUtils.getUtilsInstance();

StrutsPortlet

La classe com.ibm.wps.portlets.struts.WpsStrutsPortlet pour le conteneur existant étendait la classe PortletAdapter. L'application Struts utilisant la structure de portlet Struts a pu être personnalisée en étendant la classe WpsStrutsPortlet. Dans ce cas, ces modifications doivent être appliquées pour le conteneur standard. La classe com.ibm.portal.struts.portlet.StrutsPortlet pour le conteneur standard étend le portlet générique du conteneur standard.

Processeur de requêtes

La classe com.ibm.wps.portlets.struts.WpsRequestProcessor pour le conteneur existant a pu être étendue pour personnaliser le traitement. La classe Request Processor pour le conteneur standard est com.ibm.portal.struts.portlet.WpRequestProcessor. Si les interfaces existantes ont été utilisées pour les personnalisations, ces changements doivent être convertis en interfaces standard.