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" <[email protected]> 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: [email protected] [mailto:[email protected]] > Sent: Wednesday, April 18, 2012 7:58 AM > To: [email protected] > 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 <[email protected]> > 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: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
