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:
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
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 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 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]
[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
25 matches
Mail list logo
