This one shows how to use built-in Tapestry components, touches on the exception page, transient and persistent properties, and component event handler methods. Along the way, we see just how great it is to be able to change code on the fly! Tapestry 5 Technology Preview #2 -- 20 Oct 2006
The screencast clocks in at about 9 minutes.
For Tapestry 4 users, the two big things to pay attention to:
- Action handler methods, not listener methods
- Action requests send a client refresh, not updated HTML
The latter one is a big change from Tapestry 4, and implies that more data will have to be persistent between requests; the good news is that client property persistence, as well as flash persistence, will be supported fairly soon.
The constant question is: When will it be done? We'll be getting to the point where the other Tapestry developers can join the fun pretty soon, once I get basic forms and input validation working. I can see a useful platform ready in the spring and a final release, with some form of Spring and Hibernate integration, in the summer. Of course, my schedule is anything but fixed and set (I do have to earn a living around all of this!).
By the way, these screencasts are all done in a single take. What you see, complete with me fumbling with System.out.println, was my third full run through.
Page response is really that fast, even in the face of code changes. I'm not editting out pauses or any tricks like that. It's not just fast due to my dual-core monster desktop either; I've seen just as nice results on my more puny laptop. It's going to be hard to work on any other platform where I actually have to restart or redeploy just to see changes to my code!
26 comments:
Do my eyes deceive me or did I just see you "inferring" event types with your OnEvent annotation? Pretty clever. That could really work out well across the board. Mixing in some form behavior gives more specific defaults..
A select component would annotate itself as having a default of "onchange" / etc..(this could work equally well for dhtml type things). Obviously you are way ahead of me on this but I'm officially "excited" for real tangible reasons now.
Damnit all...Must stop looking at t5..Must stop.
type this instead:
sysout[CTRL+SPACE]
and get
System.out.println() filled in as a code template.
No, no real "inference". ActionLink generates an "action" event that starts on the client side and comes up through the servlet filter (other events may cascade from this, or originate for other purposes). In any case, the event starts in the ActionLink, is not handled there, and propogates up to the Start page; there a handler method is found (matching on component id). Alternately, we could have used @OnEvent("action").
For example, the Form component will fire events before and after processing the form submission. Like everything else so far in T5, firing events is very lightweight (as in, not relying on any reflection, just straight method invocations).
Internally, the Start page had a method, handleComponentEvent(), added to it. The implementation of that method compared the event's componentId to the list specified in the annotation, and decided to call the chose() method.
What's interesting is that the event could have continued to "bubble up", seeking an event handler that returned a non-null value (that would abort the event).
There could be some value in using the name of the method to help filter the events that are handled.
Hi Howard, I have one question: Will there still be the page secification file? I don't think to specify all components' details in the page template as good think. Thanks for an answer.
Hi Howard, does this second screencast mean that there will be no page specification file or not? I'm not a fan of the all components' details in the page template. Thanks
The "other" place for component details (type, parameters, etc.) is the Java class, in the form on the @Component annotation on a private instance field.
In Tapestry 4, the advantage of the XML files was that they could be picked up without a restart, but that's no longer a problem. For Tapestry 5, its much cleared that a component is a Java class with resources that include the template.
See the guide.
Hi Howard
Your two screencasts gives a nice look at how we can expect the development experience to look like for tapestry 5. I am, however, very much interested in getting more details of how you envision other common (as well as difficult) problems being solved in a tapestry 5 application.
I know tapestry 5 is not fully developed, but I think it could help create more attention if you produced some "vision applications", ie java and html files of how you envision a particular type of problem being solved. It would probabbly be faster than doing webcasts, and allow us to get a better feeling for what we can expect from the framework (and thereby giving more ammo to evangelize from =)
Thought you might like a comment from someone that knows nearly nothing of Tapestry but is interested and watched both the screencasts. The first one is great and makes we want to learn more. The second one is filled with object after object of weird tags that I don't have any motivation to learn. I must know 5 of these front-end languages by now. :(:(:( Just thought you might want to add a comment or two expaining what you're using and why a developer would want to learn yet another tag library. Anyways, the screencasts are great.. keep up the good work!
The screencast is good but I have to say that I'm dissapointed.
When I've discovered Tapestry 3, and Tapestry 4, things that catched up my attention is the possibility to make distinct separation between Web Designer and Web Developper : Web designers can work as usual with HTML tag knowing nothing about Tapestry. Web developpers can create code knowing nothing about CSS and HTML.
This is possible with the use of the magical "jwcid" attribute. MVC model is perfect.
My questions are : Why does T5 use special tags like <t:comp> in the HTML template ? It's not really HTML compliant. Must I send my Web designer to a Tapestry formation ?
I think I mentioned in the screencast that Tapestry 4 style "invisible instrumentation" will make a comeback, but there's other things coming in the queue first.
These screencasts are great. I'm really liking seeing the next generation in early development, so I can learn it as it comes along.
Justa wanted you to know they're apprecaited! Thanks, /bd
rattana:
I came to Tapestry as a front-end developer/designer, and am can say from that perspective that learning to deal with "jwcid" attributes on my html prototypes and templates is really no more or less frustrating than working with the technically more XHTML-friendly approach I see here with T5.
Howard's use of a custom namespace is (I believe) the perfect application of eXtenisbleHTML - especially when it's a template being designed, and not a static page.
The MVC pattern is great foundational understanding, and in a perfect world you could get away with your Designers and Developers speaking different languages on different continents... but a far more realistic implementation is one where they _do_ know a bit more about each others efforts. Don't you think?
No autocompletion: that's the main problem with those t:tags in the demo.
Are you sure?
Doesn't your html editor catchup with the namespace definition and prompt you with a hint?
Change the editor :)
Hello,
The new version of Tapestry looks really nice. The features are really interesting.
But one problem i have encountered with Tapestry and i think with nearly all webapps is the ability to open multiple browser windows, user tend to do that even if you tell them not.
Putting page properties persistent means that it will often happen that client browser windows will be out of sync with the server. I am searching a solution for this common problem (I think) to keep properties in a session relatively to a particular flow or conversation. That means when a user clicks a link or submit a form the state of the properties will be pooled in function of the context.
I don't know if i am very clear???
Another point is that sometime you don't want to have a session started on a public website as soon as a new visitor come. You want to defer the creation of the session until he actually register or buy a product etc... I find it hard with Tapestry to avoid session creation. For example if you have a search query for a database with multiple parameter, i have the option to keep the query parameters in the session or to serialize the query parameters in the url to navigate from page 1 to page 2. Keeping it in the session is the simplest way, but it requires that a session starts (something you might not want), putting it in the url makes the url long like hell!! And it is very hard to deal with a datasqueezer to encode multiple parameter easily.
It would be nice to have a convenient way for encoding multiple parameter such as query parameters or complex parameters easily with a datasqueezer (or any other way).
But i love tapestry and thank you so much for developing such a framework. Thanks to tapestry i have been able to develop this website: www.le-voyage.com and all the back office tools. And i hope it will be a success!
GREAT JOB HOWARD!
I must say the client-side redirect upon clicking a link is a disappointing feature. It results in one more unnecessary interaction between browser and server AND more importantly the URL does not convey the link that was clicked (bad for SEO and bookmarking!).
I think the client side redirect is very important because, ultimately, it means that the URL represents the "object" viewed on the page, rather than being a trace of the last activity on the object in the page. This is better for bookmarking, and for preventing unwanted side-effects from hitting the refresh button.
In terms of state management, Tapestry 4 supports persistent page state on the client, this too will be easy to move over to Tapestry 5.
Is that your "normal" Eclipse look? Seems a lot more productive than the standard look :)
I like t5.when will it be released?
and I hope there is a tool like webPilot, which's
viusal development tool.
That's the Java Browsing perspective, as opposed to the normal Java perspective. It's very familiar if you used NeXT ProjectBuilder or Smalltalk and I think more people should use it.
Normally, I run two Eclipse windows; one mostly in the Java Browsing perspective, and one mostly in the Resource perspective. On my desktop, of course, they each get their own monitor.
Okay, a couple of questions.
I remember using Hivemind for storing session scoped objects in T4, and using the Visit object in T3. How will this be handled in T5? I also believe that T5 will be huge if you supply hooks for frameworks such as Spring and Hibernate - is this something you're considering?
And finally, what will the Ajax support be like? Are you leaving that up to Tacos or is there going to be "native" T5 ajax compoents?
Keep up the good work!
Native Ajax support should be built into the final T5, much like 4.1. Application state objects will be re-implemented for T5. Some reasonable form of Spring and Hibernate integration will be available as well (not part of tapestry-core, likely there will be side projects, in apache.org, for tapestry-spring and tapestry-hibernate).
I think the best feature I liked in Tapestry was that I could use dreamweaver for designing pages and using $remove$ and $content$ to test out pages...jwcid was very easy to use with dreamweaver using the attributes panel..Now these new namespaces and etc will not be helpful for this...UI design and preview is a good portion of work in Web Application...I dont see any advantages in this change..
Perhaps a better option would be to allow users to still jwcid or may tap:id type paramters in templates.
My choice of not using jsp or jsf or asp.net was based on the distance between a designer and a programmer in a typical web application. In Tapestry, the programmer didnt have to use his programming skills to design a form or a template.... Otherwise, we will be forced to use jsf+spring..as almost all the IDEs support it.
I love other new features you are planning...
Redirect for action links is great. If you're worried about SEO or bookmarks, use "external" links.
There seems to be a lot of discussion around the html tags versus jwcid. I'm curious, how flexible/interchangeable will the templates be? Personally, I've gotten rather attached to RHTML via rails. It would be great to be able to extend Tapestry 5 (or have it built in) in such a way that JRuby would power RHTML templates for Tapestry.
If you like Rails, write Rails. I am averse to any so-called templating language that works by intermixing code with content. That demonstrates a lack of understanding of components and object-oriented techniques. It's also unmaintainable in the face of real world pressures, such as mixed temas of HTML and Java (or Ruby) developers. It assumes that everyone is equally skilled in everything ... which may be true for small projects but is absolutely not true for most projects.
Post a Comment