That certainly does help to explain the difference
in log-levels. Thanks Carsten.
Someone should document that :-)
The original problem still remains. How does Cocoon
manage to get logkit to handle the ehcache messages,
whereas with Forrest they come to the console?
IIRC the integration with
Sylvain Wallez wrote:
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
Le 7 déc. 05, à 09:10, Ross Gardler a écrit :
...I envision being able to build a Cocoon application by saying
given these input types, I want this output type and to have the
resulting application automatically tested against my test inputs...
Not sure if I understand what you mean, could
Berin:
I envision a Cocoon which takes its principle strengths in
separation of concerns to make developing web applications
easier. Modern web applications provide machine-to-machine
communications via web services and email as well as various
views into the data. I envision a Cocoon
Il giorno 07/dic/05, alle ore 09:40, Torsten Curdt ha scritto:
Plus I envision to have good testcase coverage for the whole
system. I envision to have a clean core that shines through
simplicity. I envision a non-viral component handling (One word:
AbstractLogEnabled). POJOs and factories
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 09:40, Torsten Curdt ha scritto:
Plus I envision to have good testcase coverage for the whole system.
I envision to have a clean core that shines through simplicity. I
envision a non-viral component handling (One word:
AbstractLogEnabled). POJOs
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
Bertrand Delacretaz wrote:
Le 7 déc. 05, à 09:10, Ross Gardler a écrit :
...I envision being able to build a Cocoon application by saying
given these input types, I want this output type and to have the
resulting application automatically tested against my test inputs...
Not sure if I
Ross Gardler wrote:
Bertrand Delacretaz wrote:
Le 7 déc. 05, à 09:10, Ross Gardler a écrit :
...I envision being able to build a Cocoon application by saying
given these input types, I want this output type and to have the
resulting application automatically tested against my test inputs...
Upayavira wrote:
...
So, what I'd propose is we choose another name, and consider it to be a
new subproject of Cocoon. A new, exciting web development framework
from the people that brought you Apache Cocoon.
Right, let us stay above the boring tech talk and focus on finding a new
name that
Reinhard Poetz wrote:
Today, Jorg and I had a long chat about this. In short, we failed to
find a solution that works with Maven 2 as it is today. The problem is
that Cocoon block requirements have a different purpose than Maven 2
dependencies. Cocoon block requirements desribe what a block
Il giorno 07/dic/05, alle ore 10:13, Sylvain Wallez ha scritto:
I was expecting you to also add I envision a Cocoon where all
exceptions would be unckecked :-)
Ça va sans dire. Oh, by the way, how do you expect to be able to
distribute Cocoon in France now that they are going to outlaw
In the exchange below I did some creative snipping to emphasize where we
are not 100% aligned on vision. Below I will bring out my points,
knowing that I'm not the guy who sets the tone for Cocoon.
Torsten Curdt wrote:
Berin:
... I envision a Cocoon which takes its principle strengths in
Berin Loritsch wrote:
What's your preference for the vision?
[ ] All web apps written in JavaScript
[X] All web apps written in pure Java
[ ] Mix and match (not as simple, but is status quo with today)
Sylvain Wallez wrote:
In the meantime, what about simply CoNG, for Cocoon New Generation.
This name isn't that nice, which will make us want to find something
else, but solves the immediate need of having a word to designate this
new thing without fighting about version numbers, separate
Berin Loritsch wrote:
What's your preference for the vision?
[ ] All web apps written in JavaScript
[ ] All web apps written in pure Java
[X] Mix and match (not as simple, but is status quo with today)
With Ajax and other bells and whistles on the client side, there will
always be
None of these. I have a vision where the business services are
implemented in Java, the web application is defined in a stateful flow
controller (xml config) and the views are generated using pipelines with
standard components. So my answer is - No programming language on the
server, just
hepabolu wrote:
Berin Loritsch wrote:
What's your preference for the vision?
[ ] All web apps written in JavaScript
[ ] All web apps written in pure Java
[X] Mix and match (not as simple, but is status quo with today)
With Ajax and other bells and whistles on the client side, there will
Ralph Goers wrote:
None of these. I have a vision where the business services are
implemented in Java, the web application is defined in a stateful flow
controller (xml config) and the views are generated using pipelines
with standard components. So my answer is - No programming language
Berin Loritsch wrote:
What's your preference for the vision?
[ ] All web apps written in JavaScript
[ ] All web apps written in pure Java
[X] Mix and match (not as simple, but is status quo with today)
Vadim
Berin:
I envision a Cocoon which takes its principle strengths in
separation of concerns to make developing web applications easier.
Modern web applications provide machine-to-machine communications
via web services and email as well as various views into the data.
I envision a Cocoon
Berin Loritsch wrote:
Ralph Goers wrote:
None of these. I have a vision where the business services are
implemented in Java, the web application is defined in a stateful
flow controller (xml config) and the views are generated using
pipelines with standard components. So my answer is - No
Berin Loritsch wrote:
Ralph Goers wrote:
None of these. I have a vision where the business services are
implemented in Java, the web application is defined in a stateful flow
controller (xml config) and the views are generated using pipelines
with standard components. So my answer is - No
Ross Gardler wrote:
Berin Loritsch wrote:
I would argue that what you are talking about is a domain specific
language in the guise of configuration (just like your hibernate
descriptors and ant scripts).
Sometimes, DSL's bring many benefits, just consider the sitemap.
Do we want to know
Berin Loritsch wrote:
In the exchange below I did some creative snipping to emphasize where
we are not 100% aligned on vision. Below I will bring out my points,
knowing that I'm not the guy who sets the tone for Cocoon.
We are collectively setting the tone, and your inputs are very valuable!
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
In the meantime, what about simply CoNG, for Cocoon New
Generation. This name isn't that nice, which will make us want to
find something else, but solves the immediate need of having a word
to designate this new thing without fighting about version
Il giorno 07/dic/05, alle ore 11:43, Ross Gardler ha scritto:
Most businesses are made up of common business processes. The odd
one will be unique to that business, but most are common. In the
case of the unique practices the software needs to be customised,
but in the case of common
Il giorno 07/dic/05, alle ore 15:23, Berin Loritsch ha scritto:
What's your preference for the vision?
[ ] All web apps written in JavaScript
[X ] All web apps written in pure Java
[ ] Mix and match (not as simple, but is status quo with today)
Ugo
--
Ugo Cei
Tech Blog:
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto:
Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much
better. No chance that it could be released without renaming.
Hmmm ... maybe Cocoon 360? ;-)
Ugo
--
Ugo Cei
Tech Blog: http://agylen.com/
Open Source
So far it seems as if we are looking at two options: Pure Java or
status quo. And so far we are something along the lines of 2 for Java
and 2 (possibly 3) for status quo.
Anyone else have input?
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 15:23, Berin Loritsch ha scritto:
What's your
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto:
Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much
better. No chance that it could be released without renaming.
Hmmm ... maybe Cocoon 360? ;-)
No, CS3 implemented on the cell processor ;P
On Dec 7, 2005, at 6:23 AM, Berin Loritsch wrote:
[X] Mix and match (not as simple, but is status quo with today)
Marc Portier wrote:
Reinhard Poetz wrote:
Today, Jorg and I had a long chat about this. In short, we failed to
find a solution that works with Maven 2 as it is today. The problem is
that Cocoon block requirements have a different purpose than Maven 2
dependencies. Cocoon block requirements
Quoin Developers wrote:
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
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto:
Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much
better. No chance that it could be released without renaming.
Hmmm ... maybe Cocoon 360? ;-)
Nothing new, no innovation at all. Did we
Following the vision that Bertrand and Marc expressed, I'd like to see
Cocoon becoming less of a xml webapp framework and more of a set of
reuasble xml webapp components and a set of design patterns. With this I
measn that you can use the parts of Cocoon that you like, in the way you
like in
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto:
Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much
better. No chance that it could be released without renaming.
Hmmm ... maybe Cocoon 360? ;-)
Ugo
MS Cocoon
[ X] Mix and match (not as simple, but is status quo with today)
Assuming we can move to a componentized Cocoon, the components will be
usable from both javascript or java.
(or from JRuby for that matter, which is supposed to support Rails [1]
in a few months ;-)
-Bertrand
[1]
So the forms_onsubmit() method needs boolean indicator as to whether
the form has already been submitted for server processing (distinct
from an ajax forms submission) to know whether it should process the
onsubmit handlers array. It should no longer simply use the
forms_onsubmtHandlers stack for
Mats Norén wrote:
Ross Gardler wrote:
Bertrand Delacretaz wrote:
Le 7 déc. 05, à 09:10, Ross Gardler a écrit :
...I envision being able to build a Cocoon application by saying
given these input types, I want this output type and to have the
resulting application automatically tested
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 11:43, Ross Gardler ha scritto:
Most businesses are made up of common business processes. The odd one
will be unique to that business, but most are common. In the case of
the unique practices the software needs to be customised, but in the
[X] Mix and match (not as simple, but is status quo with today)
However, to be effective we need a core development effort, therefore
the *official* support should be for a limited subset of what is in use
today:
Javascript + Java
Ross
Hello.
Sorry for the intervention of a non-dev on the dev list, but shouldn't
this question be asked on the user mailing list?
Aurélien
Ralph Goers wrote:
Ugo Cei wrote:
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto:
Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much
better. No chance that it could be released without renaming.
Hmmm ... maybe Cocoon 360? ;-)
Ugo
MS Cocoon
:-)
Aurélien DEHAY wrote:
Hello.
Sorry for the intervention of a non-dev on the dev list, but shouldn't
this question be asked on the user mailing list?
:) Yes and no. Check this article out for more information:
On 04.12.2005 17:00, Sylvain Wallez wrote:
Start a whiteboard prototype if you feel like it, but to me it seem
quite risky to try to rewrite everything from scratch, although I have
felt the urge myself countless time while struggling with the messy
internals. But before you go ahead and
Hi all,
I was contacted recently by Martin Cooper, Struts PMC chair -- yikes!
:-) -- that happens to know quite well the people behind DojoToolkit,
and we chatted about the opportunity to have some coordinated effort wrt
to JavaScript at Apache, both client-side and server-side.
So we've
Though I am not a dev guy, I can't resist to vote, too. IMHO a mix makes
no sense. Too make a long story short I made struggled my way into
cocoon with
-first writing custom actions as I was not aware that I should use flow
instead
-then switching to flow using JavaScript
-and finally port
Quoin Developers wrote:
So the forms_onsubmit() method needs boolean indicator as to whether
the form has already been submitted for server processing (distinct
from an ajax forms submission) to know whether it should process the
onsubmit handlers array. It should no longer simply use the
I really think the current discussions on CocoonReloaded could do with some
higher bandwidth talks to formulate a first plan. How many Cocoonites will
be at ApacheCon and could perhaps get together? I won't be there but Carsten
is (for example).
Discussing the plan via various email-threads
On 06.12.2005 13:18, Steven Noels wrote:
I'm
surprised to finally see evidence of an anti-OSGI camp in Cocoon. Not
that this surprises me, but it's just sad that this hasn't been
clarified much earlier. That damned community tax again, I guess. Waste
of time and energy for everyone.
At
51 matches
Mail list logo
