Yep,
this fits for the theories and it holds true mostly. But..
it depends on the stakeholders you are dealing with.

If you are building apps and services for others or for production anyways, there's no point on using beta code and in no case, alpha. Also there is no point of choosing the latest technology if there is no point. If you have proven track record of something so stable that it has been running for ten years without problems, like Torsten mentioned, why don't use it if it suits for the needs. Some times it's trendy to introduce the latest software for your clients, sometimes not. For example, governmental offices may like more 'the good old' stuff than the latest.

C3 and HTML5. Have you got any examples? That would be something for us in future.

Don't get me wrong. I am just a single member of some single minority and have my own opinions and further more a lot of questions and thoughts to share. And as a non native English speaker always in danger of being misunderstood, especially among of others like.

cheers,
- mika -


On Wed, 18 Apr 2012 12:03:22 +0200, Robby Pelssers <robby.pelss...@nxp.com> wrote:
Well,

I also have a pretty strong opinion about the remark you make now.

Let's first make the distinction between
- innovators      (people who are always trying to improve the way of
working themselves  --> E.g. Reinhard Poetz who started C3)
- early adapters  (people who see clear benefits in innovative
technologies .. e.g. early committers / users like Simone Tripodi)
- reasonable adapters  (people who upgrade their software after major
stable releases)
- slow adapters   (people who are satisfied with current way of
working and wait till they are forced to upgrade)


Point is... there are always costs involved.  If you created lots of
C2.1.x apps and you want to start using the latest and greatest... you
have 2 choices.

Either you start creating NEW apps using the latest technology and
leave the existing ones alone  --> Low adaptation cost
Or you decide to rewrite/upgrade your existing apps --> higher
adaptation cost

Sometimes the upgrade path is hard to sell to your customer if the
upgrade does not provide immediate visible benefits.

But let's consider you are a slow adapter and you get forced to
upgrade at some point.  You have put great amounts of effort in
getting those Cforms working and all logic is contained in flowscript
(both are deprecated in C3).

Now what do you think the cost of sticking with the old technology
is?  It's even much higher. I think for most developers the easiest
approach would be to follow that of a reasonable adapter. It balances
the Costs involved in a safer way.

Robby






-----Original Message-----
From: m...@digikartta.net [mailto:m...@digikartta.net]
Sent: Wednesday, April 18, 2012 11:52 AM
To: users@cocoon.apache.org
Subject: Re: Forms and maps


 Torsten,
 I understand your points.
Still, it depends on what are trying to achieve, how much do you have
 time for it and what are your skills and competence. Also, from the
point of the business view, there is a concept of opportunity costs. It may be reasonable to go on with the old framework, even if the newer one would be much better. On the other hand, starting with the old one isn't smart. So suggestion to start with (or wait for) the stable C3 can be
 very wise decision.

 - mika -


 On Wed, 18 Apr 2012 11:37:59 +0200, Thorsten Scherler
 <scher...@gmail.com> wrote:
On 04/18/2012 07:58 AM, m...@digikartta.net wrote:

Ciao Alberto,
you'll probably right.

What comes to Cocoon lifecycle, I don't get it. Has C3 anything in
common with C2 except the concept of pipelines? Can you do the same
things with it?
When C2.2 was published, I fell off the wagon because of techical
differences. C3 knocked me out for good. If you think of the user
coming from C2.1 environment who has get used to utilize flowscript,
templates, cforms, xsp etc and think of him/her trying to get
accustomed in C3, I think the least one can say is that he/she will be
totally in a faint.

I don't either get the eagerness for dumbing all the "good old"
techiques and frameworks.

Well if you refer to avalon as good old framework, I think dropping
that is the best thing that happened for c3. To use spring is using
the de facto industry standard and I bet there are MUCH MORE people
having used spring then avalon. Other then that xsp, cforms, ... are
home grown that are only known by nerds and which never have reached
to be a standard. Like other said in their responses the technology
ecosystem is changing rapidly and e.g. cform is nightmare to
understand, pain to extend and never had been really stable. Further
it brings no benefit over using html5 forms and REST services for the
ajax calls which is so much straight forward and ... de facto
industry
standard for web2 apps.

I migrated a couple of 2.1 generators and  transformer and it is not
too complicated to migrate. Further the whole concept is still the
same only details changed (e.g. validity and cache keys)

The limitation of c2.x had been Avalon all this years. In c3 we
finally can use transformer as simple sax handler outside cocoon.

Of course the general abandonment will halt the development but if
you think something like C2.1 and C2.2, I guess they will be useful
for years to go, if you are willing and capable of updating some parts
by your own.

Having worked with each version I see your point, but would strongly
advice people to look into c3 when we release it in a stable version
(hopefully in the next couple of month).

salu2


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org

Reply via email to