Yes but only if you have one application deployed on that server and you are just using tomcat, without apache. Pustefix uses a virtual host for every application deployed. However you can use the <serveralias/> option from the project.xml.in file. Let's say that the ip of the server is 111.222.333.444. You can use something like <serveralias>111.222.333.444</serveralias> then redeploy the application.

Now you can access your favourite pustefix application via http://111.222.333.444:8080/xml/config.

You can add those in the <properties/> section of your servlet configuration file. For example at the end of your app.conf.xml you can have something like:

<properties>
  <prop name="jdbc_conn_string">jdbc:mysql://foo/bar</prop>
</properties>

If your project is named foo and your images are in foo/img then, in project.xml.in you should have something like <passthrough>foo/img</passthrough>. This is for Apache to generate the necessary alias lines so the requests are mapped correctly.

Yes. While in development phase, you can use the <pfx:editconsole/> tag anywhere in your page. It will display a link which opens the editor and a link which shows the raw runtime XML used to generate the page.

Yes, they can be found in the projects/.cache directory.

Check if you have a <pfx:forminput> around it on the page.

You can achieve i18n by using something like

<part name="username">
  <theme name="default">
    <lang name="default">some text</lang>
    <lang name="de_DE">etwas text</lang>
  </theme>
</part>

and when you include this part in your page, the correct language will be selected at runtime by pustefix. To change the language, you can use the request parameter __language. For example requesting your page with __language=de will display the text under <lang name="de">. You can also change the language programatically using the setLanguage() method from the Context.

No, you can declare any arbitrary page as final, it doesn't have to be in the same pageflow where it is used.

If you use a new document, the pageflow will usually continue without displaying the page while if you use super.getDocument, the pageflow will stop on this page and on all the ContextResources that are declared in this pagerequest will be called insertStatus().

Basically, when using a new document, descending from StaticState doesn't really make sense, as you don't use anything interesting from this class - descending from StateImpl directly would be just as good.

StateImpl is abstract and does not implement the getDocument() method. StaticState implements the getDocument() method, calls insertStatus of all the ContextResources defined for this pagerequest and stops the pageflow.

The prerequisitesMet() method from the IHandler interface is used by pustefix to determine which HTML links should be active or not. This method is called once per each request, on all IHandlers, from all pageflows. Thus, this method should be very fast or else the whole system would be slowed down.

Yes, you can extend an interface and add some more parameters to it or override older definitions, instead of writing a new one from scratch. You can also assign a new handler. Use the extends attribute of the <interface/> tag.

You just have to exchange some Javascript libraries. The stub implementations are compatible, so you don't have to modify your Javascript code.

Replace the SOAP libraries

<script type="text/javascript" src="/core/script/xmlRequest.js"></script>
<script type="text/javascript" src="/core/script/webservice.js"></script>
<script type="text/javascript" src="/xml/wsscript/MyService.js"></script>

by the according JSON libraries (the build-time generated stub is replaced by its dynamic counterpart using the pfx:wsscript tag)

<script type="text/javascript" src="/core/script/httpRequest.js"></script>
<script type="text/javascript" src="/core/script/webservice_json.js"></script>
<pfx:wsscript name="MyService"/>

Simply add, as an additional parameter, a function reference to the call of the appropriate webservice-object's method call:

webserviceObject.getRemoteSearchResult(queryString, callbackFunction);

Or create the webservice with an object reference as argument (whose methods will be called back automatically):

var search={
   getRemoteSearchResult: function(result,requestid,exception) {
      ...
   }
}
var service=new WS_SearchService(search);
service.getRemoteSearchResult(queryString);

While synchronous calls are blocking and only can be made sequentially, asynchronous calls can be made simultaneously and they can return in undetermined order. Using a requestID the application can control or manage the order of the returning calls.

The session type servlet indicates that the service request needs a valid Pustefix/HTTP session (webservices which need to access ContextResources have to be of this type). Type none indicates that the service needs no session.

A webservice gets access to the Context or ContextResources by deriving from de.schlund.pfixcore.webservice.AbstractService and thus inheriting its access methods getContext() and getContextResource().

None. All necessary libraries come bundled with Pustefix.

Using pfx:wsscript you can request multiple stubs by specifying the servicenames as a whitespace-separated list.

<pfx:wsscript name="service1 service2 service3"/>

	Be careful with the SOAP client
	Never include the SOAP implementation code twice on a page! leads to strange "serializer not found exception"