I was looking at http://wiki.apache.org/cocoon/WhiteBoardCocoonForms and I liked
what I saw.
This document defines reusable macro libraries. I'm sure this is useful for some
usecases (e.g. editors) but I have a simpler one that goes into the direction of
reusable form definitions.
In many of
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33874.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33874.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25121.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Reinhard Poetz wrote:
I was looking at http://wiki.apache.org/cocoon/WhiteBoardCocoonForms
and I liked what I saw.
This document defines reusable macro libraries. I'm sure this is
useful for some usecases (e.g. editors) but I have a simpler one that
goes into the direction of reusable form
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33896.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33896.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33896.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Daniel Fagerstrom wrote:
Are you refering to the idea of having a configurable OM? I found it
initially to be FS, but everybody else that was involved in the
discussion wanted it, so I based my proposal on it. Carsten wanted it
for giving access to some portal specific data for portal use
Daniel Fagerstrom wrote:
Reinhard Poetz wrote:
I was looking at http://wiki.apache.org/cocoon/WhiteBoardCocoonForms
and I liked what I saw.
This document defines reusable macro libraries. I'm sure this is
useful for some usecases (e.g. editors) but I have a simpler one that
goes into the
What do you think about removing the scratchpad block from 2.1.x and
have it only once in our repository - this avoids committing changes to
both branches (2.1.x and trunk) and makes handling it a little bit easier.
The scratchpad contains experimental code anyway, so I think it's
sufficient to
We have some FOM related stuff in scratchpad (AO_*). Is this still
interesting stuff or can we delete it?
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Carsten Ziegeler wrote:
What do you think about removing the scratchpad block from 2.1.x and
have it only once in our repository - this avoids committing changes to
both branches (2.1.x and trunk) and makes handling it a little bit easier.
The scratchpad contains experimental code anyway, so I
Torsten Curdt wrote:
Carsten Ziegeler wrote:
What do you think about removing the scratchpad block from 2.1.x and
have it only once in our repository - this avoids committing changes to
both branches (2.1.x and trunk) and makes handling it a little bit
easier.
The scratchpad contains experimental
Carsten Ziegeler wrote:
We have some FOM related stuff in scratchpad (AO_*). Is this still
interesting stuff or can we delete it?
As the original author I'd say remove it in scratchpad and in trunk, I would
really like seeing this stuff alive but other things are much more important
(blocks,
Daniel Fagerstrom wrote:
Macros as reusable data types is OK in my (model view SoC
fundamentalistic ;) ) opinion.
I wouldn't call them macros then :-)
Just wanted to point out that your first
usesace could be attaced from a different POV.
ok, thanks!
--
Reinhard Pötz Independant
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Are you refering to the idea of having a configurable OM? I found it
initially to be FS, but everybody else that was involved in the
discussion wanted it, so I based my proposal on it. Carsten wanted it
for giving access to some portal
Carsten Ziegeler wrote:
What do you think about removing the scratchpad block from 2.1.x and
have it only once in our repository - this avoids committing changes to
both branches (2.1.x and trunk) and makes handling it a little bit easier.
The scratchpad contains experimental code anyway, so I
Reinhard Poetz wrote:
As the original author I'd say remove it in scratchpad and in trunk, I would
really like seeing this stuff alive but other things are much more
important
(blocks, docs).
Hmm, what's the difference to the main version?
Carsten
--
Carsten Ziegeler - Open Source
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 36
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
As the original author I'd say remove it in scratchpad and in trunk, I would
really like seeing this stuff alive but other things are much more important
(blocks, docs).
Hmm, what's the difference to the main version?
The ao version supports
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33896.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Daniel Fagerstrom wrote:
AFAIK there is no existing xpath traversal machinery in Cocoon that we
could reuse.
JFYI,
!-- Xpath Processor: --
xpath-processor class=org.apache.excalibur.xml.xpath.XPathProcessorImpl
logger=core.xpath-processor/
Vadim
Ralph Goers wrote:
Vadim Gritsenko wrote:
IMHO, there is no point in such input modules anymore. All you need is
* JS and EL firendly object model with object factories
(modules is banned word)
* Support of the EL in the sitemap
Once these two points are here, all existing input modules
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Will the scheme be named jcr?
Yes, but the scheme can be anything you want, especially as you may
use several repositories within the same webapp, and therefore use
jcr1, jcr2, etc.
ah!
Please, do jcr://repo/*
Sylvain Wallez wrote:
Torsten Schlabach wrote:
Sylvain,
I'm currently writing such a source ;-)
Will it show up in a separate block in 2.2-dev soon?
Yes. Maybe even 2.1, as I needed for a 2.1 project.
cool. I would be happy to help and testdrive when you will check in your
stuff
Michi
--
Michael Wechner wrote:
what about specifying the repo as parameter, e.g.
map:generate src=jcr://...
map:parameter name=repo value=.../
/map:generate
Because this is a source, not a generator. The parameter would be a
parameter to the generator.
Regards, Upayavira
On Tue, Mar 08, 2005 at 09:01:59AM +0100, Reinhard Poetz wrote:
I was looking at http://wiki.apache.org/cocoon/WhiteBoardCocoonForms and I
liked what I saw.
Thanks for taking a look. Any refinements are welcome.
Side note: Remeber items in the whiteboard are often initially
motivated by an
Upayavira wrote:
Michael Wechner wrote:
what about specifying the repo as parameter, e.g.
map:generate src=jcr://...
map:parameter name=repo value=.../
/map:generate
Because this is a source, not a generator. The parameter would be a
parameter to the generator.
ok. Well, I thought the
On Tue, Mar 08, 2005 at 11:09:08AM +0100, Daniel Fagerstrom wrote:
Then in the template you write:
ft:widget name=date
ft:labelbirthday/ft:label
/ft:widget
By placing labels, hints etc in the template (view) instead of in the
widget definition you get rid of the view info from the
Tim Larson wrote:
On Tue, Mar 08, 2005 at 11:09:08AM +0100, Daniel Fagerstrom wrote:
Then in the template you write:
ft:widget name=date
ft:labelbirthday/ft:label
/ft:widget
By placing labels, hints etc in the template (view) instead of in the
widget definition you get rid of the view info
Michael Wechner wrote:
Upayavira wrote:
Michael Wechner wrote:
what about specifying the repo as parameter, e.g.
map:generate src=jcr://...
map:parameter name=repo value=.../
/map:generate
Because this is a source, not a generator. The parameter would be a
parameter to the generator.
ok. Well,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=25121.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=26997.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Tim Larson wrote:
On Tue, Mar 08, 2005 at 09:01:59AM +0100, Reinhard Poetz wrote:
I was looking at http://wiki.apache.org/cocoon/WhiteBoardCocoonForms and I
liked what I saw.
Thanks for taking a look. Any refinements are welcome.
Side note: Remeber items in the whiteboard are often initially
On Tue, Mar 08, 2005 at 12:15:48PM +0100, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Macros as reusable data types is OK in my (model view SoC
fundamentalistic ;) ) opinion.
I wouldn't call them macros then :-)
Perhaps we should add more emphasis (via examples) on the wiki
page to
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27709.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hello, all,
When I created an Lucene index by CoCoon, I found
a directory named "index" existedbelow the temporary working directory of
the servlet engine (Jetty). AfterIstopped thecocoon server,
this directory was deleted. So I have to recreate the index every time the
cocoon
Tim Larson wrote:
On Tue, Mar 08, 2005 at 12:15:48PM +0100, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Macros as reusable data types is OK in my (model view SoC
fundamentalistic ;) ) opinion.
I wouldn't call them macros then :-)
Perhaps we should add more emphasis (via examples) on the
On Tue, Mar 08, 2005 at 04:50:10PM +0100, Reinhard Poetz wrote:
Tim Larson wrote:
On Tue, Mar 08, 2005 at 09:01:59AM +0100, Reinhard Poetz wrote:
In many of my forms date widgets are used: birthdate, start date, end
date, ... Definining those widgets is nearly always the same, except the
On Tue, Mar 08, 2005 at 04:40:04PM +, Tim Larson wrote:
On Tue, Mar 08, 2005 at 04:50:10PM +0100, Reinhard Poetz wrote:
can do it. What do you thing about reusable widgets as mentioned in my
initial mail of this thread? Shall I add them?
!-- Snip design notes. --
Btw, I do not mean to
Have you tried posting your question to the Lucene users list?
lucene-user@jakarta.apache.org
-Daniel
On Tue, 8 Mar 2005 10:53:40 -0500, YAN HE [EMAIL PROTECTED] wrote:
When I created an Lucene index by CoCoon, I found a directory named index
existed below the temporary working directory of
Reinhard Poetz wrote:
Michael Wechner wrote:
Upayavira wrote:
Michael Wechner wrote:
what about specifying the repo as parameter, e.g.
map:generate src=jcr://...
map:parameter name=repo value=.../
/map:generate
Because this is a source, not a generator. The parameter would be a
parameter to the
Tim Larson wrote:
On Tue, Mar 08, 2005 at 04:40:04PM +, Tim Larson wrote:
On Tue, Mar 08, 2005 at 04:50:10PM +0100, Reinhard Poetz wrote:
can do it. What do you thing about reusable widgets as mentioned in my
initial mail of this thread? Shall I add them?
!-- Snip design notes. --
Btw, I do
On Tue, Mar 08, 2005 at 08:10:36PM +0100, Reinhard Poetz wrote:
Tim Larson wrote:
Btw, I do not mean to scare you off.
No you haven't :-)
Great :)
Go ahead and add reusable
widgets to whiteboard/forms, write some samples using them and
see how they turn out in actual use. This type of
Tim Larson wrote:
On Tue, Mar 08, 2005 at 08:10:36PM +0100, Reinhard Poetz wrote:
Tim Larson wrote:
Btw, I do not mean to scare you off.
No you haven't :-)
Great :)
Go ahead and add reusable
widgets to whiteboard/forms, write some samples using them and
see how they turn out in actual use.
On Mar, 8 de Marzo de 2005, 4:48, Carsten Ziegeler dijo:
What do you think about removing the scratchpad block from 2.1.x and
have it only once in our repository - this avoids committing changes to
both branches (2.1.x and trunk) and makes handling it a little bit easier.
The scratchpad
Sylvain Wallez wrote:
Or we could also have a RepositorySelector and select a repository using
the first path element.
Instead of path element, you could use subprotocol
jcr:repo1://path/
Hmm... that may be a good option as an
application also need to access a repository directly and not only
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33915.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33915.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Hi:
We requested from user to fill a small form in bugzilla for new sites
powered by cocoon. The bugzilla form includes more info than we are
publishing online.
How we wil manage the new format? Can someone provide a sample of that?
Best Regards,
Antonio Gallardo
[EMAIL PROTECTED] wrote:
Author: lgawron
Date: Fri Mar 4 00:39:53 2005
New Revision: 156143
URL: http://svn.apache.org/viewcvs?view=revrev=156143
Log:
Fix thread safety problem in JXTemplateGenerator.setup() concerning template
script reparsing.
Modified:
Hi all,
Having to often write quick prototypes with Cocoon, I have on my laptop
one main Cocoon installation and a lot of subsitemap directories in
various locations, all mounted into the main Cocoon using the
mount-table matcher.
That works fine until the prototypes need some specific
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Or we could also have a RepositorySelector and select a repository
using the first path element.
Instead of path element, you could use subprotocol
jcr:repo1://path/
I like it, as it allows to use jcr://path to use the default (or single)
[EMAIL PROTECTED] wrote:
Author: sylvain
Date: Mon Mar 7 14:39:30 2005
New Revision: 156459
URL: http://svn.apache.org/viewcvs?view=revrev=156459
Log:
Spent 2 hours fighting with ClassCastExceptions because Poolable components are
now proxied
Added:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Author: sylvain
Date: Mon Mar 7 14:39:30 2005
New Revision: 156459
URL: http://svn.apache.org/viewcvs?view=revrev=156459
Log:
Spent 2 hours fighting with ClassCastExceptions because Poolable
components are now proxied
Added:
Extensive automated functional testing is the best way to keep up
software quality. There is general consensus on that, and everybody is
doing it - right?
The industry standard for testing Java classes is JUnit. When it comes
to testing web request/response conversations, the choice is less
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Added:
cocoon/trunk/src/java/org/apache/cocoon/sitemap/DefaultContentAggregator.java
(with props)
Modified:
cocoon/trunk/src/java/org/apache/cocoon/sitemap/ContentAggregator.java
Are you sure that you meant to checkin these
A side benefit, tremedously useful, is that the classloader is
re-created when the sitemap is reloaded. So this allows, by setting a
class-dir, to reload changed classes simply by touching the sitemap.
Awesome, mate! :-D
If we integrate the file alteration monitor from
jci we can even trigger
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33922.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Michael Wechner wrote:
Upayavira wrote:
Michael Wechner wrote:
what about specifying the repo as parameter, e.g.
map:generate src=jcr://...
map:parameter name=repo value=.../
/map:generate
Because this is a source, not a generator. The parameter would
Sylvain Wallez wrote:
Hi all,
Having to often write quick prototypes with Cocoon, I have on my laptop
one main Cocoon installation and a lot of subsitemap directories in
various locations, all mounted into the main Cocoon using the
mount-table matcher.
That works fine until the prototypes need
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Or we could also have a RepositorySelector and select a repository
using the first path element.
Instead of path element, you could use subprotocol
jcr:repo1://path/
I like it, as it allows to use jcr://path to use the default
I will not have much time to help with the docs re-organisation,
but i will do what i can.
Here is a list of the changes that i have made to the forrestbot
configuration.
For those that didn't know about it, there is a demonstration
Forrestbot which automatically builds the documentation every
Le 8 mars 05, à 11:48, Carsten Ziegeler a écrit :
What do you think about removing the scratchpad block from 2.1.x and
have it only once in our repository...
+1, good idea
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Le 9 mars 05, à 00:11, Alfred Nathaniel a écrit :
...Does anybody have practical experience with Canoo WebTest which
speaks
for/against this product? Or any other product? Or is nobody
testing?..
Although I do not see an urgent need to move away from anteater, I've
been using HttpUnit
Le 8 mars 05, à 23:52, Sylvain Wallez a écrit :
...A side benefit, tremedously useful, is that the classloader is
re-created when the sitemap is reloaded. So this allows, by setting a
class-dir, to reload changed classes simply by touching the sitemap...
Wow. Anyone got some hero plate kits for
Torsten Curdt wrote:
A side benefit, tremedously useful, is that the classloader is
re-created when the sitemap is reloaded. So this allows, by setting a
class-dir, to reload changed classes simply by touching the sitemap.
Awesome, mate! :-D
If we integrate the file alteration monitor from
jci
Alfred Nathaniel wrote:
Anteater is dead, and we should get away from it before it starts
smelling. Canoo WebTest seems to be an attractive alternative for
preserving the Anteater paradigm of tight Ant integration.
Does anybody have practical experience with Canoo WebTest which speaks
for/against
69 matches
Mail list logo
