On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote: > Marc Portier wrote: > > >another argument for having [cforms] from my side was that you could > >never confuse it with the known english word 'form' that could mean an > >HTML form, a paper-form, a whatever formalism or whatnot... in > >discussions on these lists, and thus possibly introducing confusion that > >can be avoided > > I find myself selfdebating here. > > I'm 60% on forms "everywhere" and 40% on +1 the proposal. > > the reason for using "forms" everywhere is that I want people to fight > for having their features in, instead of going their own way with > another block.
Understood, and I agree with the motivation. > Scratchpad blocks are awesome as a way to cover new ground and propose > new functionality, but once we start supporting them officially, well, > the things change. > > This is why the name change: > > - woody was a proposal > - Cocoon Forms are *the way* cocoon is going to handle forms from now on > > in a few years, there might be nothing left from woody in Cocoon Forms. > > Now, as I was explaining in IRC today, the scenario I want to avoid is > people coming up with, say "sforms" or "cform++" or "cform#" and branch off. > > This is my *only* concern. > > I would go "forms" all the way, in everything: namespaces and package > names... but Marc is right: "form" is too general as a term. We could do > it with sitemap or flowscript because they were descriptive yet special > enough. Forms clearly not descriptive enough. My main concern is about support and searching. 'Form' does not clarify which major version is being refered to so it could be hard to quickly find help for the right major version, since people are notorious for mentioning the package but not the version in their emails. > So, let's go over the proposal again: > > Block Title: Cocoon Forms, or Cocoon Forms 1.0 > > +1 for Cocoon Forms (no need to mention the version now) +1 As agreed previously. > Block Name: cforms > > +1, I would like forms better but we need to state cforms somewhere +1 cforms block solves the support/search issue mentioned above. > Package: org.apache.cocoon.cforms > > here I would go "forms" instead. package naming is where the estate > really is, where class collissions might happen. I understand how this seems like a good place for the battleground, but to introduce a new winner it looks like this would force us to break code compiled against the previous major version because we would be stealing the class and interface names for the new version. Does the new block system somehow solve this problem like via classloaders or something else? > Namespace: http://apache.org/cocoon/forms/definition/1.0 > > +1 +1 > NS Prefix: fd > > +0, doesn't really matter. +0 sounds fine, not much opinion. > So, to sum up, here is my proposal: > > -------------------------------------------------------- > Block Title: Cocoon Forms > Block Name: cforms > Package: org.apache.cocoon.forms > Namespace: http://apache.org/cocoon/forms/definition/1.0 > -------------------------------------------------------- > > -- > Stefano. --Tim Larson
