So, I'm pleased to propose Jorg Heymans, as a committer.
+1
Helma
I would have thought the husband and two boys were the fulltime job!
Obviously, Helma has at least two full time jobs. It can be argued
that she has 4 full time jobs. From personal experience having a
spouse is a full time job and most certainly raising a child is a
full time job.
Yes, I'm thinking of attending the Cocoon GetTogether 2005 in
Amsterdam, preferably on
[ ] 3/4/5 October (Mon-Wed)
[X] 5/6/7 October (Wed-Fri)
Bye, Helma
Guys,
When the navigation is a matter of creating a query and/or a hand-picked
outline, I really don't think it is THAT important to decide now. When
writing the tutorial I found it practical to keep the various
steps/documents together so I could better focus on what to write and
what was done.
p class=code/ ?
nope, code is an inline tag.
Ok, I'll settle for span class=code for now.
Anyway, I'm thinking that for this and the other issue
(anchors), for the moment we could simply make sure they are
not lost during the import, and then see afterwards to do
something about it.
Hi Bertrand,
P.S. Helma, it seems like your mailer is breaking threads sometimes,
but not always. For example, [2] starts a new thread although it is
obviously a reply to [3]. If it's easy to fix it might be
good for our
archives.
[2]
On Mon, 2005-06-13 at 18:21 +0200, Bruno Dumon wrote:
snip/
What still needs to be done issues:
snip/
* Daisy doesn't have a code-like tag, we need to decide
what to do
with this. Daisy doesn't have this since the Mozilla/IE editor APIs
don't support the creation of this type of
Could you please publish your proposal today so that I (and
hopefully Sylvain)
can review it this evening? IIRC proposals have to be handed
in by tommorrow.
And don't forget to include (time for) documentation.
Bye, Helma
Guys,
I'm aware that I'm not officially a committer (yet), however, I think it
will be a good idea to get explicit consensus on where to locate the
docs and about a rough outline of the future actions.
This is the proposal:
- the current Daisy site at the zones [1] will be the incubator for
the
Unpublished versions are only shown to people with write access to
these documents.
True for the SimpleDocument, but not for the navigation tree. I cannot
quickly see changes in the navigation tree unless I publish the latest
version. Or am I doing something wrong?
Bye, Helma
Reinhard,
Maybe it has already been discussed and then I'm more than
happy with a link but
if not, can you explain the process of how our documentation
gets published
(http://cocoon.apache.org)? IIUC,
cocoon.zones.apache.org/daisy/ is our staging
area and not the official
yes, the usual javadocs, the page generated out of
trunk/lib/jars.xml and the
pages generated out of the javadocs of sitemap components.
To me this is API docs and serve a special purpose.
_I_ would be perfectly happy if they were in an accessible place, with
links to it from the ordinary
Based on some comments I would like to revise the proposal. Let's focus
first on what info goes where and what the general direction will be.
As things progress, we can focus on explicit processes and, given the
current discussion, the roles/rights.
- the current Daisy site at the zones [1] will
Please add documentation on the working of this. The exposure will be
better if there is documentation on how it works. It doesn't have to be
pixel perfect, but it should get new users up and running.
Bye, Helma
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of
Hi Mark,
Thanks for putting in all the work. I have reviewed the documents,
straightened out some layout glitches and put them live. So you should
now be able to see your work.
I created a CategoryInDaisy page in the Wiki, so that it is easy to
record a wiki page as having been transferred.
Really, you want it so that editors and publishers can see it, but
guests can't.
Eh, yes, but since publishers 'automagically' get the editors role as
well, I mentioned the editors only.
Maybe a switch between published and latest would be good.
This exists for a SimpleDocument (but only
On http://cocoon.apache.org/mirror.cgi the link to the explanation as
to why there are no binary distributions points to the old
wiki.cocoondev.org address (and does not redirect).
Hmm, since this is only a small amount of text I would simply include it
in the page, rather than referring to
One more thing: I just discovered that when I retire a document, the
document disappears immediately! Is that right?! I would've
expected a
publisher to need to approve my retiring of a document first.
I'm not familiar with the inner working of Daisy. Your assumption sounds
reasonable. I
To all document editors,
Seeing Mark's work and my own I decided that we best set some basic
rules for writing the documentation and using particular styling. This
improves a consistent look and prevents tedious cleanup at a later
stage.
This is what I propose (and I know _I_ haven't been
It would be even better if you defined classes for the
different style
elements you want and disable the ability to arbitrarily use em and
i for example.
This is already taken care of in Daisy by the htmlArea plugin and
Daisy's HTMLCleaner
The htmlArea plugin can be customised so that
It would be the best if you provided your guideline as a
template page
YourPageShouldLookLikeThis.
Good idea.
OT: Suppose I'd like to review some documents that have not been
published yet. Is there a special query for that?
Yes, I don't have it from the top of my head, but if you
Another question: how do include anchors within pages? Should I do it
manually with the HTML view?
No idea, do check it as I'm not sure it'll pass the HTMLCleaner config.
Bye, Helma
On this basis, I'd like to propose Helma Van Der Linden as a Cocoon
committer, and thus our first 'publisher'. She has been participating
regularly in our community, and has shown a quiet but steady
interest in
helping with our documentation, as well as an increasingly clear
http://cocoon.zones.apache.org/daisy/passwordReminder ;-)
Done that but no email has arrived for more than 10 minutes now.
Bye, Helma
Problem solved. It works now.
Any kind of email delay can be expected, as Hermes' inbound SMTP
services are really flaky, and Daisy only processes its stalled mail
queue every four hours. So if sending mail doesn't succeed the first
time, it can take a while before a new mail is being
Hi Mark,
let's take it slow and use the dev list for discussions. Marking the
subjects with [Docs] (as you've already done) gives the others the
option to join or ignore as they see fit.
If the volume increases the decision to use another mailing list can
always be taken.
To aid document
OK, the dev list sounds just fine! What do you think about the
refactoring I'm suggesting? I can do it over the next few
hours if you
are agreeable. You are editor-in-chief, so I don't want to start
without your approval!
:-)
Getting started with Cocoon
+ Installing the prerequisites
To aid document reorganisation I think we should encourage a fairly
fine-grained modularity, i.e. single topic pages.
Wouldn't it be a good start to do a smart import of current
xdocs into
new documentation structure?
No offense, but smart import still means going over each and every
That was exactly what I proposed. Our target should be a single
documentation source deprecating main docs and wiki. If we
add what is
the easiest now and leave main documentation aside the whole
effort will be incoherent.
True, but let's do one step at a time. The wiki is easier to
Yes, I think we are writing more than a reference manual
here. Perhaps,
at the appropriate places we could also talk about unit testing and
other best practices.
To me it ranges from executive summary to user's guide and tutorials
to developer's guide and reference manual and everything
Hi Mark,
sorry for being late in replying. Usually weekends are more hectic than
weekdays here.
I cannot grant you editor privileges as Steven is the administrator for
the site. I've asked Steven to fix this. In the mean time, just add
comments to any page and I'll be happy to incorporate the
Daughter woke up early: done. Helma, can you cross-check?
Done. All looks fine. Updated the navigation tree on cocoondev.org and
the first page to reflect the new site.
Now all I need is my editor rights back.
Bye, Helma
Hi Marc,
I do like the introduction.
A less time consuming alternative for me would be to Sew it all
together at Planet Cocoon, as it is already set up with
infrastructure
for anyone wishing to join in, tools for workflow, categorisation,
document hierarchy management etc. If I were to
Do we have something else on our wishlists (some fancy cforms
features, etc.)?
An effort to substancially reduce the number of open issues in bugzilla?
Bye, Helma
Linden H van der (MI) wrote:
An effort to substancially reduce the number of open issues in
bugzilla?
IMO this would be more something for a FirstFriday if these
are still happening.
Sounds good to me too. Why was the idea dropped in the first place? I
haven't joined them but got
1- Current released version
2- Daily SVN 2.1.x
3- Daily SVN 2.2.x..
Good idea, but I'm not sure if we want to have three versions there,
maybe we should start with the release and go from there?
YES! YES! YES!
I mean: good idea to start with the current released version and go from
Le 27 mai 05, à 14:47, Steven Noels a écrit :
...People interested in co-administering Daisy (users, creation of
variants, ACL rules, sites): please stand up...
My coworker and local Daisy expert, Patrick Ahles, agrees with helping out in
user-administration provided it requires a limited
A more general question: what sort of demand do you think
there is for
translations of the documentation? Any particular languages?
Being Dutch, and therefore used to use other people's language rather
than my own to get in contact with someone, I'm probably not
representative for the entire
important that it gets done. My point is that
no mater how easy and automated the process becomes, good
documentation requires a great deal of human collaborative effort.
On May 25, 2005, at 8:30 AM, Linden H van der (MI) wrote:
- pick a tool, any tool that meets the criteria I
Guys,
with all due respect for the various efforts to improve the
documentation, there is only one way to improvement and that is
screening all the available documentation on validity and clarity and
rewrite/enhance it when it's lacking or write the missing pieces. This
screening process is
I think that they are many people around here that can do the
dirty job to create well formed files (xml, xhtml, etc) but
few that can write documentation.
Well, I think you might be wrong there in the numbers. I've seen a post,
at least once, where someone writes something like I'd like to
I have a little time on my hands to actually implement some
of the things mentioned. My only question is what are others
possibly doing in parallel setting up some other system. I'd
rather not duplicate efforts when it turns out someone has
set up Daisy somewhere by the end of this week.
Daisy already IS set up: www.cocoondev.org/handbook
I now use it for the tutorial only, but I really don't mind if it
becomes the (temporary?) home of the entire new documentation.
How does Daisy handle xdocs type documents? Is a conversion
to daisy's format easy?
My coworker and
- pick a tool, any tool that meets the criteria I mentioned
above and
start a new set of documentation there. I suggest Daisy.
What you should be concerned about is managing new and existing
content. This includes some process for accepting vetting, editing/
correcting and
even a simple text editor. The one thing I have learned over the
years is that using the correct tool for the job makes the job
True.
Third, Cocoon's documentation is not as bad as people think. I was
able to put together a fairly complex e-commerce site that included
custom
Well, if you can delete documents from the repository, we can
move stuff
across, then delete it when it has been repurposed.
Yep, Daisy can delete documents.
Well, in my view we shouldn't have an ultimate distinction. They are
both a part of the same overall documentation.
True, but in
This will mean that people will be able to do forrest run
and edit the
content in SVn immediately. As the Daisy plugin matures the
same will be
true for content in a Daisy repository. Similarly, if PlanetCocoon
succeeds we can integrate their content and editing in the same way.
AHHH.
There is, but it's pure HTML. It has nothing to do with
CForms. Unknown
attributes on fi:styling are just copied to the output, e.g.
@class and also @readonly.
This is still true. I had a look at the stylesheets when this topic was
on.
Bye, Helma
I'm interested in hearing why you think that committership is
*the* incentive for people to contribute?
Same here. I may not be a representative of the average user population,
but I don't WANT committership until I'm fully convinced that I can
submit something without breaking somebody else's
I disagree. Cocoon has been very open in giving committership in the
past and will continue to be. But the fact is that committers know
True. With small group I only mean that the number of committers is
very small, compared to the total number of users on the lists. This is
just a fact,
As explained in a private mail to Sebastien, I've taken up the
http://www.cocoondev.org/handbook site that Steven graciously set up for me. I
intend to work on the mid-level tutorial that was the initial goal for the
Cocoon In Action project.
Doing it in Daisy is much easier for me, since it
As explained in a private mail to Sebastien, I've taken up the
http://www.cocoondev.org/handbook site that Steven
graciously set up for me. I intend to work on the mid-level
tutorial that was the initial goal for the Cocoon In Action project.
Doing it in Daisy is much easier for me, since
: Community health)
Linden H van der (MI) wrote:
As explained in a private mail to Sebastien, I've taken up the
http://www.cocoondev.org/handbook site that Steven
graciously set up for me. I intend to work on the mid-level
tutorial that was the initial goal for the Cocoon In Action
On the other hand, a full author listing means more work
because of one
more file to update when we commit a contribution (and the
need to avoid
duplicates).
Is it possible to have a script running on the SVN server that extracts
the username of each contributor and appends it to a file,
Related projects:
- CoWarp? http://osoco.sourceforge.net/cowarp/
Cocoon-based project:
- Daisy (http://www.cocoondev.org/main/117/42.html)
Bye, Helma
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, 29 April 2005 12:42
To: dev@cocoon.apache.org
Subject:
Hi,
I try to follow all threads on new Cocoon docs and I think I read
somewhere that you've put the docs live. But I can't find the reference
nor the URL where they should be.
Can you give me the URL?
Bye, Helma
Hi,
I stumbled onto a problem I've noticed before (Cocoon 2.1.5 I think). I
was under the impression it was solved,
but apparently not.
Situation is this:
- SVN checkout of BRANCHES
- Build a form definition with
fd:form.
fd:validation
fd:javascript
var success=true;
return success;
my SoC is bigger than yours.
Ok, people, enough bikeshedding.
Let's get back to work.
And all this because of an introduction to a Cocoon tutorial. Now I
remember why I didn't want to write this part in the first place.
Let's SHOW Cocoon's features and let everyone judge for themselves
Guys,
the most recent version of logkit.xconf in the HEAD results in an
exception (something like LogKitTarget [1] not found). I've updated my
local version 15 minutes ago, did a clean build and the error was there.
I then reverted to the previous version of logkit.xconf, did a clean
build and
Subject: Re: SVN HEAD: logkit.xconf error
Linden H van der (MI) wrote:
Guys,
the most recent version of logkit.xconf in the HEAD results in an
exception (something like LogKitTarget [1] not found). I've
updated my
local version 15 minutes ago, did a clean build and the error was
there. I
Guys,
can someone with in-depth knowledge of the CForms widgets help me out
here? I want to build a form that can be used to enter an HL7v3
TelecomAddress[1]. The final XML result looks like this:
telecomAddress use=HP nullFlavor=OTH/
or
telecomAddress use=HP value=tel:+3112345678/
I've
What about a custom validator?
Sounds like a good idea, but I have no clue how to do this in a generic
way. The next XML fragment could have the value defined as a set of
elements, e.g.:
name nullFlavor=NI/
vs.
name
given qualifier=firstJohn/given
given qualifier=initialL./given
What about an assert validation on value?
Sounds like a good idea, so I tried it. Thanks.
It doesn't work yet the way I want it to, so I've probably messed up the
test, I'll look into that on Monday.
However, writing the test showed that this is a very cumbersome way to
handle it. As I've
To give this some momentum AND because I haven't figured out yet how to
submit something to Sebastien's CMS, I'll post my proposal here:
The idea is: build a simple website using Cocoon and expand it as
time/tutorial and such progresses.
---
You are a web developer wanting to use Cocoon for the
Guys,
I know it's not done to mail to a mailing list with the return receipt
on. I've been notified be a few of you already, for which I thank you.
However, it's default turned on here, and I often forget to turn it
off before mailing to a Cocoon list.
I try to remember, but every now and then I
Hi,
Although Sebastien can answer for himself, I've asked exactly the same
question. Answer: he only has access to PHP-hosting, no Java hosting.
If someone would offer a Cocoon hosting or Daisy hosting for the
project, I personnaly be happy to move the content there.
Bye, Helma
Hi,
sorry I've been too busy lately to participate in anything I've promised
over time. It's not that I don't want to do it any more, just time...
well, you know.
Reading this thread, something clicked as I've been working on a simple
website using Cocoon with simple XML files as backend. So no
Hi,
just a quick hack/overview of what I have in mind. All this can be
added/modified etc. This is more or less how I did it. Note: I'm not in
favor of making this tutorial a showcase of all things possible. That
would make the tutorial either too large and too complex.
Another idea: once
: David Crossley [mailto:[EMAIL PROTECTED]
Sent: Saturday, 19 March 2005 04:08
To: dev@cocoon.apache.org
Subject: Re: [2.1.7 Testing Results - Forms block, samples] - update
Antonio Gallardo wrote:
Linden H van der (MI) dijo:
I fixed several of the problems below, but it results
Reading the HTML spec [1], the difference between disabled
and readonly are:
- readonly is only available on input and textarea. disabled is
available on all controls
- readonly sends back the value to the server, which is of no
use if the
widget is not active
- readonly inputs receive
So, to sum it up: readonly as attribute is supported in
the current
version of the styling XSL files, but there will be no
widget support
for this due to security issues. If treatment of the readonly
attribute should differ from the current situation, it is up to the
user to modify
Guys,
I checked out HEAD from SVN yesterday and now I'm trying to build it. I
did nothing more than build clean and build webapp and this is the
result:
D:/svn/cocoon/tools/src/check-jars.xsl:155:40: Warning!
File optional/commons-fileupload-1.0.jar appears in the lib/
directory, but is not
sorry, turned out to be a remnant from a previous attempt to develop a
exist-block-inject package.
Sorry for the noise.
Bye, Helma
-Original Message-
From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
Sent: Friday, 18 March, 2005 14:10
To: dev@cocoon.apache.org
Subject: build
Hi,
I fixed several of the problems below, but it results in 1 to 3 line patches of
about 40 files. What's the most efficient way of handling this?
Bye, Helma
-Original Message-
From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
Sent: Fri 3/18/2005 15:51
To: dev@cocoon.apache.org
Guys,
I've been working on bug fixing the forms samples which results in 1 - 3
line patches of about 40 files. What's the most efficient way of
creating and submitting these patches?
I only have Eclipse to create patches.
Bye,
Helma van der Linden
Medical Informatics
University Maastricht
Ok. He can add whatever attribute to his styling, the stylesheets are
True.
built for this, but I don't want to see this readonly attribute
handled in the stylesheets, as we have other mechanisms for
this, namely widget states.
Agree, however, readonly is part of the HTML textarea
Talking about users too lazy to read the docs :-)
http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transf
ormer.html#Attributes
Umph, I read this page about a dozen times, even when I was looking for
the answer to this problem, but somehow I either missed it or it didn't
click. :-(
Title: Message
Sounds
like a good idea. Since I'm working on the styling XSL sheets anyway, should I
include this?
Bye,
Helma
-Original Message-From: depub2
[mailto:[EMAIL PROTECTED] Sent: Tuesday, 15 March 2005
19:58To: CocoonDev; [EMAIL PROTECTED]Subject: RE: Re:
Sylvain,
I think he means that adding readonly='readonly' as attribute to his
own fi:styling tag is passed through the styling XSL files. IIRC there
is a template that deals with extra attributes in the styling tag.
HTH.
Bye, Helma
-Original Message-
From: Sylvain Wallez
Just for the record: nested repeaters are supported. I don't have the
samples at hand, but if you look at the list of samples just before the
dream team sample, you'll see 3. One of them demonstrates nested
repeaters.
Bye, Helma
-Original Message-
From: Mark Lowe [mailto:[EMAIL
Hi Jeremy,
you can specify the catalogue name in i18n attributes like this:
img src=cal.gif alt=cataloguename:calendar.alt i18n:attr=alt/
Thanks for replying, I already deducted this from a discussion some
years ago where Bruno suggested this. Talking about hidden
docs/features. ;-)
I'd love to add my version of the forms block samples to 2.1.7, but it's
not finished yet (mostly cosmetic changes are needed). I could dump it
in bugzilla in its current state and use the rest of the week for bug
fixes.
I merely copied the forms samples dir so there is duplicated code there.
Hi,
Just a quick response.
What you describe here are two entities: rooms and persons. It is much
more common sense to treat them separately, i.e. a list for editing
persons (just a repeater) and a list for editing rooms (simple list?)
and finally, maybe a doubleList for adding persons to a
: Sunday, 13 March 2005 20:22
To: dev@cocoon.apache.org
Subject: RE: CForms Binding - Cross Referenced Data
(duplicate of post on users)
Linden H van der (MI) wrote:
Hi,
Just a quick response.
What you describe here are two entities: rooms and persons.
It is much more common
Guys,
I don't manage to stay current on the ins and outs of CForms, current
state and its future. I'm currently working on removing the tablebased
layout from the forms-*-styling.xsl files. I would very much like it to
be added to 2.1.7, so I'm doing my best to get it done before the code
freeze.
PROTECTED]
Sent: Saturday, 12 March 2005 14:45
To: dev@cocoon.apache.org
Subject: Re: Question on CForms - relevant for 2.1.7
Le 12 mars 05, à 14:30, Linden H van der (MI) a écrit :
...What I'd like to know is: how many differences are there between
HEAD
and TRUNK that will make my
Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Saturday, 12 March 2005 15:06
To: dev@cocoon.apache.org
Subject: Re: Question on CForms - relevant for 2.1.7
Le 12 mars 05, à 14:52, Linden H van der (MI) a écrit :
...So at least the styling will remain the same, but are there
differences (big
@cocoon.apache.org
Subject: Re: Question on CForms - relevant for 2.1.7
Le 12 mars 05, 14:52, Linden H van der (MI) a crit :
...So at least the styling will remain the same, but are there
differences (big or small) in the widget definitions etc.
that require
a rewrite
Hi,
I've managed to get the i18n for the flowscript samples to work, by
moving around the i18n transformer. However, I haven't succeeded in
properly translating i18n info that is introduced in the
forms-*-styling.xsl files. It seems impossible to add the i18n
transformer a second time.
So, what
]
Sent: Saturday, 12 March 2005 20:00
To: dev@cocoon.apache.org
Subject: Re: CForms samples for 2.1.7 - i18n question
Le 12 mars 05, à 19:01, Linden H van der (MI) a écrit :
...I've managed to get the i18n for the flowscript samples
to work, by
moving around the i18n transformer. However
-
From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
Sent: Saturday, 12 March 2005 21:02
To: dev@cocoon.apache.org
Subject: RE: CForms samples for 2.1.7 - i18n question
Bertrand et Sylvain,
Right now, no i18n works. In core.log I find lines like:
INFO(2005-03-12) 20:24.05
the calendar.alt key in the default catalogue, but it's in the
forms catalogue.
Thanks.
Bye, Helma
-Original Message-
From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
Sent: Saturday, 12 March 2005 21:56
To: dev@cocoon.apache.org
Subject: RE: CForms samples for 2.1.7 - i18n question
Found this one too somewhere in an old message:
img src=cal.gif alt=forms:calendar.alt i18n:attr=alt/
Now all I need are translations ;-)
Bye, Helma
-Original Message-
From: Linden H van der (MI) [mailto:[EMAIL PROTECTED]
Sent: Saturday, 12 March 2005 23:51
To: dev
I don't see this here, just did svn up and a full build of the
BRANCH_2_1_X, and
http://localhost:/samples/blocks/forms/form1.flow works
fine, and
the localized versions look ok as well.
Works for me also. Helma, you should try a build clean webapp, as
NoSuchMethodError
Guys,
Today I checked out the latest HEAD version and got it to build
successfully (the out-of-the-box settings). However, when I started the
form1.flow sample it gave me a blank page and a stacktrace in the
console about no such method. Since this one is also used for the
localized versions in
Hi,
since you're updating the FormsMessages file, could you add an entry
message key=calendar.altYour local name for a Calendar
here/message
I'm working on the forms-samples-styling.xsl files and in the meantime I
try to fix a little TODO to provide a localized alt to the calendar
image.
To all the guys that provided the translation: thanks!
Bye, Helma
In my attempt to fix the locales samples in the Cforms samples block, as
well as adding a localized calendar image alt attribute, I came across
some odd behaviour:
In the pipeline form1 of the sitemap of these samples, i18n is called
twice, so I assumed this can be done. However, when I do this
You mean changing the forms-styling XSL stuff?
Would be way cool, but there are people who might not want to rely on
CSS too much for positioning fields.
I'm all for moving to more powerful CSS-based versions, but
it might be
good to keep the existing stuff around for people who want
As I've stumbled across this a few times already (and I'm not nearly as
much into Cocoon as you guys), I know what you mean. I'll try and modify
the current XSL code and put it in Bugzilla.
Bye, Helma
-Original Message-
From: Ugo Cei [mailto:[EMAIL PROTECTED]
Sent: Monday, 28
1 - 100 of 102 matches
Mail list logo
