RE: cocoon migrate from 2.1 to 2.2 or 3 (was Re: Forms and maps)
Hi Thorsten, This line kind of triggered me to reply: you can even use even generic app generator to create native android, etc. apps without writing a single line of code Are you aware of people having done so or were you involved yourself? If so... you don't happen to have some guidelines or sample app to take a look at? Cheers, Robby -Original Message- From: Thorsten Scherler [mailto:scher...@gmail.com] Sent: Wednesday, April 18, 2012 5:08 PM To: users@cocoon.apache.org Subject: cocoon migrate from 2.1 to 2.2 or 3 (was Re: Forms and maps) The whole thread had changed the subject a long time ago ... On 04/18/2012 03:29 PM, Mark H. Wood wrote: On Wed, Apr 18, 2012 at 11:34:26AM +0200, Derek Hohls wrote: It all depends on your environment and the rate of change. There are many back-end systems (running on old but reliable technology) that hardly change at all. However, the web (and now tablets/mobile) has a very high rate of change (and expectation of change). The point here is that by using more loosely-coupled modules then you will only have to change the parts that really need to be changed; a monolithic approach is less amenable to that. I think this may actually underscore the O.P.'s point. Changing the whole world in one go is the monolithic approach. The modular approach would enable choosing new mechanisms for new work and sticking with old, established mechanisms for existing, still-useful work when that makes sense. Having to throw out piles of satisfactory working code just to use a dependency version that still has the attention of its maintainers is really unwelcome. I think the complaint is that Cocoon 3 is really Butterfly 1. Well, yes and no. If you have experience with c2.x you can do close to the same thing on c3. Most of the pipelines i saw are pure generator - xsl transform - serializer stuff that has not changed a bit. Yes there are some components not yet migrated but we are an open source project and welcome every patch. However the basic idea from the start of 2.1 blocks had been to slim down cocoon. c3 is the consequence of 10 years of slim down. To pin it down on a concrete code example if you wanted a specific component in c2.1 you needed to get hold of an avalon manager, ask the manager to lookup your component (or additional ones to do the final lookup). Every component needed to be configured and registered with the manager. Leaving your 20 lines of code being 90% boilerplate code. In comparison in c3 you do @Autowired @Qualifier(messageSource) ReloadableResourceBundleMessageSource messageSource; To inject your variables and creating a setter you are not forced to even use spring BUT you can still reuse your code. ...and best NO boileplate code, resulting is much cleaner code. I had chosen c3 as base framework for our current project because that allowed me to have pure java devs in my team that never worked with cocoon at all and they were productive since day one (which is not possible in 2.x having made that experience in other projects). Bottom line regarding forms handling html5 + ajax framework + your js + css as view technologies and c3 rest service as form action handler is a beautiful base due to various reasons: - mobile ready (you can even use even generic app generator to create native android, etc. apps without writing a single line of code) - REST services are not bound to c3 - REST services can call or even dynamically create c3 based pipelines. -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/ - 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
Re: cocoon migrate from 2.1 to 2.2 or 3 (was Re: Forms and maps)
On 04/18/2012 09:36 PM, Mika M Lehtonen wrote: Ouh, I didn't realize what kind of the avalanche of arguments I would start. Maybe this tells that there is something bubbling under. I don't want to hurt anyones feelings. I don't want bad blood. No, no bad blood at all. I think there are so many different level persons involved in this, that it will cause some misunderstandings from time time to time. I like Cocoon, I like C2.1, I like C2.2, I like C3 and probably I will like C4. I believe I understand those who are Cocoon developers or somehow else near it. But maybe you who are inside don't understand dudes like me. Robby wrote in his final statement that Just like we all use Java.. I do not use Java. When I first get to know Cocoon, I hadn't have written a single line of Java. Nowadays I have written maybe 50 or 100 lines. Other languages yes, but not Java. I liked Cocoon 2.1 because I could do neat things without knowing a single decent programming language. After then, I have written quite a lot with C#, but not with Java. Still I like Cocoon. Believe me I know exactly what you mean. I started like you: http://markmail.org/message/uw2garygytcbyifq the first years I was using cocoon but only xsl and wiring some components. I never touched java at all those days. However that is still possible with c3. We have an intern ATM that is doing exactly that, using c3 to do some xsl and fo transformation. I do think that C3 is a clever thing to do. I do. I am hoping that I will get into it some day. But because I do this for living, I can't jump to it right away. C2.1 is the most familiar. Have to start with it. Then maybe C2.2 and finally C3. Or just forget the whole thing. The latter is the way I chose a couple of years ago. But I may have changed my decision. I would recommend to skip c2.2 and try c3. I had the chance to play with it in a smaller project before I chosen it for the upcoming bigger deployment. Having this all said I understand that people stick with c2.1 and not migrating their development to c3 and that is perfectly fine. we love all versions of cocoon here. ;) BTW since c3 is very clean written (mostly) it is a good place to understand as well java. ;) salu2 -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: cocoon migrate from 2.1 to 2.2 or 3 (was Re: Forms and maps)
Thorsten, thank you for your feedback. Yeah, I think I will switch to C3 some day near, that is, if we'll decide to continue with Cocoon. One app is on it's way to final. How succesful it is, will make quite a big difference whether we continue or not. I hope we do. - mika - On Thu, 19 Apr 2012 11:14:34 +0200, Thorsten Scherler scher...@gmail.com wrote: On 04/18/2012 09:36 PM, Mika M Lehtonen wrote: Ouh, I didn't realize what kind of the avalanche of arguments I would start. Maybe this tells that there is something bubbling under. I don't want to hurt anyones feelings. I don't want bad blood. No, no bad blood at all. I think there are so many different level persons involved in this, that it will cause some misunderstandings from time time to time. I like Cocoon, I like C2.1, I like C2.2, I like C3 and probably I will like C4. I believe I understand those who are Cocoon developers or somehow else near it. But maybe you who are inside don't understand dudes like me. Robby wrote in his final statement that Just like we all use Java.. I do not use Java. When I first get to know Cocoon, I hadn't have written a single line of Java. Nowadays I have written maybe 50 or 100 lines. Other languages yes, but not Java. I liked Cocoon 2.1 because I could do neat things without knowing a single decent programming language. After then, I have written quite a lot with C#, but not with Java. Still I like Cocoon. Believe me I know exactly what you mean. I started like you: http://markmail.org/message/uw2garygytcbyifq the first years I was using cocoon but only xsl and wiring some components. I never touched java at all those days. However that is still possible with c3. We have an intern ATM that is doing exactly that, using c3 to do some xsl and fo transformation. I do think that C3 is a clever thing to do. I do. I am hoping that I will get into it some day. But because I do this for living, I can't jump to it right away. C2.1 is the most familiar. Have to start with it. Then maybe C2.2 and finally C3. Or just forget the whole thing. The latter is the way I chose a couple of years ago. But I may have changed my decision. I would recommend to skip c2.2 and try c3. I had the chance to play with it in a smaller project before I chosen it for the upcoming bigger deployment. Having this all said I understand that people stick with c2.1 and not migrating their development to c3 and that is perfectly fine. we love all versions of cocoon here. ;) BTW since c3 is very clean written (mostly) it is a good place to understand as well java. ;) salu2 - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Forms and maps
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 abros...@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-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
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 gelo1...@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: m...@digikartta.net [3] [mailto:m...@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
RE: Forms and maps
Mika It all depends on your environment and the rate of change. There are many back-end systems (running on old but reliable technology) that hardly change at all. However, the web (and now tablets/mobile) has a very high rate of change (and expectation of change). The point here is that by using more loosely-coupled modules then you will only have to change the parts that really need to be changed; a monolithic approach is less amenable to that. Derek (And yes, of course, we are all helping to ensure that there are more - not less - jobs in future!) 04/18/12 11:25 AM 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 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: m...@digikartta.net [3] [mailto:m...@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 thethe 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
Re: Forms and maps
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 -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
RE: Forms and maps
That's a good one! - mika - On Wed, 18 Apr 2012 11:30:58 +0200, Robby Pelssers robby.pelss...@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: m...@digikartta.net [mailto:m...@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 gelo1...@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: m...@digikartta.net [3] [mailto:m...@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
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
Re: Forms and maps
On 04/18/2012 11:24 AM, m...@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 Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
RE: Forms and maps
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
RE: Forms and maps
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
Re: Forms and maps
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 mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpUETbqeTWQe.pgp Description: PGP signature
Re: Forms and maps
On Wed, Apr 18, 2012 at 11:34:26AM +0200, Derek Hohls wrote: It all depends on your environment and the rate of change. There are many back-end systems (running on old but reliable technology) that hardly change at all. However, the web (and now tablets/mobile) has a very high rate of change (and expectation of change). The point here is that by using more loosely-coupled modules then you will only have to change the parts that really need to be changed; a monolithic approach is less amenable to that. I think this may actually underscore the O.P.'s point. Changing the whole world in one go is the monolithic approach. The modular approach would enable choosing new mechanisms for new work and sticking with old, established mechanisms for existing, still-useful work when that makes sense. Having to throw out piles of satisfactory working code just to use a dependency version that still has the attention of its maintainers is really unwelcome. I think the complaint is that Cocoon 3 is really Butterfly 1. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgp8QKsMr5QTr.pgp Description: PGP signature
RE: Forms and maps
Although I don't think this mailing list is the appropriate list to discuss these kinds of issues I will post my final word on this. Just like we all use Java (at least the ones working with Cocoon) most of us should be fair to admit that Java's progress is heavily been slowed down by trying to be backwards compatible. Lots of newer/cooler/more productive languages have evolved among which to name an example is Scala. One of the key arguments for C3 was in fact opening up the opportunity to: - run a pipeline from command line - embed cocoon into other frameworks And although you might have no need for this, I think it enables freedom / choice which is a great thing. So C3's mission statement could very well be: - you choose your favourite (web)stack and we will take care of the XML processing. - Or you could use C3's REST controllers and stick with 1 single framework Robby -Original Message- From: Mark H. Wood [mailto:mw...@iupui.edu] Sent: Wednesday, April 18, 2012 3:29 PM To: users@cocoon.apache.org Subject: Re: Forms and maps On Wed, Apr 18, 2012 at 11:34:26AM +0200, Derek Hohls wrote: It all depends on your environment and the rate of change. There are many back-end systems (running on old but reliable technology) that hardly change at all. However, the web (and now tablets/mobile) has a very high rate of change (and expectation of change). The point here is that by using more loosely-coupled modules then you will only have to change the parts that really need to be changed; a monolithic approach is less amenable to that. I think this may actually underscore the O.P.'s point. Changing the whole world in one go is the monolithic approach. The modular approach would enable choosing new mechanisms for new work and sticking with old, established mechanisms for existing, still-useful work when that makes sense. Having to throw out piles of satisfactory working code just to use a dependency version that still has the attention of its maintainers is really unwelcome. I think the complaint is that Cocoon 3 is really Butterfly 1. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
cocoon migrate from 2.1 to 2.2 or 3 (was Re: Forms and maps)
The whole thread had changed the subject a long time ago ... On 04/18/2012 03:29 PM, Mark H. Wood wrote: On Wed, Apr 18, 2012 at 11:34:26AM +0200, Derek Hohls wrote: It all depends on your environment and the rate of change. There are many back-end systems (running on old but reliable technology) that hardly change at all. However, the web (and now tablets/mobile) has a very high rate of change (and expectation of change). The point here is that by using more loosely-coupled modules then you will only have to change the parts that really need to be changed; a monolithic approach is less amenable to that. I think this may actually underscore the O.P.'s point. Changing the whole world in one go is the monolithic approach. The modular approach would enable choosing new mechanisms for new work and sticking with old, established mechanisms for existing, still-useful work when that makes sense. Having to throw out piles of satisfactory working code just to use a dependency version that still has the attention of its maintainers is really unwelcome. I think the complaint is that Cocoon 3 is really Butterfly 1. Well, yes and no. If you have experience with c2.x you can do close to the same thing on c3. Most of the pipelines i saw are pure generator - xsl transform - serializer stuff that has not changed a bit. Yes there are some components not yet migrated but we are an open source project and welcome every patch. However the basic idea from the start of 2.1 blocks had been to slim down cocoon. c3 is the consequence of 10 years of slim down. To pin it down on a concrete code example if you wanted a specific component in c2.1 you needed to get hold of an avalon manager, ask the manager to lookup your component (or additional ones to do the final lookup). Every component needed to be configured and registered with the manager. Leaving your 20 lines of code being 90% boilerplate code. In comparison in c3 you do @Autowired @Qualifier(messageSource) ReloadableResourceBundleMessageSource messageSource; To inject your variables and creating a setter you are not forced to even use spring BUT you can still reuse your code. ...and best NO boileplate code, resulting is much cleaner code. I had chosen c3 as base framework for our current project because that allowed me to have pure java devs in my team that never worked with cocoon at all and they were productive since day one (which is not possible in 2.x having made that experience in other projects). Bottom line regarding forms handling html5 + ajax framework + your js + css as view technologies and c3 rest service as form action handler is a beautiful base due to various reasons: - mobile ready (you can even use even generic app generator to create native android, etc. apps without writing a single line of code) - REST services are not bound to c3 - REST services can call or even dynamically create c3 based pipelines. -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: cocoon migrate from 2.1 to 2.2 or 3 (was Re: Forms and maps)
Ouh, I didn't realize what kind of the avalanche of arguments I would start. Maybe this tells that there is something bubbling under. I don't want to hurt anyones feelings. I don't want bad blood. I think there are so many different level persons involved in this, that it will cause some misunderstandings from time time to time. I like Cocoon, I like C2.1, I like C2.2, I like C3 and probably I will like C4. I believe I understand those who are Cocoon developers or somehow else near it. But maybe you who are inside don't understand dudes like me. Robby wrote in his final statement that Just like we all use Java.. I do not use Java. When I first get to know Cocoon, I hadn't have written a single line of Java. Nowadays I have written maybe 50 or 100 lines. Other languages yes, but not Java. I liked Cocoon 2.1 because I could do neat things without knowing a single decent programming language. After then, I have written quite a lot with C#, but not with Java. Still I like Cocoon. I do think that C3 is a clever thing to do. I do. I am hoping that I will get into it some day. But because I do this for living, I can't jump to it right away. C2.1 is the most familiar. Have to start with it. Then maybe C2.2 and finally C3. Or just forget the whole thing. The latter is the way I chose a couple of years ago. But I may have changed my decision. - mika - 18.4.2012 18:07, Thorsten Scherler kirjoitti: The whole thread had changed the subject a long time ago ... On 04/18/2012 03:29 PM, Mark H. Wood wrote: On Wed, Apr 18, 2012 at 11:34:26AM +0200, Derek Hohls wrote: It all depends on your environment and the rate of change. There are many back-end systems (running on old but reliable technology) that hardly change at all. However, the web (and now tablets/mobile) has a very high rate of change (and expectation of change). The point here is that by using more loosely-coupled modules then you will only have to change the parts that really need to be changed; a monolithic approach is less amenable to that. I think this may actually underscore the O.P.'s point. Changing the whole world in one go is the monolithic approach. The modular approach would enable choosing new mechanisms for new work and sticking with old, established mechanisms for existing, still-useful work when that makes sense. Having to throw out piles of satisfactory working code just to use a dependency version that still has the attention of its maintainers is really unwelcome. I think the complaint is that Cocoon 3 is really Butterfly 1. Well, yes and no. If you have experience with c2.x you can do close to the same thing on c3. Most of the pipelines i saw are pure generator - xsl transform - serializer stuff that has not changed a bit. Yes there are some components not yet migrated but we are an open source project and welcome every patch. However the basic idea from the start of 2.1 blocks had been to slim down cocoon. c3 is the consequence of 10 years of slim down. To pin it down on a concrete code example if you wanted a specific component in c2.1 you needed to get hold of an avalon manager, ask the manager to lookup your component (or additional ones to do the final lookup). Every component needed to be configured and registered with the manager. Leaving your 20 lines of code being 90% boilerplate code. In comparison in c3 you do @Autowired @Qualifier(messageSource) ReloadableResourceBundleMessageSource messageSource; To inject your variables and creating a setter you are not forced to even use spring BUT you can still reuse your code. ...and best NO boileplate code, resulting is much cleaner code. I had chosen c3 as base framework for our current project because that allowed me to have pure java devs in my team that never worked with cocoon at all and they were productive since day one (which is not possible in 2.x having made that experience in other projects). Bottom line regarding forms handling html5 + ajax framework + your js + css as view technologies and c3 rest service as form action handler is a beautiful base due to various reasons: - mobile ready (you can even use even generic app generator to create native android, etc. apps without writing a single line of code) - REST services are not bound to c3 - REST services can call or even dynamically create c3 based pipelines. - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Forms and maps
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-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
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 abros...@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-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 - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Forms and maps
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-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
