You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Alberto <ab...@ogs.trieste.it> on 2012/04/13 19:03:04 UTC
Forms and maps
Hi,
I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
cocoon forms.
I have to do simple things from flowscript: load a kml url and receive
the coordinates of an area selection.
I'm considering to use OpenLayers or Google Maps. Looking sources I
found already existing widget classes for GoogleMaps
(org.apache.cocoon.forms.formmodel.GoogleMap) but it is undocumented and
using it I have the following error: "Non-existing component for this
hint (Key='googlemap')". Moreover it seems it lacks methods to load a
kml file.
So, which is the best way to do it? The googlemap widget is working?
I have to write a new widget following the document
http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
Any suggest is welcome
Best regards
Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Forms and maps
Posted by mi...@digikartta.net.
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
<Ro...@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: mika@digikartta.net [mailto:mika@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
> <sc...@gmail.com> wrote:
>> On 04/18/2012 07:58 AM, mika@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-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Forms and maps
Posted by Robby Pelssers <Ro...@nxp.com>.
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: mika@digikartta.net [mailto:mika@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
<sc...@gmail.com> wrote:
> On 04/18/2012 07:58 AM, mika@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-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Forms and maps
Posted by mi...@digikartta.net.
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
<sc...@gmail.com> wrote:
> On 04/18/2012 07:58 AM, mika@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-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Forms and maps
Posted by Thorsten Scherler <sc...@gmail.com>.
On 04/18/2012 07:58 AM, mika@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
--
Thorsten Scherler<scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Forms and maps
Posted by mi...@digikartta.net.
That's a good one!
- mika -
On Wed, 18 Apr 2012 11:30:58 +0200, Robby Pelssers
<Ro...@nxp.com> wrote:
> You should read this article 'Why Good Programmers Are Lazy and
> Dumb' http://blogoscoped.com/archive/2005-08-24-n14.html
>
> I think it's not so much about losing our jobs but about
> - trying to become more productive (getting more done in the same
> amount of time)
> - avoiding repetitive work
>
>
> The ones who do actually have more market value compared to their
> competitors. So even from financial point of view there is a drive
> towards doing exactly the above.
>
> Why does Apple release a new iphone / ipad each year? Because they
> have to keep generating a income... That does not mean the previous
> products were of poor quality.
>
> Robby
>
>
> -----Original Message-----
> From: mika@digikartta.net [mailto:mika@digikartta.net]
> Sent: Wednesday, April 18, 2012 11:25 AM
> To: users@cocoon.apache.org
> Subject: RE: Forms and maps
>
>
> Absolutely. But trying to stay on the edge of the trends won't fit
> for
> us all.
> And continous rewriting of apps doesn't make any sense. Why on earth
> we
> can't create something that would last at least a decade?
> Half of us would be out of jobs?
>
> - mika -
>
>
> On Wed, 18 Apr 2012 10:50:37 +0200, gelo1234 <ge...@gmail.com>
> wrote:
>> I totally agree with Robby's opinion. The trend is to use HTML5 on
>> the client side in case of Web apps.
>>
>> Greetings,
>> Greg
>> 18-04-2012 10:27, "Robby Pelssers" napisał(a):
>> Just my 2 cents on this topic...
>>
>> Cocoon forms was at the time in my eyes a pretty awesome solution
>> to
>> build highly dynamic forms with support for continuations. But as we
>> all know this puts considerable strain on the server side.
>> Gradually
>> we started seeing a tendency towards AJAX (XmlHttpRequests) which is
>> a
>> fancy word for:
>> - no complete page refresh
>> - partial re-rendering of page
>> - only fetching the minimal amount of data
>> - let the browser do the heavy lifting
>>
>> This trend is evolving even further now with Websockets.
>>
>> One could easily say that the same discussions hold for database
>> related technologies. Hibernate was the big revelation, a super
>> abstraction over RDBMS dialects. It greatly reduces portability but
>> it just doesn't always do the right thing (e.g. performance wise) so
>> some people reverted back to plain jdbc wrappers.
>>
>> XSP was very convenient but it allows developers to mix controller
>> /
>> view which is now seen as a bad habit.
>>
>> Avalon was the way forward to configure your components at the time
>> and next dependency injection became the most hyped buzzword.
>> Spring
>> framework and google juice came into play.
>>
>> I guess it's a matter of taste and the willingness to move forward.
>> All (web)frameworks and technologies move forward (willingly or
>> not):
>> - new JDK
>> - newer versions of dependencies
>> - Ant --> maven
>> - ...
>>
>> Recently there were some rants against XSLT
>> (http://www.snoyman.com/blog/2012/04/xslt-rant.html [2] ). Just try
>> transforming XML from your most favorite programming language and
>> you
>> might be in for a surprise. Surely XSLT takes a lot of typing but
>> also XSLT is evolving just as XQuery is.
>>
>> I can only advise to take a good look around and find the best
>> match
>> for your requirements. If that is all about building dynamic forms
>> wicket might be a good fit. Cocoon still is and certainly will be
>> for the near future the best choice for transforming XML.
>>
>> Cheers,
>> Robby
>>
>> -----Original Message-----
>> From: mika@digikartta.net [3] [mailto:mika@digikartta.net [4]]
>> Sent: Wednesday, April 18, 2012 7:58 AM
>> To: users@cocoon.apache.org [5]
>> Subject: Re: Forms and maps
>>
>> 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. 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.
>>
>> cheers,
>> - mika -
>>
>> P.S. There are still several actors using C2.0..
>>
>> On Tue, 17 Apr 2012 22:49:37 +0200, Alberto
>> wrote:
>> > On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
>> >> Interesting,
>> >> I am also integrating maps into sites produced with Cocoon 2.1x.
>> I
>> >> have no answer to you but maybe we could collaborate on this
>> issue?
>> >> OpenLayers widget would be something!
>> >
>> > Just some considerations.
>> > I like very much cocoon, its philosophy, and the way to produce
>> > application with it and especially with forms. But we must remain
>> > realistic: in the last years the pace of the develop of cocoon is
>> > slow
>> > and the next release will be something different. For example,
>> the
>> > integration with Wicket seems to be the sign that forms will not
>> be
>> > more
>> > developed.
>> > Due to the fact that I don't know how to develop a new widget for
>> > cocoon, I was waiting for some clue or suggest to evaluate the
>> effort
>> > needed.
>> > Unfortunately I have not received any answer so I'm considering
>> to
>> > invest my time in another framework (Wicket) that can solve this
>> kind
>> > problem and has a future more outlined.
>> >
>> > Ciao
>> >
>> > Alberto
>> >
>> >
>> >>
>> >> cheers,
>> >> mika
>> >>
>> >>
>> >> 13.4.2012 20:03, Alberto kirjoitti:
>> >>> Hi,
>> >>>
>> >>> I'm using cocoon 2.1.12-dev and I'm facing how to include a map
>> in
>> >>> cocoon forms.
>> >>> I have to do simple things from flowscript: load a kml url and
>> >>> receive
>> >>> the coordinates of an area selection.
>> >>> I'm considering to use OpenLayers or Google Maps. Looking
>> sources I
>> >>> found already existing widget classes for GoogleMaps
>> >>> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is
>> >>> undocumented and
>> >>> using it I have the following error: "Non-existing component
>> for
>> >>> this
>> >>> hint (Key='googlemap')". Moreover it seems it lacks methods to
>> load
>> >>> a
>> >>> kml file.
>> >>>
>> >>> So, which is the best way to do it? The googlemap widget is
>> >>> working?
>> >>> I have to write a new widget following the document
>> >>> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets [7]?
>> >>>
>> >>> Any suggest is welcome
>> >>>
>> >>> Best regards
>> >>>
>> >>> Alberto
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [8]
>> >>> For additional commands, e-mail: users-help@cocoon.apache.org
>> [9]
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [10]
>> >> For additional commands, e-mail: users-help@cocoon.apache.org
>> [11]
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [12]
>> > For additional commands, e-mail: users-help@cocoon.apache.org
>> [13]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [14]
>> For additional commands, e-mail: users-help@cocoon.apache.org [15]
>>
>>
>>
>> Links:
>> ------
>> [1] mailto:Robby.Pelssers@nxp.com
>> [2] http://www.snoyman.com/blog/2012/04/xslt-rant.html
>> [3] mailto:mika@digikartta.net
>> [4] mailto:mika@digikartta.net
>> [5] mailto:users@cocoon.apache.org
>> [6] mailto:abrosich@ogs.trieste.it
>> [7] http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets
>> [8] mailto:users-unsubscribe@cocoon.apache.org
>> [9] mailto:users-help@cocoon.apache.org
>> [10] mailto:users-unsubscribe@cocoon.apache.org
>> [11] mailto:users-help@cocoon.apache.org
>> [12] mailto:users-unsubscribe@cocoon.apache.org
>> [13] mailto:users-help@cocoon.apache.org
>> [14] mailto:users-unsubscribe@cocoon.apache.org
>> [15] mailto:users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Forms and maps
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Wed, Apr 18, 2012 at 11:30:58AM +0200, Robby Pelssers wrote:
> You should read this article 'Why Good Programmers Are Lazy and Dumb' http://blogoscoped.com/archive/2005-08-24-n14.html
>
> I think it's not so much about losing our jobs but about
> - trying to become more productive (getting more done in the same amount of time)
> - avoiding repetitive work
I'm not sure which way the above is pointed, but anyway: which is
more productive:
o rewriting the same app. every six months until the end of time to
keep up with the fashion of the moment; or
o spending a few moments every now and then to maintain that app., and
the bulk of your time writing new app.s to address new needs?
Which is more repetitive?
The iPhone thing explains why I almost always carry an "outdated"
phone. It still does everything I want it to do. I'll trade it when
it doesn't do that anymore. I'd rather spend my money and time on an
unrelated, unmet need.
But maybe these arguments are pointless. Some projects need the
Latest Thing and other projects need stability and maintenance. If C3
is too big a break, gather others who feel the same way and fork C2
and share the maintenance and development.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Asking whether markets are efficient is like asking whether people are smart.
RE: Forms and maps
Posted by Robby Pelssers <Ro...@nxp.com>.
You should read this article 'Why Good Programmers Are Lazy and Dumb' http://blogoscoped.com/archive/2005-08-24-n14.html
I think it's not so much about losing our jobs but about
- trying to become more productive (getting more done in the same amount of time)
- avoiding repetitive work
The ones who do actually have more market value compared to their competitors. So even from financial point of view there is a drive towards doing exactly the above.
Why does Apple release a new iphone / ipad each year? Because they have to keep generating a income... That does not mean the previous products were of poor quality.
Robby
-----Original Message-----
From: mika@digikartta.net [mailto:mika@digikartta.net]
Sent: Wednesday, April 18, 2012 11:25 AM
To: users@cocoon.apache.org
Subject: RE: Forms and maps
Absolutely. But trying to stay on the edge of the trends won't fit for
us all.
And continous rewriting of apps doesn't make any sense. Why on earth we
can't create something that would last at least a decade?
Half of us would be out of jobs?
- mika -
On Wed, 18 Apr 2012 10:50:37 +0200, gelo1234 <ge...@gmail.com>
wrote:
> I totally agree with Robby's opinion. The trend is to use HTML5 on
> the client side in case of Web apps.
>
> Greetings,
> Greg
> 18-04-2012 10:27, "Robby Pelssers" napisał(a):
> Just my 2 cents on this topic...
>
> Cocoon forms was at the time in my eyes a pretty awesome solution to
> build highly dynamic forms with support for continuations. But as we
> all know this puts considerable strain on the server side. Gradually
> we started seeing a tendency towards AJAX (XmlHttpRequests) which is
> a
> fancy word for:
> - no complete page refresh
> - partial re-rendering of page
> - only fetching the minimal amount of data
> - let the browser do the heavy lifting
>
> This trend is evolving even further now with Websockets.
>
> One could easily say that the same discussions hold for database
> related technologies. Hibernate was the big revelation, a super
> abstraction over RDBMS dialects. It greatly reduces portability but
> it just doesn't always do the right thing (e.g. performance wise) so
> some people reverted back to plain jdbc wrappers.
>
> XSP was very convenient but it allows developers to mix controller /
> view which is now seen as a bad habit.
>
> Avalon was the way forward to configure your components at the time
> and next dependency injection became the most hyped buzzword. Spring
> framework and google juice came into play.
>
> I guess it's a matter of taste and the willingness to move forward.
> All (web)frameworks and technologies move forward (willingly or
> not):
> - new JDK
> - newer versions of dependencies
> - Ant --> maven
> - ...
>
> Recently there were some rants against XSLT
> (http://www.snoyman.com/blog/2012/04/xslt-rant.html [2] ). Just try
> transforming XML from your most favorite programming language and you
> might be in for a surprise. Surely XSLT takes a lot of typing but
> also XSLT is evolving just as XQuery is.
>
> I can only advise to take a good look around and find the best match
> for your requirements. If that is all about building dynamic forms
> wicket might be a good fit. Cocoon still is and certainly will be
> for the near future the best choice for transforming XML.
>
> Cheers,
> Robby
>
> -----Original Message-----
> From: mika@digikartta.net [3] [mailto:mika@digikartta.net [4]]
> Sent: Wednesday, April 18, 2012 7:58 AM
> To: users@cocoon.apache.org [5]
> Subject: Re: Forms and maps
>
> 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. 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.
>
> cheers,
> - mika -
>
> P.S. There are still several actors using C2.0..
>
> On Tue, 17 Apr 2012 22:49:37 +0200, Alberto
> wrote:
> > On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
> >> Interesting,
> >> I am also integrating maps into sites produced with Cocoon 2.1x.
> I
> >> have no answer to you but maybe we could collaborate on this
> issue?
> >> OpenLayers widget would be something!
> >
> > Just some considerations.
> > I like very much cocoon, its philosophy, and the way to produce
> > application with it and especially with forms. But we must remain
> > realistic: in the last years the pace of the develop of cocoon is
> > slow
> > and the next release will be something different. For example, the
> > integration with Wicket seems to be the sign that forms will not
> be
> > more
> > developed.
> > Due to the fact that I don't know how to develop a new widget for
> > cocoon, I was waiting for some clue or suggest to evaluate the
> effort
> > needed.
> > Unfortunately I have not received any answer so I'm considering to
> > invest my time in another framework (Wicket) that can solve this
> kind
> > problem and has a future more outlined.
> >
> > Ciao
> >
> > Alberto
> >
> >
> >>
> >> cheers,
> >> mika
> >>
> >>
> >> 13.4.2012 20:03, Alberto kirjoitti:
> >>> Hi,
> >>>
> >>> I'm using cocoon 2.1.12-dev and I'm facing how to include a map
> in
> >>> cocoon forms.
> >>> I have to do simple things from flowscript: load a kml url and
> >>> receive
> >>> the coordinates of an area selection.
> >>> I'm considering to use OpenLayers or Google Maps. Looking
> sources I
> >>> found already existing widget classes for GoogleMaps
> >>> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is
> >>> undocumented and
> >>> using it I have the following error: "Non-existing component for
> >>> this
> >>> hint (Key='googlemap')". Moreover it seems it lacks methods to
> load
> >>> a
> >>> kml file.
> >>>
> >>> So, which is the best way to do it? The googlemap widget is
> >>> working?
> >>> I have to write a new widget following the document
> >>> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets [7]?
> >>>
> >>> Any suggest is welcome
> >>>
> >>> Best regards
> >>>
> >>> Alberto
> >>>
> >>>
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [8]
> >>> For additional commands, e-mail: users-help@cocoon.apache.org
> [9]
> >>>
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [10]
> >> For additional commands, e-mail: users-help@cocoon.apache.org
> [11]
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [12]
> > For additional commands, e-mail: users-help@cocoon.apache.org [13]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [14]
> For additional commands, e-mail: users-help@cocoon.apache.org [15]
>
>
>
> Links:
> ------
> [1] mailto:Robby.Pelssers@nxp.com
> [2] http://www.snoyman.com/blog/2012/04/xslt-rant.html
> [3] mailto:mika@digikartta.net
> [4] mailto:mika@digikartta.net
> [5] mailto:users@cocoon.apache.org
> [6] mailto:abrosich@ogs.trieste.it
> [7] http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets
> [8] mailto:users-unsubscribe@cocoon.apache.org
> [9] mailto:users-help@cocoon.apache.org
> [10] mailto:users-unsubscribe@cocoon.apache.org
> [11] mailto:users-help@cocoon.apache.org
> [12] mailto:users-unsubscribe@cocoon.apache.org
> [13] mailto:users-help@cocoon.apache.org
> [14] mailto:users-unsubscribe@cocoon.apache.org
> [15] mailto:users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Forms and maps
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Wed, Apr 18, 2012 at 11:54:40AM +0200, Thorsten Scherler wrote:
> On 04/18/2012 11:24 AM, mika@digikartta.net wrote:
[snip]
> > Half of us would be out of jobs?
>
> jeje actually that is point of view. I know of colleagues that maintain
> some buggy developments and earn a good living. The prob in general in
> cocoon where that if you do it right the first time you have no
> maintenance. So e.g. upgrading and rewriting some apps brings us work.
Ha! I am now recalling an old cartoon. There's a diesel locomotive
pulling a flatcar. On the flatcar is a man shovelling coal onto a
conveyor that carries the coal back to the pile from which he is
shovelling. He has a job, but....
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Doing a revision is like chewing used gum. -- Asimov
Re: Forms and maps
Posted by Thorsten Scherler <sc...@gmail.com>.
On 04/18/2012 11:24 AM, mika@digikartta.net wrote:
>
> Absolutely. But trying to stay on the edge of the trends won't fit for
> us all.
> And continous rewriting of apps doesn't make any sense. Why on earth
> we can't create something that would last at least a decade?
jeje, I actually know about some of my old c2.0.x apps that are still in
production and have not failed once in over 10 years.
> Half of us would be out of jobs?
jeje actually that is point of view. I know of colleagues that maintain
some buggy developments and earn a good living. The prob in general in
cocoon where that if you do it right the first time you have no
maintenance. So e.g. upgrading and rewriting some apps brings us work.
salu2
--
Thorsten Scherler<scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Forms and maps
Posted by mi...@digikartta.net.
Absolutely. But trying to stay on the edge of the trends won't fit for
us all.
And continous rewriting of apps doesn't make any sense. Why on earth we
can't create something that would last at least a decade?
Half of us would be out of jobs?
- mika -
On Wed, 18 Apr 2012 10:50:37 +0200, gelo1234 <ge...@gmail.com>
wrote:
> I totally agree with Robby's opinion. The trend is to use HTML5 on
> the client side in case of Web apps.
>
> Greetings,
> Greg
> 18-04-2012 10:27, "Robby Pelssers" napisał(a):
> Just my 2 cents on this topic...
>
> Cocoon forms was at the time in my eyes a pretty awesome solution to
> build highly dynamic forms with support for continuations. But as we
> all know this puts considerable strain on the server side. Gradually
> we started seeing a tendency towards AJAX (XmlHttpRequests) which is
> a
> fancy word for:
> - no complete page refresh
> - partial re-rendering of page
> - only fetching the minimal amount of data
> - let the browser do the heavy lifting
>
> This trend is evolving even further now with Websockets.
>
> One could easily say that the same discussions hold for database
> related technologies. Hibernate was the big revelation, a super
> abstraction over RDBMS dialects. It greatly reduces portability but
> it just doesn't always do the right thing (e.g. performance wise) so
> some people reverted back to plain jdbc wrappers.
>
> XSP was very convenient but it allows developers to mix controller /
> view which is now seen as a bad habit.
>
> Avalon was the way forward to configure your components at the time
> and next dependency injection became the most hyped buzzword. Spring
> framework and google juice came into play.
>
> I guess it's a matter of taste and the willingness to move forward.
> All (web)frameworks and technologies move forward (willingly or
> not):
> - new JDK
> - newer versions of dependencies
> - Ant --> maven
> - ...
>
> Recently there were some rants against XSLT
> (http://www.snoyman.com/blog/2012/04/xslt-rant.html [2] ). Just try
> transforming XML from your most favorite programming language and you
> might be in for a surprise. Surely XSLT takes a lot of typing but
> also XSLT is evolving just as XQuery is.
>
> I can only advise to take a good look around and find the best match
> for your requirements. If that is all about building dynamic forms
> wicket might be a good fit. Cocoon still is and certainly will be
> for the near future the best choice for transforming XML.
>
> Cheers,
> Robby
>
> -----Original Message-----
> From: mika@digikartta.net [3] [mailto:mika@digikartta.net [4]]
> Sent: Wednesday, April 18, 2012 7:58 AM
> To: users@cocoon.apache.org [5]
> Subject: Re: Forms and maps
>
> 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. 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.
>
> cheers,
> - mika -
>
> P.S. There are still several actors using C2.0..
>
> On Tue, 17 Apr 2012 22:49:37 +0200, Alberto
> wrote:
> > On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
> >> Interesting,
> >> I am also integrating maps into sites produced with Cocoon 2.1x.
> I
> >> have no answer to you but maybe we could collaborate on this
> issue?
> >> OpenLayers widget would be something!
> >
> > Just some considerations.
> > I like very much cocoon, its philosophy, and the way to produce
> > application with it and especially with forms. But we must remain
> > realistic: in the last years the pace of the develop of cocoon is
> > slow
> > and the next release will be something different. For example, the
> > integration with Wicket seems to be the sign that forms will not
> be
> > more
> > developed.
> > Due to the fact that I don't know how to develop a new widget for
> > cocoon, I was waiting for some clue or suggest to evaluate the
> effort
> > needed.
> > Unfortunately I have not received any answer so I'm considering to
> > invest my time in another framework (Wicket) that can solve this
> kind
> > problem and has a future more outlined.
> >
> > Ciao
> >
> > Alberto
> >
> >
> >>
> >> cheers,
> >> mika
> >>
> >>
> >> 13.4.2012 20:03, Alberto kirjoitti:
> >>> Hi,
> >>>
> >>> I'm using cocoon 2.1.12-dev and I'm facing how to include a map
> in
> >>> cocoon forms.
> >>> I have to do simple things from flowscript: load a kml url and
> >>> receive
> >>> the coordinates of an area selection.
> >>> I'm considering to use OpenLayers or Google Maps. Looking
> sources I
> >>> found already existing widget classes for GoogleMaps
> >>> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is
> >>> undocumented and
> >>> using it I have the following error: "Non-existing component for
> >>> this
> >>> hint (Key='googlemap')". Moreover it seems it lacks methods to
> load
> >>> a
> >>> kml file.
> >>>
> >>> So, which is the best way to do it? The googlemap widget is
> >>> working?
> >>> I have to write a new widget following the document
> >>> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets [7]?
> >>>
> >>> Any suggest is welcome
> >>>
> >>> Best regards
> >>>
> >>> Alberto
> >>>
> >>>
> >>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [8]
> >>> For additional commands, e-mail: users-help@cocoon.apache.org
> [9]
> >>>
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [10]
> >> For additional commands, e-mail: users-help@cocoon.apache.org
> [11]
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [12]
> > For additional commands, e-mail: users-help@cocoon.apache.org [13]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org [14]
> For additional commands, e-mail: users-help@cocoon.apache.org [15]
>
>
>
> Links:
> ------
> [1] mailto:Robby.Pelssers@nxp.com
> [2] http://www.snoyman.com/blog/2012/04/xslt-rant.html
> [3] mailto:mika@digikartta.net
> [4] mailto:mika@digikartta.net
> [5] mailto:users@cocoon.apache.org
> [6] mailto:abrosich@ogs.trieste.it
> [7] http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets
> [8] mailto:users-unsubscribe@cocoon.apache.org
> [9] mailto:users-help@cocoon.apache.org
> [10] mailto:users-unsubscribe@cocoon.apache.org
> [11] mailto:users-help@cocoon.apache.org
> [12] mailto:users-unsubscribe@cocoon.apache.org
> [13] mailto:users-help@cocoon.apache.org
> [14] mailto:users-unsubscribe@cocoon.apache.org
> [15] mailto:users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Forms and maps
Posted by gelo1234 <ge...@gmail.com>.
I totally agree with Robby's opinion. The trend is to use HTML5 on the
client side in case of Web apps.
Greetings,
Greg
18-04-2012 10:27, "Robby Pelssers" <Ro...@nxp.com> napisał(a):
> Just my 2 cents on this topic...
>
> Cocoon forms was at the time in my eyes a pretty awesome solution to build
> highly dynamic forms with support for continuations. But as we all know
> this puts considerable strain on the server side. Gradually we started
> seeing a tendency towards AJAX (XmlHttpRequests) which is a fancy word for:
> - no complete page refresh
> - partial re-rendering of page
> - only fetching the minimal amount of data
> - let the browser do the heavy lifting
>
> This trend is evolving even further now with Websockets.
>
> One could easily say that the same discussions hold for database related
> technologies. Hibernate was the big revelation, a super abstraction over
> RDBMS dialects. It greatly reduces portability but it just doesn't always
> do the right thing (e.g. performance wise) so some people reverted back to
> plain jdbc wrappers.
>
> XSP was very convenient but it allows developers to mix controller / view
> which is now seen as a bad habit.
>
> Avalon was the way forward to configure your components at the time and
> next dependency injection became the most hyped buzzword. Spring framework
> and google juice came into play.
>
> I guess it's a matter of taste and the willingness to move forward. All
> (web)frameworks and technologies move forward (willingly or not):
> - new JDK
> - newer versions of dependencies
> - Ant --> maven
> - ...
>
> Recently there were some rants against XSLT (
> http://www.snoyman.com/blog/2012/04/xslt-rant.html ). Just try
> transforming XML from your most favorite programming language and you might
> be in for a surprise. Surely XSLT takes a lot of typing but also XSLT is
> evolving just as XQuery is.
>
> I can only advise to take a good look around and find the best match for
> your requirements. If that is all about building dynamic forms wicket
> might be a good fit. Cocoon still is and certainly will be for the near
> future the best choice for transforming XML.
>
> Cheers,
> Robby
>
>
>
> -----Original Message-----
> From: mika@digikartta.net [mailto:mika@digikartta.net]
> Sent: Wednesday, April 18, 2012 7:58 AM
> To: users@cocoon.apache.org
> Subject: Re: Forms and maps
>
>
> 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. 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.
>
> cheers,
> - mika -
>
> P.S. There are still several actors using C2.0..
>
>
> On Tue, 17 Apr 2012 22:49:37 +0200, Alberto <ab...@ogs.trieste.it>
> wrote:
> > On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
> >> Interesting,
> >> I am also integrating maps into sites produced with Cocoon 2.1x. I
> >> have no answer to you but maybe we could collaborate on this issue?
> >> OpenLayers widget would be something!
> >
> > Just some considerations.
> > I like very much cocoon, its philosophy, and the way to produce
> > application with it and especially with forms. But we must remain
> > realistic: in the last years the pace of the develop of cocoon is
> > slow
> > and the next release will be something different. For example, the
> > integration with Wicket seems to be the sign that forms will not be
> > more
> > developed.
> > Due to the fact that I don't know how to develop a new widget for
> > cocoon, I was waiting for some clue or suggest to evaluate the effort
> > needed.
> > Unfortunately I have not received any answer so I'm considering to
> > invest my time in another framework (Wicket) that can solve this kind
> > problem and has a future more outlined.
> >
> > Ciao
> >
> > Alberto
> >
> >
> >>
> >> cheers,
> >> mika
> >>
> >>
> >> 13.4.2012 20:03, Alberto kirjoitti:
> >>> Hi,
> >>>
> >>> I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
> >>> cocoon forms.
> >>> I have to do simple things from flowscript: load a kml url and
> >>> receive
> >>> the coordinates of an area selection.
> >>> I'm considering to use OpenLayers or Google Maps. Looking sources I
> >>> found already existing widget classes for GoogleMaps
> >>> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is
> >>> undocumented and
> >>> using it I have the following error: "Non-existing component for
> >>> this
> >>> hint (Key='googlemap')". Moreover it seems it lacks methods to load
> >>> a
> >>> kml file.
> >>>
> >>> So, which is the best way to do it? The googlemap widget is
> >>> working?
> >>> I have to write a new widget following the document
> >>> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
> >>>
> >>> Any suggest is welcome
> >>>
> >>> Best regards
> >>>
> >>> Alberto
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> >>> For additional commands, e-mail: users-help@cocoon.apache.org
> >>>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> >> For additional commands, e-mail: users-help@cocoon.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
RE: Forms and maps
Posted by Robby Pelssers <Ro...@nxp.com>.
Just my 2 cents on this topic...
Cocoon forms was at the time in my eyes a pretty awesome solution to build highly dynamic forms with support for continuations. But as we all know this puts considerable strain on the server side. Gradually we started seeing a tendency towards AJAX (XmlHttpRequests) which is a fancy word for:
- no complete page refresh
- partial re-rendering of page
- only fetching the minimal amount of data
- let the browser do the heavy lifting
This trend is evolving even further now with Websockets.
One could easily say that the same discussions hold for database related technologies. Hibernate was the big revelation, a super abstraction over RDBMS dialects. It greatly reduces portability but it just doesn't always do the right thing (e.g. performance wise) so some people reverted back to plain jdbc wrappers.
XSP was very convenient but it allows developers to mix controller / view which is now seen as a bad habit.
Avalon was the way forward to configure your components at the time and next dependency injection became the most hyped buzzword. Spring framework and google juice came into play.
I guess it's a matter of taste and the willingness to move forward. All (web)frameworks and technologies move forward (willingly or not):
- new JDK
- newer versions of dependencies
- Ant --> maven
- ...
Recently there were some rants against XSLT (http://www.snoyman.com/blog/2012/04/xslt-rant.html ). Just try transforming XML from your most favorite programming language and you might be in for a surprise. Surely XSLT takes a lot of typing but also XSLT is evolving just as XQuery is.
I can only advise to take a good look around and find the best match for your requirements. If that is all about building dynamic forms wicket might be a good fit. Cocoon still is and certainly will be for the near future the best choice for transforming XML.
Cheers,
Robby
-----Original Message-----
From: mika@digikartta.net [mailto:mika@digikartta.net]
Sent: Wednesday, April 18, 2012 7:58 AM
To: users@cocoon.apache.org
Subject: Re: Forms and maps
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. 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.
cheers,
- mika -
P.S. There are still several actors using C2.0..
On Tue, 17 Apr 2012 22:49:37 +0200, Alberto <ab...@ogs.trieste.it>
wrote:
> On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
>> Interesting,
>> I am also integrating maps into sites produced with Cocoon 2.1x. I
>> have no answer to you but maybe we could collaborate on this issue?
>> OpenLayers widget would be something!
>
> Just some considerations.
> I like very much cocoon, its philosophy, and the way to produce
> application with it and especially with forms. But we must remain
> realistic: in the last years the pace of the develop of cocoon is
> slow
> and the next release will be something different. For example, the
> integration with Wicket seems to be the sign that forms will not be
> more
> developed.
> Due to the fact that I don't know how to develop a new widget for
> cocoon, I was waiting for some clue or suggest to evaluate the effort
> needed.
> Unfortunately I have not received any answer so I'm considering to
> invest my time in another framework (Wicket) that can solve this kind
> problem and has a future more outlined.
>
> Ciao
>
> Alberto
>
>
>>
>> cheers,
>> mika
>>
>>
>> 13.4.2012 20:03, Alberto kirjoitti:
>>> Hi,
>>>
>>> I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
>>> cocoon forms.
>>> I have to do simple things from flowscript: load a kml url and
>>> receive
>>> the coordinates of an area selection.
>>> I'm considering to use OpenLayers or Google Maps. Looking sources I
>>> found already existing widget classes for GoogleMaps
>>> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is
>>> undocumented and
>>> using it I have the following error: "Non-existing component for
>>> this
>>> hint (Key='googlemap')". Moreover it seems it lacks methods to load
>>> a
>>> kml file.
>>>
>>> So, which is the best way to do it? The googlemap widget is
>>> working?
>>> I have to write a new widget following the document
>>> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
>>>
>>> Any suggest is welcome
>>>
>>> Best regards
>>>
>>> Alberto
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Forms and maps
Posted by mi...@digikartta.net.
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. 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.
cheers,
- mika -
P.S. There are still several actors using C2.0..
On Tue, 17 Apr 2012 22:49:37 +0200, Alberto <ab...@ogs.trieste.it>
wrote:
> On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
>> Interesting,
>> I am also integrating maps into sites produced with Cocoon 2.1x. I
>> have no answer to you but maybe we could collaborate on this issue?
>> OpenLayers widget would be something!
>
> Just some considerations.
> I like very much cocoon, its philosophy, and the way to produce
> application with it and especially with forms. But we must remain
> realistic: in the last years the pace of the develop of cocoon is
> slow
> and the next release will be something different. For example, the
> integration with Wicket seems to be the sign that forms will not be
> more
> developed.
> Due to the fact that I don't know how to develop a new widget for
> cocoon, I was waiting for some clue or suggest to evaluate the effort
> needed.
> Unfortunately I have not received any answer so I'm considering to
> invest my time in another framework (Wicket) that can solve this kind
> problem and has a future more outlined.
>
> Ciao
>
> Alberto
>
>
>>
>> cheers,
>> mika
>>
>>
>> 13.4.2012 20:03, Alberto kirjoitti:
>>> Hi,
>>>
>>> I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
>>> cocoon forms.
>>> I have to do simple things from flowscript: load a kml url and
>>> receive
>>> the coordinates of an area selection.
>>> I'm considering to use OpenLayers or Google Maps. Looking sources I
>>> found already existing widget classes for GoogleMaps
>>> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is
>>> undocumented and
>>> using it I have the following error: "Non-existing component for
>>> this
>>> hint (Key='googlemap')". Moreover it seems it lacks methods to load
>>> a
>>> kml file.
>>>
>>> So, which is the best way to do it? The googlemap widget is
>>> working?
>>> I have to write a new widget following the document
>>> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
>>>
>>> Any suggest is welcome
>>>
>>> Best regards
>>>
>>> Alberto
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Forms and maps
Posted by gelo1234 <ge...@gmail.com>.
Hello,
I would like to share my opinion on C3. I think that dropping support for
the most of native Cocoon components is a good step forward. As you see
trends now in enterprise applications, everybody from RedHat to Oracle
limits the amount of code from bare application server core engine making
it smaller, lighter and faster. As to additional components or modules they
are only supported if compliant with standards and mostly through separate
bundles/libraries or connectors.
There is 1 standard in Java world concerning Enterprise Java Apps - its
Java EE.
And C3 adheres to that standard through the strong RESTful Web Services
support. And I think the goal is to provide very light and fast web
services engine besides being robust integration platform. And in order to
stay competitive it must adhere to standards. Nobody will be interested in
developing non-standard components that are just equivalents of other
standard-compliant frameworks/bundles. Instead of writing its own versions
of additional components Cocoon should provide support for any necessary
standard on the market through the use of connectors/API to
components/technologies that are already used in other frameworks. That
reusability guarantees further development of the whole platform.
If you design your application by decoupling functionality among separate
services which is the concept of SOA, its very important to have very
loosely coupled components that can support any technology available on the
market. Its a nonsense and very error-prone trying to provide native
modules for any relevant technology.
And if some technology works better than other one, why not just use it?
It relates to Cocoon Forms and Wicket or JSF.
Any competitive platform now should be opened to any available technology
and should provide support for such one, while concentrating on its core
job - in case of Cocoon I presume it to be extensive XML processing and
RESTful Web Services.
According to my experience with Cocoon its a very robust platform in terms
of XML processing and data integration. And while we still use very old
release in production - 2.0.5, it still meets our goals by providing
functionality similar to today's ESB and a mix of WS-* (SOAP) and RESTful
Web Services. In case of web front-ends, we don't use any non-standard
compliant modules like Forms. Instead we use a bunch of open reliable
external libraries like JSTL, Velocity, Dojo, jQuery or jQuery Mobile to
build very satisfactory user-experience. We also make extensive use of
Google Maps through Google Maps API from Javascript/jQuery. We don't need
and don't want to use any non-standard Google Maps component from Cocoon.
Its all about the design of your app.
Greetings,
Greg
17-04-2012 22:50, "Alberto" <ab...@ogs.trieste.it> napisał(a):
> On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
> > Interesting,
> > I am also integrating maps into sites produced with Cocoon 2.1x. I
> > have no answer to you but maybe we could collaborate on this issue?
> > OpenLayers widget would be something!
>
> Just some considerations.
> I like very much cocoon, its philosophy, and the way to produce
> application with it and especially with forms. But we must remain
> realistic: in the last years the pace of the develop of cocoon is slow
> and the next release will be something different. For example, the
> integration with Wicket seems to be the sign that forms will not be more
> developed.
> Due to the fact that I don't know how to develop a new widget for
> cocoon, I was waiting for some clue or suggest to evaluate the effort
> needed.
> Unfortunately I have not received any answer so I'm considering to
> invest my time in another framework (Wicket) that can solve this kind
> problem and has a future more outlined.
>
> Ciao
>
> Alberto
>
>
> >
> > cheers,
> > mika
> >
> >
> > 13.4.2012 20:03, Alberto kirjoitti:
> >> Hi,
> >>
> >> I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
> >> cocoon forms.
> >> I have to do simple things from flowscript: load a kml url and receive
> >> the coordinates of an area selection.
> >> I'm considering to use OpenLayers or Google Maps. Looking sources I
> >> found already existing widget classes for GoogleMaps
> >> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is undocumented and
> >> using it I have the following error: "Non-existing component for this
> >> hint (Key='googlemap')". Moreover it seems it lacks methods to load a
> >> kml file.
> >>
> >> So, which is the best way to do it? The googlemap widget is working?
> >> I have to write a new widget following the document
> >> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
> >>
> >> Any suggest is welcome
> >>
> >> Best regards
> >>
> >> Alberto
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> >> For additional commands, e-mail: users-help@cocoon.apache.org
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: Forms and maps
Posted by Alberto <ab...@ogs.trieste.it>.
On 04/13/2012 07:18 PM, Mika M Lehtonen wrote:
> Interesting,
> I am also integrating maps into sites produced with Cocoon 2.1x. I
> have no answer to you but maybe we could collaborate on this issue?
> OpenLayers widget would be something!
Just some considerations.
I like very much cocoon, its philosophy, and the way to produce
application with it and especially with forms. But we must remain
realistic: in the last years the pace of the develop of cocoon is slow
and the next release will be something different. For example, the
integration with Wicket seems to be the sign that forms will not be more
developed.
Due to the fact that I don't know how to develop a new widget for
cocoon, I was waiting for some clue or suggest to evaluate the effort
needed.
Unfortunately I have not received any answer so I'm considering to
invest my time in another framework (Wicket) that can solve this kind
problem and has a future more outlined.
Ciao
Alberto
>
> cheers,
> mika
>
>
> 13.4.2012 20:03, Alberto kirjoitti:
>> Hi,
>>
>> I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
>> cocoon forms.
>> I have to do simple things from flowscript: load a kml url and receive
>> the coordinates of an area selection.
>> I'm considering to use OpenLayers or Google Maps. Looking sources I
>> found already existing widget classes for GoogleMaps
>> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is undocumented and
>> using it I have the following error: "Non-existing component for this
>> hint (Key='googlemap')". Moreover it seems it lacks methods to load a
>> kml file.
>>
>> So, which is the best way to do it? The googlemap widget is working?
>> I have to write a new widget following the document
>> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
>>
>> Any suggest is welcome
>>
>> Best regards
>>
>> Alberto
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Forms and maps
Posted by Mika M Lehtonen <mi...@digikartta.net>.
Interesting,
I am also integrating maps into sites produced with Cocoon 2.1x. I have
no answer to you but maybe we could collaborate on this issue?
OpenLayers widget would be something!
cheers,
mika
13.4.2012 20:03, Alberto kirjoitti:
> Hi,
>
> I'm using cocoon 2.1.12-dev and I'm facing how to include a map in
> cocoon forms.
> I have to do simple things from flowscript: load a kml url and receive
> the coordinates of an area selection.
> I'm considering to use OpenLayers or Google Maps. Looking sources I
> found already existing widget classes for GoogleMaps
> (org.apache.cocoon.forms.formmodel.GoogleMap) but it is undocumented and
> using it I have the following error: "Non-existing component for this
> hint (Key='googlemap')". Moreover it seems it lacks methods to load a
> kml file.
>
> So, which is the best way to do it? The googlemap widget is working?
> I have to write a new widget following the document
> http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets?
>
> Any suggest is welcome
>
> Best regards
>
> Alberto
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org