RE: CForms Summer of Code project

> 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

[VOTE] Consensus about documentation location

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 th

Re: [VOTE] Consensus about documentation location

Linden H van der (MI) wrote: Many thanks for the summary and the vote. I have to admit that I wasn't able to read all the mails. 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

Re: [VOTE] Consensus about documentation location

Linden H van der (MI) wrote: 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]

Re: [VOTE] Consensus about documentation location

Il giorno 13/giu/05, alle 09:53, Leszek Gawron ha scritto: Linden H van der (MI) wrote: - this documentation is targeted at Cocoon 2.2. This means that we try to write version-independent documentation, but when there is a difference between 2.1 and 2.2, the documentation will describe 2.2. W

Re: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

On 10 Jun 2005, at 10:12, Linden H van der (MI) wrote: So what I want is a navigation section that basically displays all documents available (including the unpublished ones). The only problem now is to whom it will be visible. Unpublished versions are only shown to people with write access to

Re: CForms Summer of Code project

Hi all! Yes, I will. The deadline is on the 14th, so does that mean the 14th 0:00 or 23:59? Its a big difference for me as a student ;) Anyway, I'll get to it this afternoon, still have to work before. Don't worry though, I didn't (and won't) forget! Thank you very much for your help! max

Re: CForms Summer of Code project

Max Pfingsthorn wrote: Hi all! Yes, I will. The deadline is on the 14th, so does that mean the 14th 0:00 or 23:59? Its a big difference for me as a student ;) don't know. But as you work for a Dutch company you gain a few hours as Google has its headquaters in California AFAIK ;-) Anyway,

RE: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

> 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

[CForms] Plain convertor for Enum datatype is null, throws NPE for MultiValueFields

Hi, I have a multi-value field widget, with datatype enum (so that users can select 0 or more values from an enum). But, when I load my object model in the form (setting the enum values from my model into the formmodel), then show the form, I get a NullPointerException in MultiValueField.generateI

Re: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

On 13 Jun 2005, at 11:18, Linden H van der (MI) wrote: 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. Ah

Re: [VOTE] Consensus about documentation location

Linden H van der (MI) wrote: 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

RE: [VOTE] Consensus about documentation location

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 docum

Re: [VOTE] Consensus about documentation location

Linden H van der (MI) wrote: 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

Re: NullPointerException building cocoon for forrest

Carsten Ziegeler wrote: Juan Jose Pablos wrote: Hi, Since this version: http://svn.apache.org/viewcvs.cgi?rev=164112&view=rev I am getting a null pointer exception when runnig forrest: Exception in thread "main" java.lang.NullPointerException at org.apache.cocoon.Cocoon.initialize(Coc

RE: generated docs (was: [VOTE] Consensus about documentation location)

> 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 "ordin

Re: [VOTE] Consensus about documentation location

Sylvain Wallez wrote: Same concerns as Ugo. We should IMO document 2.1 and use specially labelled sections and pages for what's different in 2.2. We could also uses Daisy branches, but I don't think it's a good idea to start a multi-branch effort right now. I agree with this also. - o

Re: [VOTE] Consensus about documentation location

Ralph Goers wrote: Sylvain Wallez wrote: Same concerns as Ugo. We should IMO document 2.1 and use specially labelled sections and pages for what's different in 2.2. We could also uses Daisy branches, but I don't think it's a good idea to start a multi-branch effort right now. I agree wit

Re: [VOTE] Consensus about documentation location

On Jun 13, 2005, at 3:27 AM, Ugo Cei wrote: Il giorno 13/giu/05, alle 09:53, Leszek Gawron ha scritto: Linden H van der (MI) wrote: - this documentation is targeted at Cocoon 2.2. This means that we try to write version-independent documentation, but when there is a difference between 2.

Re: [Daisy/Docs] Styling conventions

On 10 Jun 2005, at 22:52, Linden H van der (MI) wrote: I don't have the privileges to set it up, so I'll bug Steven about it when we figure out what should be done. ;-) This is changed now. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java &

Re: [Docs] Refactoring, porting Wiki content, and evaluating Daisy

On 10 Jun 2005, at 04:07, Mark Leicester wrote: * Newly created pages are invisible until they are published (by someone with publishing rights). It's a little like flying blind. I had to remember document IDs in order to cross-link (unpublished pages don't show up in the link chooser). I

RE: [VOTE] Consensus about documentation location - revised version

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

Re: [VOTE] Consensus about documentation location

On 13 Jun 2005, at 16:13, Glen Ezkovich wrote: One of the current limitations of Daisy is that we have only 3 roles. We need a fourth. Publishers, who make a document official and publish it to the main documentation site. You can have an "official documentation site" with a navtree that is

Re: [osgi] Package structure

Bertrand Delacretaz wrote: > Le 10 juin 05, à 18:23, Daniel Fagerstrom a écrit : > >> ...I will be offline the comming week (sailing). Feel free to finish >> the OSGi stuff while I'm away ;) > > > hmmm...this OSGI stuff is cool, but if we have a choice, I'd rather go > sailing ;-) Which, in fac

Re: [VOTE] Document Editors, and a new Committer

Nathaniel Alfred wrote: >>-Original Message- >>From: Upayavira [mailto:[EMAIL PROTECTED] >>Sent: Donnerstag, 9. Juni 2005 11:52 >>To: dev@cocoon.apache.org >>Subject: [VOTE] Document Editors, and a new Committer > > >>On this basis, I'd like to propose Helma Van Der Linden as a Cocoon >>

Re: [Ann/RFC] "Sitemap Blocks"

Yey!! Daniel, you rock! Thanks so much for your continuous work on this! See my comments inlined. Daniel Fagerstrom wrote: > I have added a first, hopefully working, version of the sitemap aspect > of real blocks to the trunk. No functionality to get components (not > even VPCs) yet from the bl

Re: [VOTE] Consensus about documentation location - revised version

Linden H van der (MI) wrote: 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

CForms-XUL project information

Hi Antonio, Helma, and all others! Thank you for your remarks. I have attached some documentation i've written concerning CForms-XUL. Please take a look at it. Thanks! Maksim Kashynski begin 666 Cocoon CForms - XUL - proposal.html M/&@R/D-&;W)M2!(5$U,(&ES('-U<'!OFEL M;&[EMAIL PROTECTED],(&ES(%A-

Re: [VOTE] Consensus about documentation location

Reinhard Poetz wrote: Linden H van der (MI) wrote: 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

Re: [VOTE] Consensus about documentation location

Ross Gardler wrote: Reinhard Poetz wrote: Linden H van der (MI) wrote: 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.apa

Re: [VOTE] Consensus about documentation location

On Jun 13, 2005, at 8:46 AM, Ralph Goers wrote: Sylvain Wallez wrote: Same concerns as Ugo. We should IMO document 2.1 and use specially labelled sections and pages for what's different in 2.2. We could also uses Daisy branches, but I don't think it's a good idea to start a multi-bran

Re: CForms Summer of Code project

Hi everyone! I've posted my preliminary proposal at http://wiki.apache.org/cocoon/GoogleSummerOfCode2005 Any comments are very welcome! Bye! max On 6/13/05, Reinhard Poetz <[EMAIL PROTECTED]> wrote: > Max Pfingsthorn wrote: > > Hi all! > > > > Yes, I will. The deadline is on the 14th, so does

Re: [osgi] Package structure

On Monday 13 June 2005 23:43, Stefano Mazzocchi wrote: > > hmmm...this OSGI stuff is cool, but if we have a choice, I'd rather go > > sailing ;-) > > Which, in fact, I did :-) You do that all the time. Question is; Was it with a boat this time?? ;o) Thanks to Daniel for bring my attention to OSG

CForms: some renamings on the Widget interface

Hi all, As part of the stabilization work on CForms, there are a couple of changes I'd like to do on the naming-related methods of the Widget interface. Today we have: - getId() which returns the local name of widget. - getRequestParameterName() which returns the combination of the parent wi

Build fails with latest checkout of BRANCH_2_1_X

Hi, Build fails with latest checkout of BRANCH_2_1_X, using j2sdk1.4.2_07 on Debian Sarge /L. compile-core: Copying 18 files to /home/leo/BRANCH_2_1_X/build/cocoon-2.1.8-dev/classes Copied 60 empty directories to 33 empty directories under /home/leo/BRANCH_2_1_X/build/cocoon-2.1.8-dev/classes C

[docs] import tool for current docs

[sent this earlier but didn't get through, likely because of attachments] Thought I'd help out a bit with the documentation effort by writing a tool to import the current documentation into Daisy. The facts: * it's written in javascript (rhino) to lower the hacking-barrier * it imports the xdoc

Re: "CForms - XUL" Project proposal

> --- Ursprüngliche Nachricht --- > Von: "Maksim Kashynski" <[EMAIL PROTECTED]> > Datum: Sun, 12 Jun 2005 22:36:13 +0300 > > Hi everybody! > My name is Maksim Kashynski. > > I am interested in working on CForms-XUL project under Google SoC. > > So this is my proposal's draft. > Problem: > Coco

Re: CForms Summer of Code project

On Fri, Jun 10, 2005 at 12:46:09AM +0200, Max Pfingsthorn wrote: > Hi again! > > This is mainly to Reinhard and Sylvain, I guess. Who else is a CForms > guru here? :) > > I have a question about the inheritance and namespace/inclusion > semantics which are not really discussed in the wiki. > > 1

Re: [VOTE] Consensus about documentation location - revised version

On Jun 13, 2005, at 10:16 AM, Linden H van der (MI) wrote: 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, th

CForms: some renamings on the Widget interface

[repost as the original seems to have been lost] Hi all, As part of the stabilization work on CForms, there are a couple of changes I'd like to do on the naming-related methods of the Widget interface. Today we have: - getId() which returns the local name of widget. - getRequestParameterName

Re: CForms Summer of Code project

On Fri, Jun 10, 2005 at 08:04:26AM +0200, Reinhard Poetz wrote: > Max Pfingsthorn wrote: > >Hi again! > > > >This is mainly to Reinhard and Sylvain, I guess. Who else is a CForms > >guru here? :) > > IIRC the idea came from Tim Larson who has also started with some > experimental code > (http://

[docs] import tool for current docs

Thought I'd help out a bit with the documentation effort by writing a tool to import the current documentation. The facts: * it's written in javascript (rhino) to lower the hacking-barrier * it imports the xdocs starting from the source tree. It translates them to html with an XSL and cleans the

Re: CForms: some renamings on the Widget interface

Sylvain Wallez wrote: Hi all, As part of the stabilization work on CForms, there are a couple of changes I'd like to do on the naming-related methods of the Widget interface. Today we have: - getId() which returns the local name of widget. - getRequestParameterName() which returns the combi

Re: CForms: some renamings on the Widget interface

On Mon, 2005-06-13 at 17:02 +0200, Sylvain Wallez wrote: > Hi all, > > As part of the stabilization work on CForms, there are a couple of > changes I'd like to do on the naming-related methods of the Widget > interface. > > Today we have: > - getId() which returns the local name of widget. > -

Small dilemma: are Actions still recommended?

Cocooners, Working on some introductory documentation I ran into a slight dilemma. I want to mention how Cocoon is able to access either the model or a database in response to a request and produce a response based on the result. Because of its simplicity, I will be concentrating on JSFlo

Re: CForms: some renamings on the Widget interface

Jason Johnston wrote: On Mon, 2005-06-13 at 17:02 +0200, Sylvain Wallez wrote: Hi all, As part of the stabilization work on CForms, there are a couple of changes I'd like to do on the naming-related methods of the Widget interface. Today we have: - getId() which returns the local name o

Re: Small dilemma: are Actions still recommended?

Glen Ezkovich wrote: Cocooners, Working on some introductory documentation I ran into a slight dilemma. I want to mention how Cocoon is able to access either the model or a database in response to a request and produce a response based on the result. Because of its simplicity, I will be

Re: CForms: some renamings on the Widget interface

On Mon, 2005-06-13 at 23:31 +0200, Sylvain Wallez wrote: > Jason Johnston wrote: > > >On Mon, 2005-06-13 at 17:02 +0200, Sylvain Wallez wrote: > > > > > >>Hi all, > >> > >>As part of the stabilization work on CForms, there are a couple of > >>changes I'd like to do on the naming-related methods

Re: [docs] import tool for current docs

Bruno Dumon wrote: * Daisy doesn't have a -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 tag. ? Ross

Re: CForms-XUL project information

Hi Maksim, can you repost the proposal.html? See below what I got. Best Regards, Antonio Gallardo On Lun, 13 de Junio de 2005, 11:41, Maksim Kashynski dijo: > Hi Antonio, Helma, and all others! > Thank you for your remarks. > I have attached some documentation i've written concerning CForms-XUL

DO NOT REPLY [Bug 35348] New: - I18ntranformation output xmlns:i18n in the first element

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 35273] - [PATCH] processToDOM returns a read-only DOM

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: CForms: some renamings on the Widget interface

On Lun, 13 de Junio de 2005, 10:02, Sylvain Wallez dijo: > So I propose the following: > - getId() --> getName() > - getRequestParameterName() --> getFullId() > - deprecate and remove later getId() and getRequestParameterName(). > > Once getId() will have been removed for some time, we'll be able t

Re: "CForms - XUL" Project proposal

On Lun, 13 de Junio de 2005, 13:43, "Jörg Heinicke" dijo: > Hello Maksim, > > isn't "just" converting the stylesheets for HTML to ones for XUL to easy? > The really interesting part with XUL is to use it as rich client, i.e. to > avoid rendering the complete page on each request, but only the parts

Re: Small dilemma: are Actions still recommended?

Sylvain Wallez wrote: Glen Ezkovich wrote: Cocooners, Working on some introductory documentation I ran into a slight dilemma. I want to mention how Cocoon is able to access either the model or a database in response to a request and produce a response based on the result. Because of its

Re: CForms Summer of Code project

Max Pfingsthorn wrote: Hi everyone! I've posted my preliminary proposal at http://wiki.apache.org/cocoon/GoogleSummerOfCode2005 Any comments are very welcome! The proposal looks very good to me, only one thing to add: Don't forget to refer to the project proposal --> http://wiki.apache.or

Re: CForms-XUL project information

Sure! On 6/14/05, Antonio Gallardo <[EMAIL PROTECTED]> wrote: > Hi Maksim, > > can you repost the proposal.html? See below what I got. > > Best Regards, > > Antonio Gallardo > CForms - XUL front-end project proposal Problem overview Cocoon CForms is a framework providing easy form-handli

Re: "CForms - XUL" Project proposal

Of course it is! Seems like you've taken it from my mind, just before I posted it :) On 6/14/05, Antonio Gallardo <[EMAIL PROTECTED]> wrote: > On Lun, 13 de Junio de 2005, 13:43, "Jörg Heinicke" dijo: > > Hello Maksim, > > > > isn't "just" converting the stylesheets for HTML to ones for XUL to ea