Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <CD8AF9AA-FCD5-49CD-9BFB-2251514EBEC4@apache.org>
From: Ross Gardler <rgardler@apache.org>
To: dev@forrest.apache.org
In-Reply-To: <ded132f10812220344r61919737ud6546f05ca9e2c21@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Piwi - Forrest in PHP
Date: Mon, 22 Dec 2008 14:48:13 +0000
References: <ded132f10812180727l3479fdafj63b5558d1d489eee@mail.gmail.com>
 <89981C6C-BEDC-4F0F-8498-8DCEBCB10F00@apache.org>
 <ded132f10812220344r61919737ud6546f05ca9e2c21@mail.gmail.com>


On 22 Dec 2008, at 11:44, Christian Grobmeier wrote:

> 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.

This would be requirements creep for Forrest. We are a content  
framework not a web framework. Given that the goal of Forrest is to  
provide many output formats from many input formats (and according to  
the PIWI website this goal is shared) then I am struggling with the  
above affirmation.

Either you don't need to support forms, or you need to support them in  
a way that is compatible with the goal of the project, i.e. give the  
best possible rendering of a page given the constraints of the output  
format.

>>> - Authentification
>> Again, how do you justify this alongside static generation?
>
> This cannot work with static generation.
>

Exactly, see my comments above. I feel that either the PIWI objectives  
are poorly stated on your website or you have a sever case of  
requirements creep on your hands.

>>
>> 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.
>


Historically Cocoon was an XML publishing framework. Over the years it  
migrated into being a web framework as requirements like forms  
processing and authentication crept in (I carefully chose those  
examples for obvious reasons, but I could have provided so many more  
such examples).

Forrest was created around the time it was clear Cocoon was more than  
an XML publishing framework, Forrest came along to satisfy a specific  
need of XML publishing (many formats in, many formats out) and  
stripped out most of the dynamic web framework stuff that had crept  
into Cocoon. Forrest was originally targeted at creating web sites and  
documentation for ASF projects. Over the years it has grown into more  
genera publishing jobs.

In other words, you are right about Forrest, but Cocoon is most  
definitely a web framework.


> 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.

Given the history of Forrest I doubt we would be interested in a  
project that brings back the requirements creep that resulted in the  
creation of Forrest in the first place. However, the idea of  
simplifying Forrest and making it more accessible to users is of  
interest to a number of Forrest devs.

However, as I said in my original mail. Most of us have a great deal  
invested in Forrest as it is currently designed. To get traction here  
I expect you will need to:

a) decide what the scope of PIWI is and, if necessary address the  
requirements creep issue
b) allow Forrest plugins to be reused without modification (a script  
for conversion might work)

Even then I'm not saying you will get traction, I'm only saying I  
doubt you will get traction without that.

> I see some synergies in PIWI and Forrest. For example, I always wanted
> to use Forrest but had no java host ready.

But this shows the misunderstanding you have of Forrest. The idea is  
that you host static content, not dynamic content. If you need dynamic  
content you need a web framework not a publishing tool. To host static  
content you don't need Java (or PHP)

> 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.

Sure, and your work has gone further than my Forrest 2 experiments  
did. However, it has diverged from the goals of Forrest and is  
therefore, in its current form, a very different project.

Ross