-<page:page __file="25d9e34651a528f0599ed749b35701fc" __status="-1" xmlns:paloose="http://www.paloose.org/schemas/Paloose/1.0" xmlns:link="http://www.hsfr.org.uk/Schema/Link" xmlns:list="http://www.hsfr.org.uk/Schema/List" xmlns:page="http://www.hsfr.org.uk/Schema/Page" xmlns:t="http://www.hsfr.org.uk/Schema/Text" xmlns:i18n="http://apache.org/cocoon/i18n/2.1" xmlns:xi="http://www.w3.org/2001/XInclude">

-<page:meta>

<page:title>Paloose — FAQ</page:title>

</page:meta>

-<page:content>

<t:heading level="1">Frequently Asked Questions</t:heading>

-<t:group label="faqEntry">

<t:heading level="2" id="about">About the author</t:heading>

-<t:p>

The Paloose project is currently run by me,

. I recently retired after a (too) long career designing (amongst other things) computer hardware and software; I am now a professional music engraver, something I did as a hobby during my working life. I started Paloose to keep myself amused and to support my other interest,

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="palooseName">What's with the name?</t:heading>

-<t:p>

The original name I chose was "Papoose"; in the UK this is defined as "

<t:emph degree="weak">... a type of bag used to carry a child on the back</t:emph>

". Unfortunately it does not seem have this meaning in the US, indeed, with some people, it is a derogatory term. However, it occurred to me that a simple change of letter would give "Paloose", which is another term for the Appaloosa horse, something dear to my heart as, until recently, I was privileged to have and ride one of my own.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="palooseFuture">What future for Paloose?</t:heading>

-<t:p>

Paloose is released under the GPL-3. If anyone wishes to get involved then please

me. I intend to use it for all my small sites and will continue to do so until

<t:index entry="Cocoon"/>

Cocoon is supported by the smaller ISPs that I use. It is also interesting (and slightly depressing) that the latest

<t:index entry="Cocoon"/>

Cocoon does not seem to be as easy to use as

<t:index entry="Cocoon"/>

Cocoon Version 2.1.x. I use this latter version on my local servers and have no plans (yet) to upgrade to

<t:index entry="Cocoon"/>

Cocoon Version 2.2 or later. While I am prepared to admit that this is my problem, I know others who have had the same experience. As a result perhaps Paloose will fulfil the requirements of those who want a quick

<t:index entry="Cocoon"/>

Cocoon-like engine for their small Web sites.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="licence">What Licence is Paloose issued under?</t:heading>

<t:index entry="licence"/>

<t:index entry="Paloose!licence"/>

<t:p>Paloose is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. </t:p>

<t:p>This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. </t:p>

-<t:p>

You should have received a copy of the GNU General Public License along with Paloose when you downloaded it. If not, see

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="palooseToDo">What facilities do you intend to add to Paloose?</t:heading>

-<t:p>

This is quite a difficult question as I have limited time and am not trying to do a complete

<t:index entry="Cocoon"/>

Cocoon implementation in PHP5 — a pointless exercise anyway. Now that I have added a simple (limited) data caching scheme to the pipeline all of what I intended to add is complete. I am gradually refining the code and improving the documentation and comments. I am happy to look at anything that users suggest — just EMAIL me at

and may add a further wrapper for Content Management Systems such as Joomla!.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="palooseLogo">Can I use the Paloose logo on my site?</t:heading>

-<t:p>

Yes please. I suggest the following

or the

. Scale it as you feel fit.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="PDF generation"/>

<t:index entry="FOP transformer"/>

<t:index entry="LaTeX@\LaTeX"/>

<t:heading level="2" id="fopSupport">Do you intend to add PDF support via FOP?</t:heading>

<t:p>The short answer to this is: no. It would mean writing a complete XSL-fo system in PHP5 which is something I really do not have the time (or inclination) to do. If you really want to produce PDF output then I suggest that you write a suitable XML to LaTeX transformer and then run that to get PDF.</t:p>

<t:p>I wrote a transformer (XML to LaTeX) to produce a paper PDF copy of this Paloose documentation Web site which runs within an Ant build file. It is not particularly difficult to generate XML to LaTeX transformers, although obviously it requires a knowledge of LaTeX. I would be happy to help anyone who has a problem.</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="systems">What systems will it run on?</t:heading>

<t:p>Basically any system that will run PHP5. Currently the list is Mac OS-X, Linux, and other similar Unix systems. I also know of a system based on Apache 2.0/PHP5 on Windows Server 2003.</t:p>

</t:group>

-<t:group label="faqEntry">

-<t:heading level="2" id="SAXvDOM">

Why don't you use SAX, like

<t:index entry="Cocoon"/>

Cocoon, instead of DOM?

</t:heading>

-<t:p>

I thought about this quite hard initially. I concluded that using a DOM approach was far simpler. It has the penalty of being slower but Paloose is only intended for small volume/traffic sites and ultimate performance is not such an issue. I have seen no reason to revise this decision in the light of typical site usage. Changing to a SAX approach would mean a major code change and I really do not have the time at present as my Music Publishing venture (

) and my horses have more call on my time.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="performance">How can I improve the performance of Paloose?</t:heading>

-<t:p>

Assuming that you are already using the caching system and want more speed, it is possible, but at the expense of a little effort (and possible obscurity), to tailor the Paloose code and your own sitemaps and XSL. The implications and method are described on a

in more detail.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="caching!configure"/>

<t:heading level="2" id="caching">What about caching in Paloose?</t:heading>

-<t:p>

I have done considerable work on various ways of caching within Paloose and versions after 1.3.0 use pipeline data caching on certain generators and transformers. I confess that I am in a quandry over this as the gains from using a cache seem to be minimal and not really worth the effort except in some key cases — see

for more on this. It is not the end of the story, but more performance increases will probably come from elsewhere.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="CForms"/>

<t:index entry="Javascript"/>

<t:index entry="flows"/>

<t:index entry="forms"/>

<t:heading level="2" id="formsBackground">Why did you not use CForms and JavaScript for flows?</t:heading>

-<t:p>

It is useful to provide some background to some of the decisions that I made for flows and forms. This is where Paloose diverges from

<t:index entry="Cocoon"/>

Cocoon most. The latter is based on Java and Javascript which was not available to me (conceptually, not practically, as Paloose is based solely on PHP5). Thus I had to base what I did on a pure PHP approach while including the concepts of

<t:index entry="Cocoon"/>

Cocoon flows and forms. I made several false starts which arose from several design problems:

</t:p>

-<list:list type="unordered">

<list:item>How to store the information at each point of the flow?</list:item>

<list:item>Which form template to use (CForms, XForms etc.)?</list:item>

<list:item>How to allow forward and back (continuations) in the forms?</list:item>

</list:list>

<t:index entry="Paloose!forms"/>

<t:index entry="PForms"/>

-<t:p>

All of these problems seemed intractable at first with decisions made about one influencing, detrimentally, a decision made elsewhere. Mirroring the

<t:index entry="Cocoon"/>

Cocoon forms template,

was initially desirable for commonality with

<t:index entry="Cocoon"/>

Cocoon. But it soon became apparent that this was going to make the whole approach far too complicated for what I wanted. Much code was wasted in exploring this but I believe it was the right decision. In the end I based the Paloose forms (

) on the JXForms that older version of

<t:index entry="Cocoon"/>

Cocoon used. (I had produced some sites with this in the past so I was reasonably familiar with it).

is not radically different from JXForms but it does not slavishly follow the latter. I believe that

is suitable for the restrictions I had set on Paloose and, as I have said elsewhere, if you have a site that requires all the facilities of

then you should probably be using

<t:index entry="Cocoon"/>

Cocoon anyway.

</t:p>

-<t:p>

Once I had settled on

there was the problem of how to implement the flow script, which in

<t:index entry="Cocoon"/>

Cocoon uses Javascript. The

<t:index entry="Cocoon"/>

Cocoon approach is to take a "snapshot" of the Javascript engine (a simplistic way of describing it) in order to maintain continuity between client requests. I was unable to find a sensible way of doing this with PHP5 (which does not mean to say that one does not exist). So I had to find a means of providing the user with a simple method of continuations based solely on a PHP5 approach. I believe I have

while keeping to the spirit of

<t:index entry="Cocoon"/>

Cocoon.

</t:p>

-<t:p>

All these solutions, however successful, have made me diverge from the strict

<t:index entry="Cocoon"/>

Cocoon approach so please read the documentation very carefully.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="siteDesigns">Who designs your own sites that use Paloose?</t:heading>

-<t:p>

These have been done by my son

who is the GUI art director for

and I am very grateful to him for the help he has given me in their design. However I have to take the blame for the Paloose site: any good points are due to him, the bad ones are all mine.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="Paloose!example sites"/>

<t:heading level="2" id="exampleSites">Are there examples of sites that use Paloose?</t:heading>

<t:heading level="3">My sites</t:heading>

-<list:list type="unordered">

-<list:item>

</list:item>

-<list:item>

</list:item>

-<list:item>

</list:item>

-<list:item>

</list:item>

</list:list>

<t:heading level="3">Others</t:heading>

-<list:list type="unordered">

-<list:item>

</list:item>

-<list:item>

</list:item>

</list:list>

</t:group>

-<t:group label="faqEntry">

<t:index entry="PForms! and SQL"/>

<t:heading level="2" id="paloose2Cocoon">How do I generate multiple selection lists in PForms from SQL entries?</t:heading>

-<t:p>

The addition of a simple transformer is all that is necessary; it is explained in more detail on

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="Paloose!porting to Cocoon"/>

-<t:heading level="2" id="paloose2Cocoon">

How do I port Paloose Sites to

<t:index entry="Cocoon"/>

Cocoon?

</t:heading>

-<t:p>

This is very easy with the only major change being the sitemap components. See this

for more information. But beware, the Password, Gallery and PageHit transformers will not work unless you write your own in Java. I have not needed to yet, but when I do I will post them on this site.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="Cocoon!porting to Paloose"/>

-<t:heading level="2" id="cocoon2Paloose">

How do I port

<t:index entry="Cocoon"/>

Cocoon Sites to Paloose?

</t:heading>

-<t:p>

This is really just the reverse of the above. The only issue might be one of performance so it is worth bearing in mind that Paloose is obviously slower than

<t:index entry="Cocoon"/>

Cocoon.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="writing components"/>

<t:heading level="2" id="writeComponents">How do I write Components for Paloose?</t:heading>

-<t:p>

I have written an example component

that is a "template" for writing generator, transformer and serializer components; also included is an example exceptions class used by the template. Current releases of Paloose include it in the folder

<t:code type="dir">resources/templates/</t:code>

. Also have a look at the various existing components that make up Paloose.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="iPhone"/>

<t:heading level="2" id="iPhhoneSupport">Do you have any support for iPhone?</t:heading>

-<t:p>

Yes. The

can detect the iPhone to allow separate pipelines to be run.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="errors!page not found \dots"/>

<t:index entry="RewriteRule"/>

<t:heading level="2" id="htaccessProblem">Help! I have tried everything but I am still getting page not found.</t:heading>

-<t:p>

The usual problem here that you have not set up the

<t:index entry=".htaccess"/>

<t:code type="dir">.htaccess</t:code>

file up correctly. Remember that Apache will serve all your requests, including ones that are destined for Paloose unless you tell it otherwise. For example if you want requests for, say,

<t:code type="dir">http://<hostname>/<site-path>/file.asm</t:code>

, to be processed by Paloose then you would have to add the following line into your

<t:index entry=".htaccess"/>

<t:code type="dir">.htaccess</t:code>

file:

</t:p>

<t:verbatim> RewriteRule (.+)\.asm paloose.php?url=$1.asm [L,qsappend]</t:verbatim>

<t:p>Remember though that the one type of file extension that this method does not handle is PHP, so putting</t:p>

<t:verbatim> RewriteRule (.+)\.php paloose.php?url=$1.php [L,qsappend]</t:verbatim>

-<t:p>

in the

<t:index entry=".htaccess"/>

<t:code type="dir">.htaccess</t:code>

file will cause an infinite loop.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="errors!Class 'XsltProcessor' not found"/>

<t:heading level="2" id="XsltProcessorNotFound">Help! Why am I getting "Class 'XsltProcessor' not found" errors</t:heading>

<t:p>99% of the time this shows that you are running PHP5 without the XML/XSL support that there should be. Try recompiling PHP5 with the following configuration parameters included </t:p>

<t:verbatim>--with-xml --with-libxml-dir=<dir path> --with-xsl</t:verbatim>

</t:group>

-<t:group label="faqEntry">

<t:index entry="errors!Parse error: syntax error, unexpected '=', \dots"/>

<t:index entry="PHP4"/>

<t:heading level="2" id="noPHP5">Help! Why am I getting "Parse error: syntax error, unexpected '=', expecting '(' in /../../paloose/lib/Paloose.php on line xx" errors</t:heading>

-<t:p>

This means you are still running PHP4. You need to run PHP5. Speak to your ISP to provide PHP5. The other reason may be that your

<t:index entry=".htaccess"/>

<t:code type="dir">.htaccess</t:code>

file has not been set properly to use PHP5.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="errors!Input file not found"/>

<t:heading level="2" id="noHtaccess">Help! Why am I getting "Input file not found" as the only browser output?</t:heading>

-<t:p>

See

-<link:link type="ref" ref="htaccessProblem">

FAQ entry about the

<t:index entry=".htaccess"/>

<t:code type="dir">.htaccess</t:code>

file

</link:link>

, this is the usual problem. Also make sure that you do not overwrite a system

<t:index entry=".htaccess"/>

<t:code type="dir">.htaccess</t:code>

that is required. That is why it is best to have your site in a separate folder.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="documentation schemas"/>

<t:heading level="2" id="ppSchemas">Are there schemas for the XML used in this site?</t:heading>

-<t:p>

Yes the basic schema is written in

. They are not an essential to running Paloose or understanding, they are merely given out of interest; although I would urge the use of schemas to reduce errors in your XML files. The primary page schema is

. They are pretty versions of the raw RELAX NG which are easier to read. If anyone would like a copy of the transforms necessary to produce the pretty-printed version please

and I will consider putting them up as a download.

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:index entry="sitemap!schemas"/>

<t:heading level="2" id="sitemapSchemas">Why do you not use schemas for the sitemaps?</t:heading>

-<t:p>

This is a fairly contentious subject. Sitemaps are built in such expandable form that producing a schema in something like

is very difficult — they simply do not have a rich enough structure to do what I think is necessary without having to use Schematron additions. The closest that I got to producing one used

. I wrote an extensible set of schemas which worked fine, but are now sadly out of date. I also produced schemas for Dublin Core, Jakarta Ant and RDF (although RDF is a major problem because it is impossible to write a universal validating XML schema for it — it ain't the right sort of grammar and the current 2004 specification for RDF is flawed), all of which can be found on the

home page. DSD-2 is the best schema language we never had, sad ....

</t:p>

</t:group>

-<t:group label="faqEntry">

<t:heading level="2" id="techTrivia">Technical Trivia</t:heading>

<t:p>The code that builds Paloose is a little rough and ready in places. This is my first PHP program (other than the odd embedded line within HTML) and it shows. I am more used to program in strongly typed languages having had a lifetime using Algol, Coral, Algol68, Pascal, Java at al; as well as more obscure offerings such as OmniMark, ELLA, Abel, TeX. I have programmed in Perl for many years and so PHP was not a wholly new experience. I am sure that I have used 10 lines in places where PHP5 would let me use one; never mind — it suffices, the future will refine the code. </t:p>

</t:group>

</page:content>

</page:page>