Doh....sorry stefano I meant to send that just to you.... fat fingers
strike again.
Andrew C. Oliver wrote:
Stefano Mazzocchi wrote:
Andrew C. Oliver wrote:
>
>
> since i answer the asf email, this is something that has bugged
> the crap out of me, and about which i have complained several
> times to no avail.
>
> there is no canonical /mailing-lists.html location to which
> i can point people for j random project, so i have to tell them
> to search the project site for the info. that sucks.
>
>
so fix it.
Uh, Andy, that helped a lot. Thanks. :)
No problem ;-)
Can you estimate the emount of energy it takes to go into every
project and tell them to update their site? or, if you want to do it,
why do you think they would agree with you? maybe they don't like the
URI name, maye they have a community.html page that already lists
those things. or maybe, for whatever reason, they don't want
development mail lists to be easy to find (I did needed that once in
order to slow down community building!)
That is another issue entirely. Whether consistancy and usability has
a cost-benefit ratio that makes it worth your while. Or whether
consistancy can be a goal in a diverse group of people whom are not
beholden to your goal.
In fact, Forrest is just *one* possible use of Cocoon. Forrest is a
Cocoon spin-off, but the great value is its focus: come up with a way
to generate a *nice* web site, nice navigation, nice look&feel, easy
content administration. In the future, we might also include a
web-driven content management system on top of Forrest (running
Cocoon underneath).
Although I use Cocoon for this task, to be honest its not very well
suited for this in my opinion (and I'm sorry to say this). Its much
slower and sucks down way more memory than anakia/etc does to generate
static documentation. Now for dynamic stuff, Cocoon is defintely the
cats meow but if it weren't for the fact that Nicola Ken has made
documentation with XML brainless for me, I'd probably use something
else. I'd like to see either Cocoon increase performance by about a
factor of 3 and decrease memory consumption by at least a factor of 3
for static documentation generation or see Forrest support other suck
transform engines in a pluggable manner so that those can be fast.
I spent several months with my former girlfriend (who is a usability
engineer) to design the Forrest layouts and the usability of the
navigation. A lot of work has ben put into that, while other efforts
(maven, stylebook) simply didn't care about navigation and usability,
but just about look and ease of regeneration.
And it looks really nice. I can't wait to use it. It has made it on
my palm pilot based task list (along with voting to put a burr in
Bush's boot which I did today ;-) ). Ease of regeneration is
usability for developers.
Of course, I'm way biased here, so don't start a maven vs. forrest
pissing contest, please.
I just want to point out that the only way I see to fix our web
interface problems is to create better tools and hardcode a number of
usability guidelines into them.
I disagree. The tools do not make the man, nor do they make
decisions. I'm actually rather suprised to hear this from you. One of
the reasons I prefer Centipede (for instance) over Maven is that it
enables me to do things my way where maven tends to tell me how I must
do them. There is an inherent disabillity towards consistancy in this
type of development and I think the best way to afford it is through
personal leadership. (Look at the architecture of Cocoon, the only
thing consistant about it is Avalon and XML technologies....the rest
is often more different than night and day).
Another approach to this (rather than try and create tools for folks
to do things your way) is to simply pick up the hatchet and create a
site for all of the projects that is consistant and etc. One way to
do this is to get like minded people like yourself start it and see if
others come and fall in line... Perhaps forrest is exactly that....
However its success depends on a number of folks saying "gee thats a
good idea" and "gee thats easy to use" (from a developer standpoint)
and "that sure is pretty"... And in the end since this is apache we'll
have at least two competing versions ;-)...Perhaps as our community
becomes less western centered we'll become less concentrated on
dualism and more concentrated on diverse cooperation.
So I think I agree with your methods and, etc, but not your
perspective on the matter ;-)
Starting with a project.xml info file is a great thing and we can
keep going from that point on.
I agree.
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
