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 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 > >
