Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Monday, January 29, 2007

New Screencast: Tapestry Maven Archetype

I've added a new screencast, this one showing off the use of the tapestry-simple Maven archetype to create a new project. It runs about five minutes and shows off how simple it is to get up and running.

If you haven't built Tapestry 5 locally, you need to remember to add -DremoteRepositories=http://people.apache.org/repo/m2-snapshot-repository/ to the command line.

I'm thinking about starting a vote to do a preview release of Tapestry 5, just to get the necessary JARs and archetypes into the general Maven repository.

14 comments:

Hugo said...

Looking real good.
Is the source code for the archtype available ?
I'd like to use the templates your using in TapIDEA so that when a user creates a project within IDEA he get's a similar template.

Unknown said...

Hugo, come on, of course its available. Just follow the link, as in screencast, and all the details are there (like any other Maven project).

Anonymous said...

Compared to what happens here http://www.oracle.com/technology/products/jdev/viewlets/1013/fusion.html
your presentation is not impressive at all.

Unknown said...

Annonymous:

First, I almost deleted your post because it is imflammatory. Go start your own blog if you want to bash others.

Second, apples and oranges. The screencast is about setting up a Tapestry application, not about building out a full application.

Third, your screencast demonstrates everything wrong with the current mindset: throwing more and more tools and more and more complexity and more and more layers at the problem of building web applications. Tapestry is about simplicity, the fact that you do not need, nor should you require, all that machinery.

Generally, software that demos well is insufficiently capable of meeting real world needs. What's the maintenance of such an application look like? How well do the various artifacts and editors work with source code control and large teams? How do you handle merges and diffs when you're dealing with acres of machine generated XML and Java? How easy is it to change your mind about workflow or the naming of a page? Those are the questions I'm intested in, and Tapestry has very good answers to all questions in that category.

Massimo said...

You already own my vote for the preview.

Anonymous said...

Howard,
I am one of those who bought your book 'Tapestry (3) in Action'. I am one of those who wrote several Tapestry 4 applications without even looking inside the book. I am also one of those who care less and less about what happens to Tapestry 5.
-- Why?
-- Let someone else answer this question.

Regards,
Jacob

Unknown said...

Jacob,

I'm having a hard time understanding the point of your post. Is it good that you were able to write T4 apps without reading Tapestry in Action? Are you saying Tapestry 4 is "good enough" and you don't feel the need to switch? Or are you saying that you don't care what new paths Tapestry 5 takes?

Jesse Kuhnert said...

Maybe a little release would be good. It worked out "ok" for me with 4.1, though guilt starts mounting when you feel like you've done a bait and switch on them. (the switch being "move to snapshots" if you want the fixes )

Either way it'll probably open the door to tons of useful real world feedback, just as long as you're ready for it. ;)

Unknown said...

I'm sick today and moving slow ... but I'm working on my version of a BeanEditor component. I'd like that to be in the first preview release of Tapestry 5. It will probably be the single element that changes the most going forward, but that's OK.

Jesse Kuhnert said...

I'm still slightly slack jawed every once in a while when I think about the ramifications of what you've done here....It's so amenable to change / integration with anything.

Bill Holloway said...

Other problems with Anonymous' bashing post are the highly niched utility of this Oracle monster and the barriers to entry. Not only do you have to have a fairly deep understanding of Oracle and workflow and JSP and all the complexities of the XML configs and the tools, etc., you are also trapped in a particular solution space that is far too complex for the lionshare of webapps.

and you have to able to afford all these things.

Anonymous said...

I'm really looking forward to Tap 5. I started with 3 (read In Action), then 4 (read Enjoying Dev with Tap), and think Tap 5 will really be something that will be a good fit for what I am going to be doing.

I think making Tap smarter, rather than using more tools to create the app is the right direction. I see a lot of value in convention of configuration too, as long as when you do want to configure it's not too painful.

As far as the bashing posts, that;s just odd. Why would someone bother wasting their time bashing free software? Ignore them.

Anonymous said...

I just finished reading the T5-tutorial (as much as has been written) and I thought I'd provide some feedback:

Things I like
- Using a servlet filter rather than a servlet. I think this has great potential. If I am guessing right, this means that Tapestry will only serve up what it should, and other servlets (ie, other frameworks, JSP, etc.) can serve up what they need to. You could in a sense have different approaches running simulateously for different parts of the site. A great idea.
- Threadsafe object usage. I know this isn't exactly new to T5, but this makes web development sooo much easier.
- No type declaration of page properties. It looks like the xhtml page just references the property by name and probably uses some notion of a formatter (customizable I'm sure) based on the object type. Then in the component class, all you have to do is specify a Java bean conforming "get" method name for the property and Tapestry will use it for the property specified in the xhtml file. I think I like that, although something seems dangerous about it.
- Automatic code reloading, including method signature changes. Very nice. Huge win for dev time.
- POJO with annotations. Exacly the right direction. Makes development simpler, allows true domain modelling with ineritance, makes testing easier since no special container must be used.
- Chapter on how to set up a dev environment. I think this helps with adoption. It is no fun to want to try out a new product or framework only to spend a lot of time trying to set the thing up. Obviously people are not forced into using maven and eclipse, but if someone provides an already-set-up environment, I will probably use it. This is also why I like Kent Tong's book so much. He went through how to set up eclipse for tapestry.

Things I didn't like
- Package naming requirements. apparently page classes have to be in *.pages. I suppose this is to prevent the developer from having to declare each page or configure where they are, but couldn't an annotation be put on the class itself? Is the concern that it would just take too long for Tapestry to load and scan through all the objects, looking for the page class, especialy since (I imagine) the page classes are loaded on demand when needed? Seems like there could be another way, although I admit I don't know of one.

I am looking forward to reading more when it comes out. I would venture to say that good documentation or a book on T5 may make all the difference with getting people to understand it and adopt it. All it takes is time and money :)

Unknown said...

John,

Thanks for the review.

I'll probably be updating the tutorial to discuss using Callisto for things (an ongoing experiment). Or maybe not ... using Jetty and JettyLauncher is old hat for me and works quite well.

Requiring specific packages fulfills a number of needs. Firstly, yes locating page and component classes is somewhat expensive, and the class reloading logic has to be limited to particular packages (otherwise you get into all sorts of issues that result in ClassCastExceptions as different loaders load the same classes, differently).

In addition, the idea of telling Tapestry just the name of a package, in web.xml, and letting it figure out everything else from there is very, very compelling.

In fact, it's more than just limiting the amount of configuration a developer must do ... much of Tapestry 5 is also about limiting the number of descisions the developer must make (especially early on). Strong recommendations become necessities and people actually get some relief. I've joined the cult of people influenced by the book "The Paradox of Choice".