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
