You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2003/08/27 17:33:51 UTC
Re: Blocks Manual
On Wed, 27 Aug 2003, Robert Simmons wrote:
> Greetings,
>
> Is there a manual that describes all of what each block in cocoon 2.1
> does ? Perhaps I missed it.
Nope, it isn't there. Don't forget to have a look at
http://cocoon.apache.org/2.1/plan/index.html,
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Cocoon+2&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=%27Importance%27,
http://wiki.cocoondev.org/Wiki.jsp?page=RT as well, and
http://cocoon.apache.org/community/contrib.html as a way to solve all
this.
It's good to have you back, Robert. While we ain't a bunch of academics,
we still primarily scratch our own itches. We hope our users do as well,
and this, together with some respect for the time all of us voluntarily
contribute to the Cocoon project, is essentially what community-based open
source development is all about. The 'strategy' behind shipping software
with rough edges is two-fold: (1) Cocoon won't be finished until its
community declares so, by no longer contributing to it, and (2) we like to
see every user as a possible future contributor. We don't employ a
professional helpdesk, since our users happen to help each other, and
several devs are keen to help with major issues. All this is done in the
best possible spirit, and I hope you can respect that. Your enquiries are
meaningful, and many of them would merit being implemented, but it's not
by simply stating them that they effectively will be resolved. The leaky
abstraction in software communities is human beings doing the actual work.
Cheers,
</Steven>
RE: Blocks Manual
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Robert Simmons wrote:
>
> If I had the qualifications to, yes. However it would be terribly
> inefficient for me to spend months studying the source code to
> the blocks in
> order to make complete documentation when there are people that
> already know
> these blocks and could make the documentation a lot quicker.
>
> Cocoon has a number of huge documentation holes. Do you bring in a source
> newbie to plug them or do you get on the developers that actually
> know what
> is going on to plug them? Option B is much more reasonable.
>
I think everyone ranging from a user to the expert can help here. Starting
a documentation doesn't mean that you know everything. You can provide
a frame with the things you know (or you think you know) and others
can step in and fill the holes. This is a community work then.
You will see this happen as soon as you do the starting work.
Carsten
Re: Blocks Manual
Posted by Robert Simmons <ro...@norcom.de>.
If I had the qualifications to, yes. However it would be terribly
inefficient for me to spend months studying the source code to the blocks in
order to make complete documentation when there are people that already know
these blocks and could make the documentation a lot quicker.
Cocoon has a number of huge documentation holes. Do you bring in a source
newbie to plug them or do you get on the developers that actually know what
is going on to plug them? Option B is much more reasonable.
-- Robert
"Steven Noels" <st...@outerthought.org> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0308281348520.19702-100000@cocoondev.org...
> On Thu, 28 Aug 2003, Robert Simmons wrote:
>
> > Like I said before, I tend to be direct in my language and if I offend,
I
> > certainly dont mean to and I appologize.
>
> You don't seem to understand what I'm trying to explain, so pardon my
> shouting: QUIT APOLOGIZING - DO SOMETHING ABOUT IT.
>
> Except for the JMS logging thing, most of your remarks make some sense.
> Now, what if nobody cares enough to actually do the work for you? Will you
> do it yourself?
>
> Cheers,
>
> </Steven>
>
>
Re: Blocks Manual
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 28 aoû 2003, à 13:45 Europe/Zurich, Robert Simmons a écrit :
> ...On-topic: that blocks manual would be cool. Im having a hard time
> figuring
> out what blocks I will need for my production build....
There were lots of discussion a while ago on the docs list regarding
"component reference pages", basically manpage-like reference docs on
the various components (Blocks or not).
The general idea was to have a reference page for each component,
partly generated from the component's source code javadoc tags,
augmented by xml or text-based narration.
This hasn't happened yet as nobody really took the plunge, but anybody
willing to help on this is welcome - in the meantime the qdox block
allows javadoc-like tags to be processed by Cocoon when generating the
docs.
In the meantime, the best reference for the blocks are the samples, but
you're right that a well-organized documentation would be better.
-Bertrand
Re: [users@httpd] Folder/Directory Access Control
Posted by Joshua Slive <jo...@slive.ca>.
On Thu, 28 Aug 2003, Jason (Spaz) wrote:
>
> Greetings,
>
> I am rather new to Apache but I have most of the basics down. I am running
> the latest build of Apache for Win32 (winxp). I have a folder that I woiuld
> like to restrict access to by IP addresses. Is this done through a
> .htaccess file placed in the folder that I want to restrict access too? Do
> I follow the same logic as found in the main .conf file?
You may use an .htaccess file, but it is not necessary. Placing
directives in an .htaccess file is the same as placing them within a
<Directory> section in httpd.conf. For access control in particular, look
at the documentation for mod_access.
Joshua.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
[users@httpd] Folder/Directory Access Control
Posted by "Jason (Spaz)" <Ha...@comcast.net>.
Greetings,
I am rather new to Apache but I have most of the basics down. I am running
the latest build of Apache for Win32 (winxp). I have a folder that I woiuld
like to restrict access to by IP addresses. Is this done through a
.htaccess file placed in the folder that I want to restrict access too? Do
I follow the same logic as found in the main .conf file?
Thanks!
Jason
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Blocks Manual
Posted by Steven Noels <st...@outerthought.org>.
On Thu, 28 Aug 2003, Robert Simmons wrote:
> Like I said before, I tend to be direct in my language and if I offend, I
> certainly dont mean to and I appologize.
You don't seem to understand what I'm trying to explain, so pardon my
shouting: QUIT APOLOGIZING - DO SOMETHING ABOUT IT.
Except for the JMS logging thing, most of your remarks make some sense.
Now, what if nobody cares enough to actually do the work for you? Will you
do it yourself?
Cheers,
</Steven>
[users@httpd] Re: Blocks Manual
Posted by Robert Simmons <ro...@norcom.de>.
And am willing to contribute if I can do so in a manner that doesnt require
months of learning before I can accomplish anything. I wonder if that means
cocoon is too big that it scares off newbies. =) Happens to the best of
them, JBoss, Apache Web Server, etc.
Like I said before, I tend to be direct in my language and if I offend, I
certainly dont mean to and I appologize.
On-topic: that blocks manual would be cool. Im having a hard time figuring
out what blocks I will need for my production build.
-- Robert
"Steven Noels" <st...@outerthought.org> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0308271703280.28478-100000@cocoondev.org...
> On Wed, 27 Aug 2003, Robert Simmons wrote:
>
> > Greetings,
> >
> > Is there a manual that describes all of what each block in cocoon 2.1
> > does ? Perhaps I missed it.
>
> Nope, it isn't there. Don't forget to have a look at
> http://cocoon.apache.org/2.1/plan/index.html,
>
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Cocoon+2&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=%27Importance%27,
> http://wiki.cocoondev.org/Wiki.jsp?page=RT as well, and
> http://cocoon.apache.org/community/contrib.html as a way to solve all
> this.
>
> It's good to have you back, Robert. While we ain't a bunch of academics,
> we still primarily scratch our own itches. We hope our users do as well,
> and this, together with some respect for the time all of us voluntarily
> contribute to the Cocoon project, is essentially what community-based open
> source development is all about. The 'strategy' behind shipping software
> with rough edges is two-fold: (1) Cocoon won't be finished until its
> community declares so, by no longer contributing to it, and (2) we like to
> see every user as a possible future contributor. We don't employ a
> professional helpdesk, since our users happen to help each other, and
> several devs are keen to help with major issues. All this is done in the
> best possible spirit, and I hope you can respect that. Your enquiries are
> meaningful, and many of them would merit being implemented, but it's not
> by simply stating them that they effectively will be resolved. The leaky
> abstraction in software communities is human beings doing the actual work.
>
> Cheers,
>
> </Steven>
>
>
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: Blocks Manual
Posted by Robert Simmons <ro...@norcom.de>.
And am willing to contribute if I can do so in a manner that doesnt require
months of learning before I can accomplish anything. I wonder if that means
cocoon is too big that it scares off newbies. =) Happens to the best of
them, JBoss, Apache Web Server, etc.
Like I said before, I tend to be direct in my language and if I offend, I
certainly dont mean to and I appologize.
On-topic: that blocks manual would be cool. Im having a hard time figuring
out what blocks I will need for my production build.
-- Robert
"Steven Noels" <st...@outerthought.org> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0308271703280.28478-100000@cocoondev.org...
> On Wed, 27 Aug 2003, Robert Simmons wrote:
>
> > Greetings,
> >
> > Is there a manual that describes all of what each block in cocoon 2.1
> > does ? Perhaps I missed it.
>
> Nope, it isn't there. Don't forget to have a look at
> http://cocoon.apache.org/2.1/plan/index.html,
>
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=Cocoon+2&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=%27Importance%27,
> http://wiki.cocoondev.org/Wiki.jsp?page=RT as well, and
> http://cocoon.apache.org/community/contrib.html as a way to solve all
> this.
>
> It's good to have you back, Robert. While we ain't a bunch of academics,
> we still primarily scratch our own itches. We hope our users do as well,
> and this, together with some respect for the time all of us voluntarily
> contribute to the Cocoon project, is essentially what community-based open
> source development is all about. The 'strategy' behind shipping software
> with rough edges is two-fold: (1) Cocoon won't be finished until its
> community declares so, by no longer contributing to it, and (2) we like to
> see every user as a possible future contributor. We don't employ a
> professional helpdesk, since our users happen to help each other, and
> several devs are keen to help with major issues. All this is done in the
> best possible spirit, and I hope you can respect that. Your enquiries are
> meaningful, and many of them would merit being implemented, but it's not
> by simply stating them that they effectively will be resolved. The leaky
> abstraction in software communities is human beings doing the actual work.
>
> Cheers,
>
> </Steven>
>
>