What has changed when updating from 0.12 to 0.13 that requires changes in your projects

  • the meaning of the "mode" attribute in pfx:button has changed: The "desc" value has been removed, as it was too esoteric. The "force" value now also creates a link even in the case that the target page is not accessible.

  • a pageflow is no longer always set. Once a pageflow has been set all the time (after the first request), even when this flow wasn't active. Now we only store a pageflow if one is really active, which can be either because of a direct request to set one (via UI, configuration...) or because a page is selected that is part of the flow. The consequence is that also the (runtime) xsl variable $pageflow may not always be set.
  • The Context method flowIsRunning() has been removed. Instead, there is a method in the base class StateImpl called isPageFlowRunning(Context) similar to the well known isDirectTrigger(...) and isSubmitTrigger(...) methods.
  • There is a very small change in the way the target page is handled in case of a "startwithflow" request. In the old logic, if neither any step of the flow under consideration needed data nor the target page was part of the steps being checked, the target page was used instead of any final page the pageflow may have defined. Now this has changed slightly - if the pageflow itself defines an (accessible) final page, this is used. Only if this is not the case, the target page is the last resort and is used as if it was the final page.
  • iwrapper groups are no longer. This in itself shouldn't be problem for most users, but also the format of the output of the wrapperstatus in the XML tree has changed. It was once something like /formresult/iwrappergroups/group/interface and it is now just /formresult/wrapperstatus/wrapper (there is also the change of going away from the stupid name "interface" when in fact we reference a wrapper). You need to check you XSLT if you have selectors on the status of the wrappers/handlers on the page.
  • The pageflow system will no longer skip the current page in the process of determining the next page to follow.
    You will need to change instances in your pageflows, where a page still return true on needsData(), so the pageflow will not just stop again on the same page after you have submitted data. There is actually some help in the pustefix-servlet.log log file from version 0.12.x: Whenever the pageflow skipped over a "current" page in the pageflow, that would have returned true from needsData(), the system wrote a line in the log file:
    SKIPPEDWOULDSTOP:<hostname>|<page name>|<pageflow name>

    If you fix your application under 0.12 so that you don't get this entry in the log file anymore, you will also have no problem with 0.13.
  • The continue="true" attribute on the wrapper definition in the servlet config file (the interface tag below the input child tag of the pagerequest configuration) has been removed. This is, because now every request will continue with the pageflow process as long as no error happened during the submit. This is the same effect as if every single wrapper has the continue attribute set to true in a 0.12 environment. Now in an 0.13 environment, if you want to stop on the same page even after a successful submit, you have to tell the system via the forcestop="true" attribute of <pfx:button> or <pfx:xinp type="submit|image"> on the user interface. Unfortunately there is no automated way to change the configuration for this, you have to look at each situation and pageflow and check if you have to add a manual stop to the request. The good thing is, that like above we implemented a log message that will log each instance when the pageflow stops at the current page because of this situation. The log message looks like:
    CONTAINERWOULDSTOP:<hostname>|<page name>

    If you fix your application under 0.12 so that you don't get this entry in the log file anymore, you should be quite a lot safer for 0.13, too.
  • The alwaysretrieve attribute on the wrapper definition is gone. Again, we changed this to become part of the frontend. See #23 and #12 for explanations and alternatives around this problem. Again no automated help for upgrading, but the problem shouldn't be that big, because alwaysretrieve wasn't used that often.
  • The old authentication mechanism (using authinterface/DefaultAuthIWrapperState/...) was removed. The role-based authentication mechanism has to be used instead. Changing to the new mechanism requires: configuration changes (use DefaultIWrapperState, normal <input> elements, define roles - at least AUTHORIZED/UNAUTHORIZED, assign roles to pages), code changes (set roles within LoginHandlers, revoke roles within LogoutHandlers).
  • The new authentication mechanism has slightly changed: The type attribute for login forms now has to be set to auth for role-based authentication too, no more roleauth, because there's only one mechanism. The hidden parameter of such forms now is named __sendingauthdata instead of __roleauth because there's no collision of the two authentication mechanisms any more and __sendingauthdata is already well known.
  • The webservice functionality has been split-off from the core. The standard distribution now contains four JARs, you have to decide which are required in your project that is upgraded to 0.13.x depending on the features you are using.
    • pfixcore-VERSION.jar
    • pustefix-webservices-core-VERSION.jar
    • pustefix-webservices-jaxws-VERSION.jar
    • pustefix-webservices-jsonws-VERSION.jar
  • The webservice default protocol was changed from SOAP to JSONWS, you should test if your webservices still work as expected. If you want to use SOAP, it's required to annotate the webservice implementation classes with a @javax.jws.WebService annotation (because JAXWS requires this annotation and the new Pustefix version doesn't generate proxy classes any more, but uses cglib based proxies at runtime, which don't allow adding the annotation automatically).
  • The central StatusCodeLib will be replaced by mulitple, module-specific, StatusCode constant classes, i.e. Pustefix now provides its own statuscode constant classes CoreStatusCodes and EditorStatusCodes, which should be used instead. Optionally you still can create a common StatusCodeLib class (by creating a statuscodeinfo.xml file referencing all your statusmessage files). But it's recommended to use the new CoreStatusCodes constant class which comes as part of the pfixcore jar (the referenced statuscodes can be edited in projects/core-override/dyntxt). You will have to move existing translations for core statuscodes from projects/common/dyntxt/statusmessages-core-merged.xml to projects/core-override/dyntxt/statusmessages-core-merged.xml and statusmessages-editor-merged.xml (notice that the statuscode names have changed: they aren't prefixed any more because the package name as namespace is sufficient). You also have to adapt references to core statuscodes in .iwrp files.
  • The propfiles target now is optional. It isn't automatically called by the build process any more, but you still can call it from your build.xml. You should check if you still use prop.in files. If they aren't customized you can create standard Java property files instead. If you need customization or like the XML format, you have to add a call to the propfiles target into your build.xml.
  • The stylesheets target now is optional and deprecated. It isn't automatically called by the build process any more. You can still call it from your build.xml, but it will show a deprecation warning. You should check if you still use xsl.in files. If they contain cus:documentation tags you either should replace them by comments or make them top-level elements, so that they are ignored by the XSLT processor.