DO NOT REPLY [Bug 25381] - consistent line-endings for all text files

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25381

consistent line-endings for all text files





--- Additional Comments From [EMAIL PROTECTED]  2003-12-10 06:50 ---
While doing this cleanup, we need to ensure no conflicts with peoples' working
copies. This could happen with active areas of cvs and where people might have
un-committed changes. Here are warnings about the areas that are going to be
cleaned next:

src/blocks/webdav/samples/ ... many files
scratchpad/samples/sitemap-viewer/ ... many files
src/blocks/portal/samples/skins/ ... a few files

DO NOT REPLY [Bug 25381] New: - consistent line-endings for all text files

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25381

consistent line-endings for all text files

   Summary: consistent line-endings for all text files
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There have been many files in our CVSs that have non-UNIX end-of-line markers.
Apache CVS stores all files in UNIX format. However, some CVS clients allow
inconsistent line-endings to creep in. This propagates the problem to the
distributions and thence to the users. In some circumstances such
inconsistencies are known to cause runtime problems.

Here is some discussion about the issue:
 whitespace cleanup and efficiency drive
 http://marc.theaimsgroup.com/?t=10684399772

We are gradually fixing it following the guidelines in:
http://cocoon.apache.org/community/committer.html

This Bugzilla issue will help us to plan, fix, and monitor the problem.

Re: Bugzilla as project management tool

[David Crossley]

Bertrand Delacretaz wrote:
> Reinhard wrote:
> >
> > ...Of course nobody is forced to do anything but if you want to 
> > support our initiative...
> 
> So hopefully people will use this and don't let it slip into
> the "good idea never used it" category. I'm optimistic;-)

To lead by example is all that we can do. When the issue tracker
becomes something that we cannot do without, then it is working.

--David
(getting lonely talking to myself while the rest of the world sleeps)

Re: whitespace cleanup and efficiency drive

[David Crossley]

Okay, i now have the cocoon-2.2 CVS completely clean of
any dos2unix problems.

Now we are not going on a witch-hunt or anything, but ...

I have perceptions that there are some committers who use
CVS clients that don't handle the linefeed conversion properly.
It would be good to find those cases and get them fixed.

Occasionally i will run the "find|grep" stuff and report back.


As for the Cocoon-2.1 CVS, there are still many issues.
Gradually i have been fixing it, and notice Vadim doing some.

There are two big areas that need conversion and i want to
do those as a batch:
src/blocks/webdav/samples/
scratchpad/samples/sitemap-viewer/

How should i approach this? With the sitemap-viewer i can
probably just go ahead, but the webdav block potentially
has many people working on it.

Anyway, i am going to experiment with a Bugzilla task
to manage the line-endings issue.

--David

Re: Cocoon Contract Opportunity

[Ryan Hoegg]

Oh man.  I could have sworn I pasted the e-mail address.  Well, I better 
call it a night for e-mail then.

Vadim Gritsenko wrote:

Ryan Hoegg wrote:

Hello John,




If first one was whoops, then this one will be ... "Double WHOOPER"? ;-)

Vadim

RE: Bugzilla as project management tool

[David Crossley]

Reinhard Poetz wrote:
> Bertrand Delacretaz wrote:
> 
> > Hi Reinhard,
> > 
> > Thanks very much for setting this up!
> 
> You're welcome

Thanks to everyone involved in getting our issue tracking
into better shape.


> Big +1 for your precise explanation, this is exactly what I meant. I
> think we (as project) have to learn to find the balance and I'm very
> optimistic we'll find it!

Yes, this is all good progress in the management of such
an enormous project. I hope that someone finds time to turn
that into a guidelines document.

--David

Re: [POLL] Interest in unified code convention

[David Crossley]

Stephan Michels wrote:
> Bertrand Delacretaz wrote:
> 
> > I'm curious, I don't care much about code layout usually, but if
> > there's an automatic thing that doesn't get in the way, why not.
> 
> I, for myself, dump my code sometimes with a horrible indention
> and let the source formatter do the rest.
> 
> It will be a pain doing the formating the first time, so we should
> agree before on the convention.

I thought that we already agreed on the code convention following
the Whitespace thread.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106914945429276

--David

Re: [POLL] Interest in unified code convention

[David Crossley]

Stephan Michels wrote:
>
> after I made some positive experiences with jalopy, an open source
> code formatter, I want to offer install jalopy with a proposal
> for the our code convention.

What do you mean by "install"? In our CVS? Or does each committer
who wants to help, need to have it installed locally?

> This should be a welcome alternative to the various 'organize imports'
> and 'dos2unix' etc.
>
> What do'ya think?

As we discussed in the other "Whitepace" thread [1] there are
many issues with this, so we need to tread carefully. Imagine
that someone was doing major work on a certain component. When
they do a 'cvs update' then they would get massive cvs conflicts.

Perhaps we should practise with the cocoon-2.2 repository.

I am not sure what POLL means, but yes i am interested.
Thanks for exploring this.

[1] http://marc.theaimsgroup.com/?t=10684399772

--David

Re: Cocoon Contract Opportunity

[Vadim Gritsenko]

Ryan Hoegg wrote:

Hello John,




If first one was whoops, then this one will be ... "Double WHOOPER"? ;-)

Vadim

Re: Xindice 1.0 broken by XindiceEmbedded

[Vadim Gritsenko]

Andrew Savory wrote:

Hi,

On 9 Dec 2003, at 21:37, Upayavira wrote:

Have you got xmlrpc.jar included in your WEB-INF/lib? I had this prob 
earlier today, and adding that jar fixed it.


That solves the xmlrpc problem, but cocoon is not able to find my 
xindice server now:

Collection xmldb:xindice://localhost:4080/db/ not found


Because xindice 1.1 uses xmlrpc as communiction protocol with xindice:/ 
subprotocol, while xindice 1.0 uses CORBA, so this is expected too.

And to answer on your another email, even if xindice 1.1 final is 
released, it still won't talk to xindice 1.0. So, what would you do in 
this case?

Vadim

Re: Cocoon Contract Opportunity

[Ryan Hoegg]

Hello John,

As you may have noticed, I accidentally responded to the whole 
cocoon-dev list!  In any case, here is what I sent you:

I am interested in hearing more about the opportunity.  I am an 
independent software consultant, and XML, java, and Cocoon are among my 
specialties.  However, I would only be able to work about a week per 
month in Boston.  I am based in Oklahoma City and do most of my work 
remotely now.

My web site is currently being redone using Forrest and Cocoon, so it is 
not available now.  Is there a good time tomorrow for me to call to 
discuss the position further?

Thanks,
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
[EMAIL PROTECTED] wrote:

Hi,
We currently have a Cocoon Architect/Engineer Contract position available in
the Boston area.
Must have 2 years minimum of Cocoon experience with strong Java and
Architecture.
If you or someone you know may be interested please email or call me at the
number below.
Thanks,
John
John T. Dunlevy
Sr. Consultant
JVT Advisors
35 New England Business Center
Andover, MA  01810
Direct (978) 557-7102
Main (978) 683-4555
[EMAIL PROTECTED]
www.jvtadvisors.com
 

[WHOOPS] Re: Cocoon Contract Opportunity

[Ryan Hoegg]

Well, sorry I sent this to the whole list!

Ryan Hoegg wrote:

Hello John,

I am interested in hearing more about the opportunity.  I am an 
independent software consultant, and XML, java, and Cocoon are among 
my specialties.  However, I would only be able to work about a week 
per month in Boston.  I am based in Oklahoma City and do most of my 
work remotely now.

My web site is currently being redone using Forrest and Cocoon, so it 
is not available now.  Is there a good time tomorrow for me to call to 
discuss the position further?

Thanks,
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
[EMAIL PROTECTED] wrote:

Hi,
We currently have a Cocoon Architect/Engineer Contract position 
available in
the Boston area.
Must have 2 years minimum of Cocoon experience with strong Java and
Architecture.
If you or someone you know may be interested please email or call me 
at the
number below.
Thanks,
John

John T. Dunlevy
Sr. Consultant
JVT Advisors
35 New England Business Center
Andover, MA  01810
Direct (978) 557-7102
Main (978) 683-4555
[EMAIL PROTECTED]
www.jvtadvisors.com
 

Re: Cocoon Contract Opportunity

[Ryan Hoegg]

Hello John,

I am interested in hearing more about the opportunity.  I am an 
independent software consultant, and XML, java, and Cocoon are among my 
specialties.  However, I would only be able to work about a week per 
month in Boston.  I am based in Oklahoma City and do most of my work 
remotely now.

My web site is currently being redone using Forrest and Cocoon, so it is 
not available now.  Is there a good time tomorrow for me to call to 
discuss the position further?

Thanks,
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
[EMAIL PROTECTED] wrote:

Hi,
We currently have a Cocoon Architect/Engineer Contract position available in
the Boston area.
Must have 2 years minimum of Cocoon experience with strong Java and
Architecture.
If you or someone you know may be interested please email or call me at the
number below.
Thanks,
John
John T. Dunlevy
Sr. Consultant
JVT Advisors
35 New England Business Center
Andover, MA  01810
Direct (978) 557-7102
Main (978) 683-4555
[EMAIL PROTECTED]
www.jvtadvisors.com
 

Re: [FYI] store bug

[Sam Coward]

Geoff Howard wrote:

Sylvain Wallez wrote:

Borges Charles wrote:

Fixing the following excalibur store bug should increasing performance:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25122
currently picking cached items from the persistent store is of any 
help because it's always returning null value.

Are we sure the code in that bug is used?  We use the JISP 
implementation which I would assume has overridden that method? 
Looks like. The JISP implementation only overrides doGet()

Sam

Re: Xindice 1.0 broken by XindiceEmbedded

[Andrew Savory]

Hi,

On 9 Dec 2003, at 21:37, Upayavira wrote:

Have you got xmlrpc.jar included in your WEB-INF/lib? I had this prob 
earlier today, and adding that jar fixed it.
That solves the xmlrpc problem, but cocoon is not able to find my 
xindice server now:

	Collection xmldb:xindice://localhost:4080/db/ not found

Upayavira, who is taking a break from Lord of the Rings on DVD while 
his wife chats on the phone
You need a break with the DVD - it's too long!

Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

Re: Xindice 1.0 broken by XindiceEmbedded

[Andrew Savory]

Hi,

On 9 Dec 2003, at 21:47, Vadim Gritsenko wrote:

Remove one of those (if you want to use 1.0 - remove 1.1), and use 
just one version. Remove also reference in xconf to the new class - 
o.a.x.c.embed.DatabaseImpl - it is not present in 1.0
Yes, I know that works as I did that in order to check the cause of the 
problem in the first place. My concern is that there may be people out 
there (like me!) already using Cocoon 2.1 with standalone XIndice 1.0. 
For these people, the new embedded xindice will cause Cocoon to break 
with no explanation. This is not a good thing - especially given the 
decisions on this list to focus only on -released- versions of 
software.

I guess our options are:

1) document the problem, stick with embedded xindice (good because we 
get latest xindice, bad because we quietly break existing sites)
2) disable embedded xindice by default (good because it means 
everything works as with previous cocoon 2.1.* releases, bad because we 
miss out on embedded functionality and xindice sample)
3) Do it some other way?

Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

Cocoon Contract Opportunity

[john]

Hi,
We currently have a Cocoon Architect/Engineer Contract position available in
the Boston area.
Must have 2 years minimum of Cocoon experience with strong Java and
Architecture.
If you or someone you know may be interested please email or call me at the
number below.
Thanks,
John

John T. Dunlevy
Sr. Consultant
JVT Advisors
35 New England Business Center
Andover, MA  01810
Direct (978) 557-7102
Main (978) 683-4555
[EMAIL PROTECTED]
www.jvtadvisors.com

DO NOT REPLY [Bug 25308] - Enum convertor

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25308

Enum convertor

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 25113] - CocoonForms - future releases

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25113

CocoonForms - future releases

This bug depends on bug 25308, which changed state:

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

DO NOT REPLY [Bug 25308] - Enum convertor

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25308

Enum convertor

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

Re: [cforms] Renaming party for union, etc.

[Sylvain Wallez]

Timothy Larson wrote:

For anybody who been following the class, new, struct, and union discussion, will you 
help choose intuitive names for these new features?
Description: http://wiki.cocoondev.org/attach?page=TimLarson
Patch: http://wiki.cocoondev.org/attach?page=TimLarson%2Fwoody_union.diff
I am thinking of changing:
 "union"->"selector", "selection", "choose", "choice", etc.
 "struct"->"container"
 "class"->"define" or leave as "class"
 "new"->"use", "instance", or leave as "new"
Note that the concept currently called "class" may be reused in a global widget definition repository, and that the concept currently called "new" may be extended to allow it to provide customization parameters or elements to the definitions it creates instances of.

What names do you all suggest?  The names will be used for the parallel concepts in the form definition, template, and binding.  It would be nice to get the names settled for the next patch before this gets committed.
 

Tim, I would do it the opposite way: commit the patch so that people can 
play with it. Reading docs is good but we also need to get our hands on 
it to fully understand the underlying concepts and find good names for them.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: [FYI] store bug

[Vadim Gritsenko]

Sylvain Wallez wrote:

Borges Charles wrote:

Hi,

Fixing the following excalibur store bug should increasing performance:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25122
currently picking cached items from the persistent store is of any 
help because it's always returning null value.
 

Wow, weird! This means that the memory store was the only one really 
useful. Being limited to 100 objects in the default sitemap, that 
doesn't make an efficient cache...

Our store *really* needed some enhancements. I'm currently working on 
it, and will commit your patch very soon along with the other 
modifications I proposed.


Another weird thing - excalibur repository does not has any history. 
Anybody knows why, or anybody knows where's the history?

Vadim

Re: [FYI] store bug

[Geoff Howard]

Sylvain Wallez wrote:
Borges Charles wrote:

Hi,

Fixing the following excalibur store bug should increasing performance:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25122
currently picking cached items from the persistent store is of any 
help because it's always returning null value.
 

Wow, weird! This means that the memory store was the only one really 
useful. Being limited to 100 objects in the default sitemap, that 
doesn't make an efficient cache...

Our store *really* needed some enhancements. I'm currently working on 
it, and will commit your patch very soon along with the other 
modifications I proposed.
Are we sure the code in that bug is used?  We use the JISP 
implementation which I would assume has overridden that method?

Geoff

Re: Xindice 1.0 broken by XindiceEmbedded

[Vadim Gritsenko]

Andrew Savory wrote:

As near as I can tell, there's a conflict between the two xindice 
jars.  With xindice-1.1b1.jar present as well as xindice.jar, I get:


You can't do anything meaningful with two very different versions of the 
software in the very same package. That's like installing windows 3.1 
and windows 95 in one directory and wondering why windows 3.1 stopped 
working. Or like having cocoon-1.7 and cocoon-2.1 both in the classpath: 
it will never work.

Remove one of those (if you want to use 1.0 - remove 1.1), and use just 
one version. Remove also reference in xconf to the new class - 
o.a.x.c.embed.DatabaseImpl - it is not present in 1.0

Vadim

Re: Xindice 1.0 broken by XindiceEmbedded

[Upayavira]

Have you got xmlrpc.jar included in your WEB-INF/lib? I had this prob 
earlier today, and adding that jar fixed it.

Regards,

Upayavira, who is taking a break from Lord of the Rings on DVD while his 
wife chats on the phone

Andrew Savory wrote:

Hi,

I've been trying to get a site that uses Xindice 1.0 running using  
Cocoon 2.1 HEAD, and it seems that the recent changes in the xmldb  
block have broken things :-(

As near as I can tell, there's a conflict between the two xindice 
jars.  With xindice-1.1b1.jar present as well as xindice.jar, I get:

java.lang.NoClassDefFoundError: org/apache/xmlrpc/XmlRpc
at  
org.apache.xindice.client.xmldb.xmlrpc.CollectionImpl.(CollectionI 
mpl.java:128)
at  
org.apache.xindice.client.xmldb.xmlrpc.DatabaseImpl.getCollection(Databa 
seImpl.java:155)
at  
org.apache.xindice.client.xmldb.DatabaseImpl.getCollection(DatabaseImpl. 
java:155)
at org.xmldb.api.DatabaseManager.getCollection(Unknown Source)
at  
org.apache.cocoon.components.source.impl.XMLDBSource.collectionToSAX(XML 
DBSource.java:263)
at  
org.apache.cocoon.components.source.impl.XMLDBSource.toSAX(XMLDBSource.j 
ava:200)
at  
org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java: 
261)
at  
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java: 
141)


I haven't yet figured out what's going on, but we might want to roll  
back the xindice embedded stuff - xindice 1.1 is not released, and 
this  breaks compatibility with existing sites using Cocoon and the 
released  version of xindice.

Alternatively, has anyone got the two working side-by-side?

Thoughts?

Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

Re: Remove XPath from XMLResourceBundle

[Bruno Dumon]

On Tue, 2003-12-09 at 22:32, Vadim Gritsenko wrote:
> More i18n related classes - XMLResourceBundleFactory and XMLResourceBundle.
> 
> I'd like to remove all XPath business from these classes (as it was not 
> used anyway) and commit simplier (and faster) SaxBuffer-based 
> implementation with fixed dictionary syntax, which is used today by i18n 
> transformer:

+1, exactly my thoughts

> 
> 
>   b
> 
> 
> If somebody is using today's XMLResourceBundle implementation -- please 
> yell! :)
> 
> Vadim
-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Xindice 1.0 broken by XindiceEmbedded

[Andrew Savory]

Hi,

I've been trying to get a site that uses Xindice 1.0 running using  
Cocoon 2.1 HEAD, and it seems that the recent changes in the xmldb  
block have broken things :-(

As near as I can tell, there's a conflict between the two xindice jars.  
With xindice-1.1b1.jar present as well as xindice.jar, I get:

java.lang.NoClassDefFoundError: org/apache/xmlrpc/XmlRpc
at  
org.apache.xindice.client.xmldb.xmlrpc.CollectionImpl.(CollectionI 
mpl.java:128)
at  
org.apache.xindice.client.xmldb.xmlrpc.DatabaseImpl.getCollection(Databa 
seImpl.java:155)
at  
org.apache.xindice.client.xmldb.DatabaseImpl.getCollection(DatabaseImpl. 
java:155)
at org.xmldb.api.DatabaseManager.getCollection(Unknown Source)
at  
org.apache.cocoon.components.source.impl.XMLDBSource.collectionToSAX(XML 
DBSource.java:263)
at  
org.apache.cocoon.components.source.impl.XMLDBSource.toSAX(XMLDBSource.j 
ava:200)
at  
org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java: 
261)
at  
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java: 
141)


I haven't yet figured out what's going on, but we might want to roll  
back the xindice embedded stuff - xindice 1.1 is not released, and this  
breaks compatibility with existing sites using Cocoon and the released  
version of xindice.

Alternatively, has anyone got the two working side-by-side?

Thoughts?

Andrew.

--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/

Remove XPath from XMLResourceBundle

[Vadim Gritsenko]

More i18n related classes - XMLResourceBundleFactory and XMLResourceBundle.

I'd like to remove all XPath business from these classes (as it was not 
used anyway) and commit simplier (and faster) SaxBuffer-based 
implementation with fixed dictionary syntax, which is used today by i18n 
transformer:


 b

If somebody is using today's XMLResourceBundle implementation -- please 
yell! :)

Vadim

Re: [cforms] Renaming party for union, etc.

[Bruno Dumon]

On Mon, 2003-12-08 at 18:02, Timothy Larson wrote:
> For anybody who been following the class, new, struct, and union discussion,
> will you help choose intuitive names for these new features?
> Description: http://wiki.cocoondev.org/attach?page=TimLarson
> Patch: http://wiki.cocoondev.org/attach?page=TimLarson%2Fwoody_union.diff
> 
> I am thinking of changing:
>   "union"->"selector", "selection", "choose", "choice", etc.
>   "struct"->"container"
>   "class"->"define" or leave as "class"
>   "new"->"use", "instance", or leave as "new"
> 
> Note that the concept currently called "class" may be reused in a global
> widget definition repository, and that the concept currently called "new"
> may be extended to allow it to provide customization parameters or elements
> to the definitions it creates instances of.
> 
> What names do you all suggest?  The names will be used for the parallel
> concepts in the form definition, template, and binding.  It would be nice
> to get the names settled for the next patch before this gets committed.

I would keep the current names (union, struct, class, new).

-- 
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED]  [EMAIL PROTECTED]

Re: [FYI] store bug

[Sylvain Wallez]

Borges Charles wrote:

Hi,

Fixing the following excalibur store bug should increasing performance:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25122
currently picking cached items from the persistent store is of any help because it's always returning null value.
 

Wow, weird! This means that the memory store was the only one really 
useful. Being limited to 100 objects in the default sitemap, that 
doesn't make an efficient cache...

Our store *really* needed some enhancements. I'm currently working on 
it, and will commit your patch very soon along with the other 
modifications I proposed.

Thanks,
Sylvain
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Drop MirrorRecorder

[Vadim Gritsenko]

Hi all,

While revamping i18n found this curious thing -- 
o.a.c.transformation.helpers.MirrorRecorder. New i18n transformer will 
no longer use this class, and will be based on SaxBuffer instead.

Is there anybody or anything using this MirrorRecorder? Please yell 
before I kill it...

Vadim

Re: Woody repeater binding

[Marc Portier]

Jan,
(and copying dev since we're having some repeater-binding related 
discussions there lately)

congrats with another very sensible use case, you seem to be building a 
catalog of those :-) pls keep 'em comming

as for the issue at hand, I'm a bit afraid it's a no go here and now.

1/ purely declaratively in the binding-def file this would require a 
more self-contained description of the binding used for the unique-key stuff

(if you check the code of the repeater-binding you would see that it 
uses a simple value-binding to do the binding of the unique-id to/from 
the unique-path)

if we could allow for letting this unique-id-binding be user defined 
through some nested


  here goes your binding declaration...
then we are already half way there...
(for your case you could then use a nested aggregate binding or even the 
new struct-container from Timothy)

2/ finally implementation-wise this would call for a change in the 
interface of the binding... next to load() and save() methods we would 
need some hasMatchingValue() check method that can be used for the 
matching of the values

(currenlty the repeater impl also remembers the unique-id and -path and 
abuses that do the matching on a more direct level. By introducing the 
new check-method we can keep on hiding those details into the 
specialized binding itself)

hope this makes sense?
unfortunately I can't work on this before friday, I do hope it's not 
blocking your activity

regards,
-marc=
Jan Hoskens wrote:

Hi,
 
I'm trying to bind an XML document to my woody form. The repeater 
requires a unique-row-id and unique-path for every row. My rows do not 
have one unique attribute but they do have a unique combination of 
attributes. e.g:
   

 
The two attributes together do define a unique row, but each attribute 
apart is not unique. Is there any way to use these attributes together 
as my 'row-identifier' or do I have to create an extra unique attribute?
 
Greetings
 
Jan
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]

[FYI] store bug

[Borges Charles]

Hi,

Fixing the following excalibur store bug should
increasing performance:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25122

currently picking cached items from the persistent
store is of any help because it's always returning
null value.

Charles Borges





Do You Yahoo!? -- Avec Yahoo! soyez au coeur de la récolte de dons pour le Téléthon.
http://fr.promotions.yahoo.com/caritatif/

Re: [POLL] Interest in unified code convention

[Timothy Larson]

--- Bertrand Delacretaz <[EMAIL PROTECTED]> wrote:
> Le Mardi, 9 déc 2003, à 17:56 Europe/Zurich, Stephan Michels a écrit :
> > Ant target, like 'ant format'.
> Which one has to run manually, right?
> If so I'm +0.5, provided that we still allow "unformatted" code in CVS.

+1 for 'ant format' target
 
> For me the "ant format" task should be a tool that people run when they 
> feel like cleaning up, not something that is forced on them.

+1  Those who care can run it, the rest can approximate it by hand.

--Tim Larson


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

Re: [POLL] Interest in unified code convention

[Bertrand Delacretaz]

Le Mardi, 9 déc 2003, à 17:56 Europe/Zurich, Stephan Michels a écrit :

On Tue, 9 Dec 2003, Bertrand Delacretaz wrote:
...Can you explain how it would be used? CVS preprocessor? ant task 
that
everybody has to (painfully) run before every commit?
Ant target, like 'ant format'.
Which one has to run manually, right?
If so I'm +0.5, provided that we still allow "unformatted" code in CVS.
For me the "ant format" task should be a tool that people run when they 
feel like cleaning up, not something that is forced on them.

-Bertrand

Re: [POLL] Interest in unified code convention

[Stephan Michels]

On Tue, 9 Dec 2003, Bertrand Delacretaz wrote:

> Le Mardi, 9 déc 2003, à 16:24 Europe/Zurich, Stephan Michels a écrit :
>
> > ...after I made some positive experiences with jalopy, an open source
> > code formatter, I want to offer install jalopy with a proposal
> > for the our code convention
>
> Can you explain how it would be used? CVS preprocessor? ant task that
> everybody has to (painfully) run before every commit?

Ant target, like 'ant format'.

> I'm curious, I don't care much about code layout usually, but if
> there's an automatic thing that doesn't get in the way, why not.

I, for myself, dump my code sometimes with a horrible indention
and let the source formatter do the rest.

It will be a pain doing the formating the first time, so we should
agree before on the convention.

Stephan.

Re: [POLL] Interest in unified code convention

[Vadim Gritsenko]

Timothy Larson wrote:

--- Stephan Michels <[EMAIL PROTECTED]> wrote:
 

Hi,

after I made some positive experiences with jalopy, an open source
code formatter, I want to offer install jalopy with a proposal
for the our code convention.
This should be a welcome alternative to the various 'organize imports'
and 'dos2unix' etc.
What do'ya think?
   

Worth a try.


Is it possible to (and should we?) install this as a filter in front
of cvs to ensure that it is invoked/enforced without extra effort from
the developers?
 

No, we should not.

Vadim

Re: [POLL] Interest in unified code convention

[Bertrand Delacretaz]

Le Mardi, 9 déc 2003, à 16:24 Europe/Zurich, Stephan Michels a écrit :

...after I made some positive experiences with jalopy, an open source
code formatter, I want to offer install jalopy with a proposal
for the our code convention
Can you explain how it would be used? CVS preprocessor? ant task that 
everybody has to (painfully) run before every commit?

I'm curious, I don't care much about code layout usually, but if 
there's an automatic thing that doesn't get in the way, why not.

-Bertrand

Re: [POLL] Interest in unified code convention

[Timothy Larson]

--- Stephan Michels <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> after I made some positive experiences with jalopy, an open source
> code formatter, I want to offer install jalopy with a proposal
> for the our code convention.
> 
> This should be a welcome alternative to the various 'organize imports'
> and 'dos2unix' etc.
> 
> What do'ya think?

Is it possible to (and should we?) install this as a filter in front
of cvs to ensure that it is invoked/enforced without extra effort from
the developers?

--Tim Larson


__
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

[POLL] Interest in unified code convention

[Stephan Michels]

Hi,

after I made some positive experiences with jalopy, an open source
code formatter, I want to offer install jalopy with a proposal
for the our code convention.

This should be a welcome alternative to the various 'organize imports'
and 'dos2unix' etc.

What do'ya think?

Stephan Michels.

RE: Bugzilla as project management tool

[Reinhard Poetz]

From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]

> Hi Reinhard,
> 
> Thanks very much for setting this up!

You're welcome

> If people here "bite" (*and* do the underlying
> implementations ;-) I'm 
> sure this will be a big help for project coordination.
> 
> Basically what you suggest is "if you're working on something it must
> be an issue in bugzilla" - I like this rule, it helps a lot in 
> answering the "projects questions" that we discussed at the GT.

Yep

> 
> But as you say
> > ...Of course nobody is forced to do anything but if you want to 
> > support our initiative...
> 
> So hopefully people will use this and don't let it slip into
> the "good 
> idea never used it" category. I'm optimistic;-)

I'm optimistic too :-)

> But I think we must be careful about this:
> 
> > ... - if you want to comment on a certain issue don't use
> the mailing
> > list
> >but enter your comments directly into Bugzilla
> >(for software design e.g. the way we developed Blocks the mailing
> > list is still the way to go, at least IMHO)...
> 
> I know there is reluctance to move discussions from the
> mailing list to 
> bugzilla, and having one more "discussion place" (besides lists, wiki 
> and IRC) might fragment discussions.
> 
> Maybe we should:
> a) Keep discussions on the list, unless they are very specific to a
> particular bugzilla issue.
> 
> By "very specific" I mean "of no interest to people who are
> not working 
> on this issue". Hard to decide for sure, it's a question of balance. 
> People can add themselves in CC to specific issues anyway if 
> they want 
> to be sure to follow the discussions.
> 
> b) Document in bugzilla the *outcome* of discussions, with
> links to the 
> mail archives.
> This is already happening and I like it, see issues 25286 and 
> 25285 for 
> example.
> 
> c) In mailing list discussions, include the bugzilla issue
> number like 
> [23454] for cross-referencing.
> 
> It is certainly hard to find a balance between "everything in the
> lists" and "everything in bugzilla", basically, what I 
> suggest is "free 
> talk on the lists" and "documented decisions in bugzilla".
> 
>  From what you wrote, I think you agree but wanted to make
> sure we're on 
> the same page.

Big +1 for your precise explanation, this is exactly what I meant. I
think we (as project) have to learn to find the balance and I'm very
optimistic we'll find it!

--
Reinhard

DO NOT REPLY [Bug 25321] - Cocoon Roadmap - NEXT release

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25321

Cocoon Roadmap - NEXT release

[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||25359

DO NOT REPLY [Bug 25359] - General roadmap - NEXT release

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25359

General roadmap - NEXT release

[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||25321
  nThis||
   Severity|Normal  |Enhancement

DO NOT REPLY [Bug 25359] New: - General roadmap - NEXT release

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25359

General roadmap - NEXT release

   Summary: General roadmap - NEXT release
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Collection issue for all _general_ issues which should be part of the next
release (enhancements to be finished, bugs to be solved, ... or simply issues
that have the be finished before the next release)

DO NOT REPLY [Bug 25356] - [Slide block] Revamping of Slide integration

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25356

[Slide block] Revamping of Slide integration

[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||25358
  nThis||

DO NOT REPLY [Bug 25320] - Cocoon Roadmap

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25320

Cocoon Roadmap

[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||25358

DO NOT REPLY [Bug 25358] New: - General roadmap - FUTURE releases

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25358

General roadmap - FUTURE releases

   Summary: General roadmap - FUTURE releases
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Collection issue for all general issues which are not urgent (so that we
remember them in the future)

Re: Bugzilla as project management tool

[Bertrand Delacretaz]

Le Mardi, 9 déc 2003, à 10:32 Europe/Zurich, Unico Hommes a écrit :

...Just one request though. Can somebody add 'current CVS 2.2' to 
version
list?
done.
-Bertrand

RE: Bugzilla as project management tool

[Unico Hommes]

Ok, I think this is actually a very good idea. I am starting to be
impressed with Bugzilla. At work we have been using Jira issue tracking
system in a similar way with good results. I don't have nearly enough
experience with either to do a good comparison but as far as I can see
Bugzilla does a great job for Cocoon. 

Just one request though. Can somebody add 'current CVS 2.2' to version
list?

Thanks, Unico

> -Original Message-
> From: Reinhard Poetz [mailto:[EMAIL PROTECTED] 
> Sent: maandag 8 december 2003 15:45
> To: [EMAIL PROTECTED]
> Subject: Bugzilla as project management tool
> 
> 
> After a discussion between Andrew, Betrand and me I started 
> to use Bugzilla as project management tool for CocoonForms 
> and Flowscript. We have the hope that Bugzilla makes it 
> easier for us to get an overview of all open tasks and this 
> should also give our users a sense of when they can expect a 
> certain new feature.
> 
> I started with CocoonForms and Flowscript but other roadmap 
> components (e.g. Portal engine, ...) would be more than 
> welcome. Please have a look at 
> http://wiki.cocoondev.org/Wiki.jsp?page=ProjectManagement 
> where you find some links to the roadmap and you'll also find 
> information concerning the way we manage our project (at 
> least all the things I'm aware of ;-)
> 
> 
> So what does this mean for you?
> ---
> Of course nobody is forced to do anything but if you want to 
> support our initiative
> 
>  - enter all the things you're working on into Bugzilla
>and connect them with the target issue
>e.g. I work on intercepted flowscript so I entered a new
>issue: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25325
>and selected "Flowscript" as the component it belongs to.
> 
>Then I added issue 25284 as issue which is blocked by my issue.
>(issue 25284 is "[Roadmap] Flowscript - FUTURE releases")
> --> this means I don't know when it will be finished ;-)
> 
>  - if you don't find an appropriate component in Bugzilla (like core,
>CocoonForms, Flowscript, ...) ask Carsten, Giacome, Betrand or
>me to create a new one
> 
>  - if you want to comment on a certain issue don't use the 
> mailing list
>but enter your comments directly into Bugzilla
>(for software design e.g. the way we developed Blocks the mailing
> list is still the way to go, at least IMHO)
> 
> 
> If you wonder why we need this?
> ---
> I hope it's not (too much) bureaucracy but
> 
>  - gives much better overview
>  - reduces the danger of duplication of our efforts
>because two people are working on the same issue
>  - people who don't follow the dev-list very closly
>can also get an overview of the current project status
>without having to subscribe
>  - our users can vote on a feature they really need 
>(every user can vote on 30 features now)
>  - good ideas don't get lost in the mail archives
> 
> 
> There is always room for improvment so I'm waiting curious 
> for your comments!
> 
> Cheers,
> Reinhard
> 
> 
> 

Re: About cocoon.apache-korea.org

[Steven Noels]

On Dec 5, 2003, at 12:43 PM, Min Kye Seon wrote:

I'm keyseon, Min and a Korean.
Hi!

I am a korean undergraduate and I am running , managing, and 
translating cocoon.apache-korea.org with korean.
The cocoon.apache-korea.org is translation site with korean.
Since I have sutdied Cocoon, I thought it is good Cocoon is activated 
and I hope to help some korean developers or user use Cocoon easily. 
So I established the cocoon.apache-korea.org in october, 2003 and 
Translating Cocoon documentation with korean began at november.
The cocoon.apache-korea.org is began from apache-kore.org. 
apache-kore.org is the translating project of a number of apache 
projects.
Now, http://jakarta.apache-korea.org, http://ant.apache-korea.org, 
http://cocoon.apache-korea.org, http://xml.apache-korea.org is active.

I am translating cocoon.apache.org.
Thanks for your interest in the Cocoon project. Given the fact we (the 
Cocoon development community) cannot provide oversight over languages 
we cannot read/understand, we are a bit nervous about seeing this 
hosted outside Apache, moreover since it looks very Apache-like: both 
domain name and layout make it appear as if it is official Apache 
documentation. This is bad and we feel it should change.

Therefore, I would suggest to change the layout and put a sufficiently 
clear warning on these pages that the content of your site is _not_ 
officially endorsed or supported by the Cocoon project. It seems that 
you are using Forrest, so this might be just a matter of changing your 
skin to some extent.

We applaud however every effort to make information about Cocoon 
available in other languages, so if you have ideas on how we can 
cooperate on this, please feel very welcome on this list. We might open 
a 'foreign language' section on our website, linking to initiatives 
such as yours: we will not endorse however any effort which hasn't been 
proposed and debated on this list.

Moreover, I am developing some Cocoon tools for cocooners.
The C-tracer following the idea Mr. Arje Cahn is distributed in 
http://cocoon.apache-korea.org/application/c-tracer.html Also, I am 
developing Cocoon Sitemap Editor as struts-config.xml editor of Struts 
and making progress 80%.
Thanks.
What are your future plans with regards to this software? Under what 
license will these tools be made available?


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java & XMLAn Orixo Member
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org

DO NOT REPLY [Bug 25356] New: - [Slide block] Revamping of Slide integration

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25356

[Slide block] Revamping of Slide integration

   Summary: [Slide block] Revamping of Slide integration
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


A lot of code in this block was out-of-date. I have started refactoring some of
it. Most notable tasks have been: 
- loose deprecated interfaces in SlideSource, SourceDescriptionGenerator
- upgrade to latest Slide libraries
- move samples to use flow instead of actions

Re: Bugzilla as project management tool

[Bertrand Delacretaz]

Hi Reinhard,

Thanks very much for setting this up!
If people here "bite" (*and* do the underlying implementations ;-) I'm 
sure this will be a big help for project coordination.

Basically what you suggest is "if you're working on something it must 
be an issue in bugzilla" - I like this rule, it helps a lot in 
answering the "projects questions" that we discussed at the GT.

But as you say
...Of course nobody is forced to do anything but if you want to 
support our
initiative...
So hopefully people will use this and don't let it slip into the "good 
idea never used it" category. I'm optimistic;-)

But I think we must be careful about this:

... - if you want to comment on a certain issue don't use the mailing 
list
   but enter your comments directly into Bugzilla
   (for software design e.g. the way we developed Blocks the mailing
list is still the way to go, at least IMHO)...
I know there is reluctance to move discussions from the mailing list to 
bugzilla, and having one more "discussion place" (besides lists, wiki 
and IRC) might fragment discussions.

Maybe we should:
a) Keep discussions on the list, unless they are very specific to a 
particular bugzilla issue.

By "very specific" I mean "of no interest to people who are not working 
on this issue". Hard to decide for sure, it's a question of balance. 
People can add themselves in CC to specific issues anyway if they want 
to be sure to follow the discussions.

b) Document in bugzilla the *outcome* of discussions, with links to the 
mail archives.
This is already happening and I like it, see issues 25286 and 25285 for 
example.

c) In mailing list discussions, include the bugzilla issue number like 
[23454] for cross-referencing.

It is certainly hard to find a balance between "everything in the 
lists" and "everything in bugzilla", basically, what I suggest is "free 
talk on the lists" and "documented decisions in bugzilla".

From what you wrote, I think you agree but wanted to make sure we're on 
the same page.

-Bertrand

DO NOT REPLY [Bug 25352] - Ignore "annotations" namespace in the sitemap

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25352

Ignore "annotations" namespace in the sitemap





--- Additional Comments From [EMAIL PROTECTED]  2003-12-09 08:52 ---
Added to bug #25351 dependencies, as this will be a first step towards
self-documenting samples.

DO NOT REPLY [Bug 25352] New: - Ignore "annotations" namespace in the sitemap

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25352

Ignore "annotations" namespace in the sitemap

   Summary: Ignore "annotations" namespace in the sitemap
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: general components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


As discussed in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107063598723431&w=2

DO NOT REPLY [Bug 25322] - Cocoon Roadmap - FUTURE releases

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25322

Cocoon Roadmap - FUTURE releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||25351

DO NOT REPLY [Bug 25351] - Documentation roadmap - FUTURE releases

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25351

Documentation roadmap - FUTURE releases

[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||25322
  nThis||
   Severity|Normal  |Enhancement

DO NOT REPLY [Bug 25351] New: - Documentation roadmap - FUTURE releases

[bugzilla]

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=25351

Documentation roadmap - FUTURE releases

   Summary: Documentation roadmap - FUTURE releases
   Product: Cocoon 2
   Version: Current CVS 2.1
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Collection issue for all documentation issues which are not urgent (so that we
remember them in the future)

Re: [cforms] Renaming party for union, etc.

[Marc Portier]

Timothy Larson wrote:
For anybody who been following the class, new, struct, and union discussion,
will you help choose intuitive names for these new features?
Description: http://wiki.cocoondev.org/attach?page=TimLarson
Patch: http://wiki.cocoondev.org/attach?page=TimLarson%2Fwoody_union.diff
I am thinking of changing:
  "union"->"selector", "selection", "choose", "choice", etc.
choice is my choice :-)

  "struct"->"container"
ok, although 'composed' comes to mind too
in fact, I'm starting to think this has some overlap with the aggregate 
widget, no?

  "class"->"define" or leave as "class"
  "new"->"use", "instance", or leave as "new"
I would stick to class and new, but that's showing a Java bias
I'm ok for define and use if people find it more intuitive
Note that the concept currently called "class" may be reused in a global
widget definition repository, and that the concept currently called "new"
may be extended to allow it to provide customization parameters or elements
to the definitions it creates instances of.
What names do you all suggest?  The names will be used for the parallel
concepts in the form definition, template, and binding.  It would be nice
to get the names settled for the next patch before this gets committed.

regards,
-marc=
--
Marc Portierhttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED]  [EMAIL PROTECTED]