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 the "> 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-unsubscr...@cocoon.apache.org [8] > >>> For additional commands, e-mail: users-h...@cocoon.apache.org > [9] > >>> > >> > >> > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org [10] > >> For additional commands, e-mail: users-h...@cocoon.apache.org > [11] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org [12] > > For additional commands, e-mail: users-h...@cocoon.apache.org [13] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org [14] > For additional commands, e-mail: users-h...@cocoon.apache.org [15] > > > > Links: > ------ > [1] mailto:robby.pelss...@nxp.com > [2] http://www.snoyman.com/blog/2012/04/xslt-rant.html > [3] mailto:m...@digikartta.net > [4] mailto:m...@digikartta.net > [5] mailto:users@cocoon.apache.org > [6] mailto:abros...@ogs.trieste.it > [7] http://wiki.apache.org/cocoon/CocoonFormsCreatingWidgets > [8] mailto:users-unsubscr...@cocoon.apache.org > [9] mailto:users-h...@cocoon.apache.org > [10] mailto:users-unsubscr...@cocoon.apache.org > [11] mailto:users-h...@cocoon.apache.org > [12] mailto:users-unsubscribe@cocoon> [15] mailto:users-h...@cocoon.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
