Simplifying Cocoon GetTogether Amsterdam 2005
•Download as PPT, PDF•
1 like•1,347 views
These slides were for a presentation at the Apache Cocoon GetTogether in 2005. From http://web.archive.org/web/20051221213534/www.cocoongt.org/speakers/andrew.html here is the synopsis: New frameworks such as Ruby on Rails are teaching the old dogs some new tricks. With the maxims of "write less code", "don't repeat yourself" and " convention over configuration", programming has become fun again. What can the Cocoon framework learn from this? Consider the lilies: most Java/XML developers fight with configuration and project building tools, and while they do XML situps, our Rails colleagues utter nice Zen-like 'umms' as their framework gently guesses at their thoughts. This session will point out the ways in which we can learn from our competitors and make life easier for our users. It will also introduce Racoon: all the fun of Rails, on Cocoon.
Recommended
More Related Content
Similar to Simplifying Cocoon GetTogether Amsterdam 2005
Similar to Simplifying Cocoon GetTogether Amsterdam 2005 (20)
More from Andrew Savory
Recently uploaded
Recently uploaded (20)
Simplifying Cocoon GetTogether Amsterdam 2005
- 1. Simplifying Cocoon Cocoon GetTogether, Amsterdam 7th October 2005
- 2. Why?
- 4. Cocoon is a fantastic and powerful application framework but it’s flexibility is it’s downfall: it’s simply too difficult to know where to begin and therefore I will not be using it.
- 5. “ Three great virtues of programming are laziness, impatience, and hubris. Larry Wall ”
- 6. Laziness
- 7. Impatience
- 8. Hubris
- 9. Is it right?
- 10. Running Cocoon
- 11. “ Everything should be made as simple as possible, but not simpler. Albert Einstein ”
- 12. ./build.sh
- 13. BUILD SUCCESSFUL Total time: 12 minutes 26 seconds
- 14. Binary or not?
- 16. ./cocoon.sh
- 17. Easy Install
- 18. Building Cocoon
- 27. Configuration
- 29. “ Out of intense complexities ” intense simplicities emerge. Winston Churchill
- 31. Developing with Cocoon
- 32. Two types of developer
- 33. Ant
- 35. What Rails does right
- 36. “ Simplicity is the ultimate sophistication Leonardo da Vinci ”
- 37. Write less code
- 42. Cool videos
- 43. Starting a Cocoon app
- 47. Databases
- 50. Dynamic forms
- 52. Any questions?
Editor's Notes
- Anecdote: In my experience, two years as a Mac user does crazy things to your brain. You come to wonder why everything isn’t as simple as point-and-click or drag-and-drop, and you develop an impatience for anything that isn’t self-evident and totally obvious to work with. This means that working with Cocoon can sometimes be a challenge! Mostly, Devil’s Advocate here. A chance to get some RTs off my chest in a non-threatening environment (i.e. in front of 120+ people)
- Three great virtues of programming are laziness, impatience, and hubris. -- Larry Wall, http://www.oreilly.com/catalog/opensources/book/larry.html I’m going to apply those virtues to Cocoon.
- (Crop/skip photo? photo of sleeping person) People talk about “XML sit-ups”, sounds like too much hard work. We don’t actively dislike XML like some Rails folk seem to, but it would be nice to give our fingers a rest from typing. Don’t do anything the computer can do for you. Lower the barrier to entry by making as many things as possible as easy as possible.
- (photo of someone looking at watch?) Shortest possible time between download and productivity. People want results NOW, or if possible, YESTERDAY. Flow is good, but it can still take some time to see results when building Cocoon applications (an eternity in comparison to Rails, which we’ll talk about later). Hopefully Torsten is going to help with my impatience in his talk on Rapid Application Development with javaflow and the compiling class loader.
- Overbearing pride or presumption: the ultimate presumption is to tell Cocoon developers that are infinitely better than me that we’re doing it all wrong. I’d like to apologise in advance: sorry :-) I’m not presuming that people aren’t aware of this - these are not new ideas, rather a collection of similar ideas gathered in one place. The presumption is that we can make this happen given the conservative resources at play (time, money). Maybe this talk will help make resources available.
- Before I go any further, I’ll answer a question many of you may be asking - why would we do this? Should a powerful tool like Cocoon be easy to use? Should Cocoon go after the “low hanging fruit” in the web application arena? Why wouldn’t we? If we don’t, we’re one step closer to thermal death. Stefano’s email about Cocoon obsolete.
- Let’s take a look at what you need to do to get up and running with Cocoon: - download the latest distribution from the web site. - build. - run. Poll: how many people have downloaded Cocoon? (RAISE OWN HAND, KEEP HAND RAISED) How many people have successfully built Cocoon? How many people have successfully run Cocoon? How many people thought the process was simple enough?
- Can we make this process simpler? Or is it already as simple as possible?
- (add scrolling build text if possible?) 1700+ lines during build. 12 minutes from clean. Make clear it’s a powerbook. Maybe I need a new machine? What happens if I’m trying to build it in Kuala Lumpur on a 486? (fade to next slide)
- Why aren’t we building easy binaries for people? (PAUSE) Acknowledge that fairly soon people will need to build in order to customise the blocks they are using, but initially - why? Remember, LAZINESS. IMPATIENCE. (Reference thread on binary vs. source only distro, and thread on new M2 build binaries.) Timeline: 2003-03-23: Stefano proposes a source-only distribution (with cleaner build) 2005-09-nn: Proposal to make binaries as part of C2.2 M2 builds
- Eschew verbosity. If most people are doing this, why specify servlet? What’s the most common use-case? Don’t need to make other options unavailable, just pick simple default. (Rails: ./script/server)
- Here’s the HUBRIS. Can we simplify further? I believe so. EASIER RUNNING. Forget the two-step ./build.sh; ./cocoon.sh, refactor mercilessly. Let’s have a new cocoon script. It should: - Check to see if a version is built, if so, runs it. Otherwise, call ./build.sh - Default to most likely option - ‘webapp’. - Be sensibly overridden with additional parameters, or individual scripts still used.
- (pic: jack in a box?) Rails has it ... ish. I reckon we can do better. Here’s my crazy thoughts: - Binary installer for as many platforms as possible (Mac done?) - Should automatically startup/shutdown - Configured through system preference pane?
- Talked a bit about building already, but only as far as getting a copy of Cocoon running. Let’s look more closely at the issues of building a customised copy of Cocoon.
- (Change word to something implying timeliness? Picture of speeding clock?) The move to blocks and refactoring of C2.2 means this section may very quickly become redundant. It may even have happened during the hackathon over the last two days.
- GUI build tool thread crops up from time to time. Replacing blocks.properties and build.properties with a friendlier alternative.
- (fade to second screenshot?) (add screenshot of pronetics builder?) Upayavira’s initial Installer, from DD-MM-YY.
- The Pro-netics version of the build generator.
- RT: we have a perfectly decent web application framework - why not build cocoon from within Cocoon? Bootstrapping issues: ship a minimal war that can run the configuration and build process independent of the main build directory? I have a dream. Why don’t we: - Offer friendly descriptions of high-level functionality (task-based?). - Resolve dependencies in the GUI before building. - Offer advanced options for power users.
- No more XML sit-ups. Where can we streamline configuration? A lot can be done with a smarter Rails-alike framework generator. (More later on that). But how about simplifying what we’ve got? Do we have too complex a set of needs to offer convention? Is it a philosophical, aesthetic, logistic, or political question? Java vs. Ruby; Java is either flexible or bloated Ruby is either agile or unscalable If it’s philosophical, aesthetic, or political then we have a problem. If the question is just logistics, we should do it because we can; simplicity is always a good thing.
- How do we identify the convention? We don’t identify convention, we simplify what we’ve got. Whatever convention emerges out of the practice of simplification, is what is convention at the moment. Let’s talk about one way to simplify configuration. web.xml , cocoon.xconf, sitemap.xmap, ... Let’s use a really good tool I know of to work on the XML for us. Assuming we ship a simple Cocoon webapp for building Cocoon, why not make it do more?
- Screenshot(s): configuring Cocoon webapp with GUI - Selecting sitemap components (need ajax expandable yada; binding to generators in sitemap (which is updated from blocks build)) - Defining pipelines - Configuring database connections: a gui to guide them through (more on this later? create from SQL? Not talking sophisticated OR-mapping at this point, going after CRUD guys here) - ...?
- I believe there are two types of developer: artisans of complexity and simplicity lovers - those that want a framework to show them best-practice and do as much of the work as possible for them - those that expect their application to exceed the limits of the framework, or to have many external dependencies and great complexity. We’ll deal with the first lot later. This is for the second lot.
- This time last year, we were using Ant and patching an installation of Cocoon as we went along. It works, it’s lightweight, it solves many concerns of building Cocoon projects. A template application is available at http://www.luminas.co.uk/gt2005/ Problems: fragile; doesn’t solve the customised Cocoon problem in a terribly elegant way; can’t easily handle lots of external dependencies (ballooning lib directory). Bertrand/Marc approach of copying Cocoon++
- Otego’s Maven Cocoon plug-in: best kept secret? It: - Handles blocks.properties/build.properties for you - Builds Cocoon when needed - Uses maven, so all the benefits of maven - Can generate a self-deployable Cocoon jar file
- We’ve looked at a few areas where Cocoon could do better for the users. By looking at other frameworks we can get more good ideas.
- (fade bottom?) Rails makes it REALLY simple to get up and running with a sample webapp. Without writing many lines of code and minimal effort, you can do basic CreateReadUpdateDelete webapps. These may not be the typical Cocoon webapp, but why couldn’t they be? Through simplifying the framework we may truly achieve sophistication.
- Auto-generate where possible. Default templates, bindings, flowscript, pipelines? Bean generators? Let’s get xdoclet examples out there!
- When I was first thinking about this, the Summer of Code project to add CForms libraries had not begun. Still writing a lot from scratch, would be great to build up library of common cocoon components (at a more abstract/higher level than blocks)
- This is my attempt at solving (or at least studying) some of the problems I’ve outlined. (Racoon in programme, lots of other Racoons)
- Need to talk about how this differs from Bertrand’s proposal: Obviously cocoon has many samples and is starting to have example application available. I wanted to go one step further and provide people with a “best practice” starting point for a Cocoon application. - generates required directories and files from the command-line - provides a servlet container as Cocoon does, but deployed in each of your applications. - Can get running with: ./racoon myapp cd myapp; ./server
- Create sitemaps, cforms and flow on the fly from a database. Generate objects ‘dynamically’ from templates (if not there already)
- What truly sets the Rails community apart is the slick marketing they are doing. Their ‘15 minute blog’ is a prime example. Let’s see if we can do it in Racoon ...
- Getting up and running; being able to see -something- within the first 30s of development (Better than 12 minutes of compilation first!)
- Adding controller
- Dynamic database editing