Hi,
On 7 Dec 2005, at 23:26, Thomas Lutz wrote:
Second argument: It was hard to explain, why I kicked struts out,
and used cocoon instead. And it was even harder to explain that
there is JavaScript in the server part. Managers who buy oracle
don't like to hear things like this...
To
On Thursday 08 December 2005 02:10, Daniel Fagerstrom wrote:
With this I
measn that you can use the parts of Cocoon that you like, in the way you
like in your webapp, without having to buy a whole religion.
Being a devout atheist, I must +1000 this one.
Niclas
On Wednesday 07 December 2005 23:56, Sylvain Wallez wrote:
* No IDE support for JavaScript
There's a JS plugin in Eclipse webtools and the amazing JSEclipse [4]
that does autocompletion of function and argument names, plus tooltips
and all that stuff.
Really??
How can it do code completion
On Wednesday December 07, 2005 6:26 pm, Thomas Lutz wrote:
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
snip type=everything I was feeling, and I'm not alone in my view/
Last comment:
Ross Gardler wrote:
Now I'd better stop before I start convincing myself that people will
find all 600 pages of my PhD interesting ;-)
Any pointer for those that might be interested?
Sylvain
--
Sylvain WallezAnyware Technologies
http://bluxte.net
Berin Loritsch schrieb:
So, please :-), only one language, and as cocoon (or whatever it's name
will be :-) ) is a J2EE framework: _Java_
I hear you, and hopefully even more.
Sorry for the interference :-), regards,
tom
Please interfere. Users lurking on dev are more than welcome to
Sylvain Wallez wrote:
Ross Gardler wrote:
Now I'd better stop before I start convincing myself that people will
find all 600 pages of my PhD interesting ;-)
Any pointer for those that might be interested?
This research is fairly old now (6 years), and things have moved on a
little,
Ross Gardler wrote:
Sylvain Wallez wrote:
Ross Gardler wrote:
Now I'd better stop before I start convincing myself that people will
find all 600 pages of my PhD interesting ;-)
Any pointer for those that might be interested?
This research is fairly old now (6 years), and things have
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
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
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...
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)
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!
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:
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
On Dec 7, 2005, at 6:23 AM, Berin Loritsch wrote:
[X] Mix and match (not as simple, but is status quo with today)
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
[ 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]
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
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:
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
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
42 matches
Mail list logo
