Berin Loritsch wrote:
In all the talks of redesign or not, there has been a recurring
question as to the vision. Sylvain has outlined some things that he
would like to see, but they really don't constitute a vision. They
are a nice list of improvements, but they aren't a vision. In my
exper
Upayavira wrote:
I've been thinking more about Sylvain's proposal and ideas. And would
like to suggest a way to look at it and see how it fits into the context
of what we already have.
Sylvain is proposing something different, something that is likely to be
almost entirely incompatible with the
Carsten Ziegeler wrote:
> Cocoon 2.2 uses "running modes" for resolving properties. In the
> WEB-INF/properties directory, you'll find two modes"prod" and "dev". By
> default, 2.2 is running in dev mode which overrides all log levels
> defined in the logkit config and sets them to DEBUG.
>
> You c
It is also necessary to change forms_onsubmit in forms-lib.js to
remove setting the forms_onsubmithandlers to null.
Any suggestions about this? It seems that it's import to know when the
form is finally submitted vs when it is being ajax submitted. Is this
correct?
function forms_onsubmit() {
I believe that the source of the problem is cforms.js
cocoon.forms.submitForm = function(element, name) {
...
forms_onsubmitHandlers = new Array();
Removing the above line seems to solve the problem. Any reason why
that line should be there? Can it be removed?
Regards,
Eric Meyer
Hello,
We've run into a problem where javascript event handlers do not work
after any ajax form widget fires. For example, before changing a
selection box that triggers an ajax event, the forms_onsubmitHandlers
has a number of objects in it. After an ajax request, the
forms_onsubmitHandlers array
>>I'm far over the stage of "remote interest", I can't wait until we have
>>switched completely to M2. And Carsten might be interested in discussing
>>Maven as well ;)
>
>
Yupp, definitly :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/webl
Cocoon 2.2 uses "running modes" for resolving properties. In the
WEB-INF/properties directory, you'll find two modes"prod" and "dev". By
default, 2.2 is running in dev mode which overrides all log levels
defined in the logkit config and sets them to DEBUG.
You can either set the running mode to "p
good morning , or better good night
I don't know English very well , and for this this email is orrible.
i have a problem , please help me!
i must to create a sitemap with the html generator and an xslt
generator, but don't work or
better or work the xslt without the html generator or the html gen
Upayavira wrote:
I've been thinking more about Sylvain's proposal and ideas. And would
like to suggest a way to look at it and see how it fits into the context
of what we already have.
Sylvain is proposing something different, something that is likely to be
almost entirely incompatible with the
On Dec 6, 2005, at 2:31 PM, Upayavira wrote:
This, it is _not_ Cocoon 3.0. It is something else.
Thus, I agree with Sylvain that it should have a new name, but think
that Raccoon is a bad one, as it is a play on Cocoon and could never
really be the project's real name. Imagine it, "powered by
Daniel Fagerstrom wrote:
> Jorg Heymans wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>> There have been a long discussion on Felix-dev about how to use M2
>>> (which is jar based) with OSGi (which is contract based, although at
>>> the package level) in the best way. Both people from Maven and
>>> Ecl
I've been thinking more about Sylvain's proposal and ideas. And would
like to suggest a way to look at it and see how it fits into the context
of what we already have.
Sylvain is proposing something different, something that is likely to be
almost entirely incompatible with the existing Cocoon. If
Jorg Heymans wrote:
Daniel Fagerstrom wrote:
There have been a long discussion on Felix-dev about how to use M2
(which is jar based) with OSGi (which is contract based, although at
the package level) in the best way. Both people from Maven and Eclipse
have been involved. We can use what they
Daniel Fagerstrom wrote:
There have been a long discussion on Felix-dev about how to use M2
(which is jar based) with OSGi (which is contract based, although at the
package level) in the best way. Both people from Maven and Eclipse have
been involved. We can use what they come up with later,
BURGHARD Éric wrote:
Daniel Fagerstrom wrote:
What do you think about moving block dependecy handling from block.xml
to pom.xml? It means reduced flexibilty as block dependencies becomes
direct instead of indirect as in the current schema. OTH it reduce
complexity and fullfills our current u
Daniel Fagerstrom wrote:
Simplicity vs flexibillity ;)
Anyway, the important thing is to get something that works ASAP, and the
block code is designed for B) and you seem to think that it is easier
with M2, so go ahead with B). We can impove usabillity with various
"conventions" at a later s
Reinhard Poetz wrote:
Jorg Heymans wrote:
Reinhard Poetz wrote:
What do you think about moving block dependecy handling from
block.xml to pom.xml? It means reduced flexibilty as block
dependencies becomes
IIUC, the dependency handling discussed here is the deploy-time
dependency ha
Jorg Heymans wrote:
Reinhard Poetz wrote:
What do you think about moving block dependecy handling from
block.xml to pom.xml? It means reduced flexibilty as block
dependencies becomes
IIUC, the dependency handling discussed here is the deploy-time
dependency handling, thus only relevant
In all the talks of redesign or not, there has been a recurring question
as to the vision. Sylvain has outlined some things that he would like
to see, but they really don't constitute a vision. They are a nice list
of improvements, but they aren't a vision. In my experience the best
visions
Daniel Fagerstrom wrote:
Berin Loritsch wrote:
I will continue to be proud of our brand, our product and our
community. And I will continue the work on *Cocoon* towards the
future in an evolutionary way, so that those who have put their
trust in us have a reasonable migration path to follow.
Berin Loritsch wrote:
Daniel Fagerstrom wrote:
To me:
* throwing away the collected work of the community
* building something rather different
* throwing away a strong brand
* leave all the users who has put a trust in us behind
seem like a rather strange way of "saving" Cocoon.
It seemed
Romano Trampus wrote:
Sorry, I read "spots" of this list and somebody could have written the
same:
I think the cocoon package is too big. I would prefer a core and a lot of
plugins, not in the same distribution. I think the cocoon package is great
but confusing. With plugins you have not to ca
Sorry, I read "spots" of this list and somebody could have written the
same:
I think the cocoon package is too big. I would prefer a core and a lot of
plugins, not in the same distribution. I think the cocoon package is great
but confusing. With plugins you have not to care that anything must ha
What I write here is just one vote, but maybe others think the same.
For all of our enterprise projects we have done in Cocoon, if it hadn't
been Java, we wouldn't have been allowed to use it. Our customers
understand Java and it is currently equated with enterprise.
Now, it is difficult enough
Daniel Fagerstrom wrote:
To me:
* throwing away the collected work of the community
* building something rather different
* throwing away a strong brand
* leave all the users who has put a trust in us behind
seem like a rather strange way of "saving" Cocoon.
It seemed like a rather strange
Bertrand Delacretaz wrote:
Le 6 déc. 05, à 10:12, Ugo Cei a écrit :
...I also see "Too soon" on that list, which might be descriptive of
the feelings of some people on this list ;).
It might be too soon to choose a name for something which doesn't exist
yet...but choosing a "code name" help
Steven Noels wrote:
On 06 Dec 2005, at 12:04, Sylvain Wallez wrote:
Steven Noels wrote:
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
Struts has Shale
Meeep. Bu. Wrong.
Struts has Craig.
And Tapestry has Howard and Spring has Rod. What do you mean?
I meant to say that Struts is
Hi,
I'm using eXist XQueryGenerator in a simple pipeline. It works correctly
when i call it directly from my browser with correct parameters.
Now this pipeline is called from
o.a.c.w.a.c.PipelineAuthenticator.authenticate(PipelineAuthenticator.java:145)
during a flow flogin and i've got an except
Luca Morandini wrote:
Stefano Mazzocchi wrote:
Luca Morandini wrote:
Nevertheless, it is easier to build a tool around a declarative
language expressed as XML, than a procedural language expressed as...
a procedural programming language.
I'm sorry, Luca, but I think that's BS.
For example
On 06 Dec 2005, at 12:04, Sylvain Wallez wrote:
Steven Noels wrote:
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
Struts has Shale
Meeep. Bu. Wrong.
Struts has Craig.
And Tapestry has Howard and Spring has Rod. What do you mean?
I meant to say that Struts is a bad example since i
Forgot the patch...
cforms-upload.patch
Description: Binary data
On 6 Dec 2005, at 12:51, Robin Wyles wrote:
Sylvain,
On 6 Dec 2005, at 12:20, Sylvain Wallez wrote:
Robin Wyles wrote:
Hi All,
I noticed that if a form contains a file field then AJAX is
completely disabled for that for
Sylvain,
On 6 Dec 2005, at 12:20, Sylvain Wallez wrote:
Robin Wyles wrote:
Hi All,
I noticed that if a form contains a file field then AJAX is
completely disabled for that form. I've patched my cforms.js so that
it disables AJAX only if the file field contains a value. Is this
valid?
Yes
Robin Wyles wrote:
Hi All,
I noticed that if a form contains a file field then AJAX is completely
disabled for that form. I've patched my cforms.js so that it disables
AJAX only if the file field contains a value. Is this valid?
Yes, definitely.
On a more general note would it not be possib
Hi All,
I noticed that if a form contains a file field then AJAX is completely
disabled for that form. I've patched my cforms.js so that it disables
AJAX only if the file field contains a value. Is this valid?
On a more general note would it not be possible to check only the
fields which are
Steven Noels wrote:
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
Struts has Shale
Meeep. Bu. Wrong.
Struts has Craig.
And Tapestry has Howard and Spring has Rod. What do you mean? That
Cocoon misses someone that can fully dedicate to it and plays the
benevolent dictator?
Sylvain
Hi All,
Up until recently I was able to have a repeater binding like this...
[...]
This would handle the loading, updating and deleting of rows in the
repeater, but ignore newly added row
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote:
Struts has Shale
Meeep. Bu. Wrong.
Struts has Craig.
It's a telltale of Cocoon's problem that we're off discussing marketing
techniques and branding again, without having any design, code, nor
dedication to boot with. A busy thread just
Ugo Cei wrote:
Il giorno 06/dic/05, alle ore 10:01, Sylvain Wallez ha scritto:
Il like this friendly animal and the rhyme with Cocoon. Now there's
also "Baboon" :-)
Have a look at
http://www.rhymezone.com/r/rhyme.cgi?Word=cocoon&typeofrhyme=perfect&org1=syl&org2=l
I also see "Too soon"
Le 6 déc. 05, à 10:17, Matthew Langham a écrit :
Where is the vision?
Delivering some of the unique things that are inside Cocoon in much
smaller independent packages, to make them useful to people who don't
need all of Cocoon.
Dunno if this qualifies as a vision, but it's how I see it ;-)
Matthew Langham wrote:
No, the brand is not strong.
Look around among people that have *not* used Cocoon and ask
them what it is. Most of them will tell you "it's a
publishing engine", or even "it's a tool to perform XSL
transformations".
What we have now and what we're building is much mor
To me:
* throwing away the collected work of the community
* building something rather different
* throwing away a strong brand
* leave all the users who has put a trust in us behind
seem like a rather strange way of "saving" Cocoon.
I will continue to be proud of our brand, our product and our
>
> No, the brand is not strong.
>
> Look around among people that have *not* used Cocoon and ask
> them what it is. Most of them will tell you "it's a
> publishing engine", or even "it's a tool to perform XSL
> transformations".
>
> What we have now and what we're building is much more than
Le 6 déc. 05, à 10:12, Ugo Cei a écrit :
...I also see "Too soon" on that list, which might be descriptive of
the feelings of some people on this list ;).
It might be too soon to choose a name for something which doesn't exist
yet...but choosing a "code name" helps clarifying what we're talki
Il giorno 06/dic/05, alle ore 10:01, Sylvain Wallez ha scritto:
Il like this friendly animal and the rhyme with Cocoon. Now there's
also "Baboon" :-)
Have a look at http://www.rhymezone.com/r/rhyme.cgi?
Word=cocoon&typeofrhyme=perfect&org1=syl&org2=l
I also see "Too soon" on that list, wh
Ugo Cei wrote:
Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto:
I started to draft here what the next-generation Cocoon should be. I
dubbed it "Racoon" (with Andrew's permission) as I really think that
from a marketing point of view, a new name should be used so that
people
don
Marc Portier wrote:
David Crossley wrote:
Please don't. Cocoon is the name
+1, same opinion here
the brand is strong enough, and can cope with major release numbers that
indicate we had serious new insights
No, the brand is not strong.
Look around among people that have *not* used C
Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto:
I started to draft here what the next-generation Cocoon should be. I
dubbed it "Racoon" (with Andrew's permission) as I really think that
from a marketing point of view, a new name should be used so that
people
don't see it as a
48 matches
Mail list logo
