Hi all,
sorry for my delay. My gmail account somehow skipped all the replies
from my inbox. :-)
Here are the answers for the first bunch of questions.

>> - Crawler for static content generation
>> - Forms (easy create web forms and assistants) & Form Validation
>
> How do you justify the decision to implement forms support *and* static
> generation. We've always been of the opinion that they are mutually
> exclusive. Forrest does support forms, but not out of the box.
> What happens when forms are submitted? Where does the data go?

We have a discussion about this currently.

You can give an external url to your form:
<form action="http://www.piwiframework.de/somescript.php" method="post">
This is useful if you want to include some google boxes in your static site.

If one does static content generation, we assume he doesn't need any
dynamic features. Nothing happens. I mean, if you have PHP installed
on your webserver, why should you use static content generation? If
you need that, you may not need forms at all.

>> I did look at the site and found a demo, but no explanation of what is
> actually happening.
>

Yes, we are lacking of user docs. This is the next big step: explain
everything more in detail. There are more open questions like that one
with forms. We'll try to do that with the next release.

> What validation mechanism do you use? that is how do you define validation
> rules?

You can do it bei declaring a <validator> tag. this tag validates your
field and returns an error if something goes wrong. Look at this:

...
Name: <input name="Name" type="text" size="30" maxlength="30" value="Name" />
<validator class="RequiredFieldValidator" fieldToValidate="Name"
message="Geben Sie einen Namen ein" initialValue="Name" />

This Validator checks if the field is filled.

<input name="Email" type="text" size="30" maxlength="50" />
<validator class="RegularExpressionValidator" fieldToValidate="Email"
pattern="/[\.a-z0-9_-]+@[a-z0-9-]{2,}\.[a-z]{2,4}$/i" message="Geben
Sie eine gültige Email an." />

The above is an regular expression validator.
We have some message-resources functions in PIWI. Later we want to add
optionally a message-key instead of the textmessage.

>> - Internal PIWI-Format has been changed to a subset of XHTML
>
> Cool - that was the big problem with your previous implementation (for me at
> least). A move to XHTML means that the XSL in our existing plugins can be
> more easily reused.

Thats true. In fact, I suggested that change to my comrade cause of
you very helpful email. I thought long about it and then we decided to
learn from forrest again and moved on to XHTML

>
>> - Generators and Connectors (Generate XML from within other
>> XML-Structures; Connect a Generator to Databases)
>
> I'm a little confused by your choice of names here. Looking at the demo the
> generator page displays data formatted in a particular way (i.e. a data
> table), there is no indication of what is actually happening. Is a generator
> the same as what we call a generator (something that creates XML for further
> processing, or is it a serializer (something that generates an output).

Sorry for the confusion. In fact, a generator generates XML constructs
for further processing.
Unfortunatly you are right: we have some HTMLGenerators too, like the
DataGrid "Generator". It should be renamed.
However, goal is to call classes which generate xml for further
processing generator and that other stuff we should call serializer.
Thanks.


>> - Authentification
> Again, how do you justify this alongside static generation?

This cannot work with static generation.

> I'm really not sure. Forrest is *not* a web framework, it is an XML
> publishing framework. Cocoon is a web framework.
>
> I'm confused by what Piwi is. Is it a web framework or a publishing
> framework. If it is a web framework what does it give over the many other
> web frameworks out there and why would Forrest (a publishing framework) be
> interested?
>
> If it is a publishing framework then why does it have some web framework
> features?
>
> Don't get me wrong, I'm not trying to be difficult. I'm genuinely trying to
> understand the objectives of Piwi and why you believe they align nicely with
> Forrest. Suffice it to say, it looks like you've done great job with Piwi.

First, thank you for your interest and your very helpful comments.

I think I should learn more about the differences from Cocoon to
Forrest. I always thought that Cocoon is a XML transformation
framework (not a web framework, even if it can used in the web
enviroment) and Forrest is one too, but with more specialized
functions for publishing on XML basis. Reduce the complexity of Cocoon
and publish your content, this is Forrest.

I consider PIWI as a xml transformation framework, which can be used
in the web too. I thought it fits to Forrest cause we simply looked at
the Forrest functionality and copied them over as good as it was
possible in PHP. For us the concept (and its interfaces) is more
important than the web features. We added those since PHP is usually a
web language.

I see some synergies in PIWI and Forrest. For example, I always wanted
to use Forrest but had no java host ready. I want to work like with
forrest but without the pain of complexity or without searching years
for a good and expensive java hosting partner. PHP is available on
most hosting enviroments. If Forrest pages could be used out of the
box in PIWI, this would be great.
PIWI feels like a lightweight Forrest to me.

I also remember the Forrest2 approach before a while. In fact this
brought me to the idea of creating PIWI. And that is the reason for
contacting this list, cause I don't see so much differences between
both projects.

Best,
Chris