Tapestry 4.0 Released

Home

News: Tapestry 4.0 Released

  1. Tapestry 4.0 Released (102 messages)

    After nearly two years of work, the Tapestry development team is proud to announce the next major release of the Tapestry web application framework.

    Tapestry is an open-source framework for creating dynamic, robust, highly scalable web applications in Java. Tapestry complements and builds upon the standard Java Servlet API, and so it works in any servlet container or application server.

    Tapestry divides a web application into a set of pages, each constructed from components. This provides a consistent structure, allowing the Tapestry framework to assume responsibility for key concerns such as URL construction and dispatch, persistent state storage on the client or on the server, user input validation, localization/internationalization, and exception reporting.

    Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with small amounts of Java code using (optional) XML descriptor files. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects -- and specifically not in terms of URLs and query parameters. Tapestry brings true object oriented development to Java web applications.

    Tapestry is specifically designed to make creating new components very easy, as this is a routine approach when building applications. The distribution includes over fifty components, ranging from simple output components all the way up to complex data grids and tree navigators.

    Tapestry is architected to scale from tiny applications all the way up to massive applications consisting of hundreds of individual pages, developed by large, diverse teams. Tapestry easily integrates with any kind of backend, including J2EE, HiveMind and Spring.

    Tapestry 4.0 represents a significant advance over Tapestry 3.0. The following are the most significant changes between the two releases:

        * The new 4.0 specification DTDs have been simplified.

        * The syntax used for binding parameters inside an HTML template and inside an XML specification is now consistent. Both make use of binding prefixes.

        * "Friendly" URLs (that is, URLs that pack more information into the path and less into query parameters) are built in. This makes it easy to divide your application across many folders (reducing clutter), and leverage J2EE declarative security along the way.

        * Listener methods are much easier and more flexible; listener parameters in the URL are automatically mapped to listener method parameters, and listener methods can return the page name or page instance to activate.

        * Component parameters now just work, without having to worry about "direction".

        * Applications can now have a global message catalog, in addition to per-page and per-component message catalogs. Messages not found in the component message catalog are searched for in the application catalog.

        * Full, native support for developing JSR-168 Portlets has been added.

        * Tapestry 4.0 makes much less use of reflection and OGNL than Tapestry 3.0; partly because there are many new binding prefixes and largely because of how parameters are now implemented.

        * HiveMind services and Spring beans can be directly injected into page and component classes.

        * Tapestry 4.0 includes optional JDK 1.5 annotation support (but Tapestry still works with JDK 1.3).

        * Tapestry 4.0 debuts a new and much more sophisticated user input validation subsystem.

        * Line precise error reporting can now display the contents of files containing errors.

        * Forms can now be canceled, bypassing client-side validation logic, and invoking an alternate listener on the server-side.

        * You are no longer limited to just Global and Visit; you can have as many application state objects as you like.

        * The use of HiveMind under the covers means that Tapestry can be easily customized to fit your needs.

        * Page properties can now be persisted on the client, as well as in the session.

        * Components and component parameters can now be marked as deprecated. Component parameters may have aliases (used when renaming a parameter).

        * The examples have been rewritten to take full advantage of Tapestry 4.0 features, including annotations.

    Tapestry is released under the Apache Software Licence 2.0.

    Tapestry is distributed as a combined binary/source distribution, and an additional documentation distribution. Tapestry may be downloaded from the Apache Mirrors.

    P.S. Tapestry (3.0) is the framework used by TheServerSide.com.

    Threaded Messages (102)

  2. Tapestry 4.0 Released[ Go to top ]

    Congratulations to the Tapestry team.

    I have been working on a project where Tapestry 3 is used to provide the web application infrastructure. It has proved to be a very powerful solution but I am glad to see that many of the changes in 4 are designed to reduce complexity.

    The Tacos Tapestry components put Tapestry in the same league as RoR for creating AJAX-enabled applications, but clearly this is only achievable by leveraging the complex and sophisticated environment provided by Tapestry. Will the existing third-party component libraries (like Tacos) continue to work with Tapestry 4?

    I am pleased that Tapestry 4 allows the use of annotations for some of the configuration as I always felt that there was a little too much XML to write with Tapestry 3. Infact I wonder if there were any design compromises made to retain backward compatibility and if so, if they were necessary. I think with the changes introduced in Java (1.)5 it is become fair to target Java 5 as a minimum with new versions of tools and libraries. Seems good enough for EJB 3 anyway.

    It seems that Hivemind is now core to Tapestry. Any technical reason why Hivemind was choosen for IoC in Tapestry over Spring (I know Hivemind is Howard's project too, but other than familiarity)? I would think that many folks using Tapestry are also using Spring and having to use two different IoC containers is a little grating.

    I am sure I will find myself delving into a Tapestry 4 over the new few days. I am definatly looking forward to checking out the changes :o).
  3. HiveMind vs. Spring[ Go to top ]

    HiveMind and Spring are both IoC containers, but they differ substantially in the details. Spring is a very good IoC container, but its main attraction is its integrations with other technologies, such as Hibernate, JDO, JMX, JMS, and so forth. Spring is about building applications, and wiring dependencies inside an XML descriptor (yes, this is an over-simplification).

    HiveMind is more of a framework for building other frameworks, though it can do all the same things as Spring. Unlike Spring, it has built-in namespace support, and fundamentally assumes that the graph of related services will be built from multiple locations (that is, each JAR on the classpath will be packaged with its own XML descriptor). In fact, Tapestry consists of about 200 individual services, each small and well-defined, and HiveMind takes care of instantitating and configuring them in a just-in-time (yet threadsafe) manner.

    Further, HiveMind includes the idea that service implementations may be overridden in a predicatable way. This means that <em>one</em> approach to extending Tapestry is to override the implementations of select services, without changing their interface.

    Lastly, HiveMind has a notion of distributed configuration (that draws on ideas from the Eclipse Plugin API) that are very relevant to Tapestry.

    What's core about IoC is that, because its based on POJOs and maybe interfaces, its easy to work together. With minimal configuration, you can have your services in Spring and inject them into your pages and components (and HiveMind services, if you wish). HiveMind is there if you need it or like it, but plays well with others, including Spring.

    I call it "object soup".

    Summary: HiveMind has specialized features appropriate to building extensible frameworks; it was created specifically to be the infrastructure for Tapestry 4.0, but is still completely general purpose.
  4. HiveMind vs. Spring[ Go to top ]

    Howard,

    Thanks for the comparison, but lately it seems like the POJO aspects of IoC are getting drowned out.

    "one approach to extending Tapestry is to override the implementations of select services, without changing their interface."

    You lost me there. I probably missunderstood but long before Tapestry, HiveMind, Spring or even Java we were able to override implementations without changing their interface. This isn't new or requiring of anything other than an OO language. My initial reaction was to think to myself "so what?".

    It seems that all we're doing here is removing code that uses "new" and replacing with a miriad of IoC containers and their configuration files. It's as if we are moving dust from under one rug and hiding under a new one.

    "What's core about IoC is that, because its based on POJOs and maybe interfaces, its easy to work together. "

    Everything in Java, even the worst of J2EE, is based on POJOs and maybe interfaces.

    Taylor
  5. HiveMind vs. Spring[ Go to top ]

    Let me explain by example.

    If I built Tapestry on top of Spring, to get it to work, you would have to cut-n-paste into your Spring XML file something like 2000 lines of XML that configure the 200 individual services in Spring. Yes -- much handwaving, and Spring has been picking up ideas from HiveMind in terms of breaking up monolithic configurations, but lets move from here.

    That's not too bad ... but it's cut-n-paste. You can make spot modifications to it ... to change the implementation of a service from DefaultFooImpl to MyFooImpl. The problems start with the next release of Tapestry which will have, say, 250 services. Your upgrade path becomes tortured, because you have to figure out what you did to the boilerplate XML and re-modify it to add back in your changes to the NEW boilerplate.

    Because of HiveMind, you can do something like:

    <implementation service-id="tapestry.bar.Foo">
      <create-instance class="MyFooImpl"/>
    </implementation>

    This is a override of the default implementation of service tapestry.bar.Foo; the normal implementation is ignored in favor of this override. This goes into your application-specific HiveMind descriptor and that information is integrated with Tapestry's many descriptors.

    When do you do stuff like this? Well, Tapestry's default behavior for runtime errors is an example. The default behavior is great for developers, but you would never want to provide that much detail to your end users ... it would scare them sh*tless. Instead, you can provide an override of the tapestry.error.RequestExceptionReporter service; providing an implementation that, say, logs the error to the file system and sends the user back to the Home page and displays a simple error message there.

    When talking about IoC and POJOs, especially in terms of using Tapestry with Spring (via HiveMind), the point is that there are no base classes for Spring Beans or HiveMind services; nor are there base interfaces. The Spring and HiveMind APIs are very carefully and selectively exposed. This means that, for example, Spring code can be used as a native HiveMind service just by providing the right HiveMind XML descriptor. Since its just classes, interfaces, and inter-dependencies it doesn't really matter whether the code was written with HiveMind or Spring (or whatever) in mind.

    The advantage of an IoC container from my perspective, is in the extra layer of abstraction, the loose binding that allows us to control, at runtime, exactly which class is instantiated and how it is initialized. There's a razor's edge there, balancing simplicity and extensibility. I think IoC in general, and HiveMind in particular, let's me ride that edge.

    Final IoC note: its more about the interfaces than about the classes. From my perspective, the Java class is just the kernel around which the service is built. The service includes a bunch of other concerns, including late binding (as just discussed) but also lifecycle issues such as just-in-time instantiation and (of course) injection of collaborating services (aka "dependencies"). HiveMind even has some clever features that allow, for example, service implementations to be specific to individual threads (ultimately, a ThreadLocal is involved ... one your code never has to see). The point is, all of that quickly adds up to far, far more than just "new".
  6. upgrade path becomes tortured[ Go to top ]

    Howard,

    These are the things that concern me...

    "Your upgrade path becomes tortured, because you have to figure out what you did to the boilerplate XML and re-modify it to add back in your changes to the NEW boilerplate."

    and...

    "to get it to work, you would have to cut-n-paste into your Spring XML file something like 2000 lines of XML that configure the 200 individual services in Spring"

    No wonder people are so hyped about Ruby, it's the only way to escape the frameworks and their xml files.
  7. upgrade path becomes tortured[ Go to top ]

    Howard,These are the things that concern me..."Your upgrade path becomes tortured, because you have to figure out what you did to the boilerplate XML and re-modify it to add back in your changes to the NEW boilerplate."and..."to get it to work, you would have to cut-n-paste into your Spring XML file something like 2000 lines of XML that configure the 200 individual services in Spring"No wonder people are so hyped about Ruby, it's the only way to escape the frameworks and their xml files.

    This was a comparison to Spring, not to Ruby. Discussing the evolution of HiveMind away from XML is an entirely different discussion. What I was pointing out was that, using HiveMind 1.1, it is possible to selectively override individual service implementations without worrying about anything else, something akin to a "patch", where your applications XML descriptor includes tightly focused overrides of virtually any other service defined by any other HiveMind descriptor. This "patch" is more likely to work in later releases unchanged (i.e., without even a recompile). The entire discussion was hypothetical, starting with "why didn't you use Spring".
  8. upgrade path becomes tortured[ Go to top ]

    Howard,These are the things that concern me..."Your upgrade path becomes tortured, because you have to figure out what you did to the boilerplate XML and re-modify it to add back in your changes to the NEW boilerplate."and..."to get it to work, you would have to cut-n-paste into your Spring XML file something like 2000 lines of XML that configure the 200 individual services in Spring"No wonder people are so hyped about Ruby, it's the only way to escape the frameworks and their xml files.

    Do you actually read posts before replying to them?
  9. HiveMind vs. Spring[ Go to top ]

    Because of HiveMind, you can do something like:<implementation service-id="tapestry.bar.Foo">&nbsp;&nbsp;<create-instance class="MyFooImpl"/></implementation>This is a override of the default implementation of service tapestry.bar.Foo; the normal implementation is ignored in favor of this override. This goes into your application-specific HiveMind descriptor and that information is integrated with Tapestry's many descriptors.

    Howard, it is possible in Spring too. Just read "3.5. Abstract and child bean definitions" in Spring (v1.2.x). It looks like this:

    <code>
    <bean id="inheritedTestBean" abstract="true"
    class="org.springframework.beans.TestBean">
    <property name="name" value="parent"/>
    <property name="age" value="1"/>
    </bean>
    <bean id="inheritsWithDifferentClass" class="org.springframework.beans.DerivedTestBean"
    parent="inheritedTestBean" init-method="initialize">
    <property name="name" value="override"/>
    <!-- age should inherit value of 1 from parent -->
    </bean>
    </code>

    Note the parent attribute.

    And modularizing beans and their xml config is also possible in Spring. Let's say you have a core module. This module is used by other modules and has lots of beans and you want to provide some default bean definitions for the core beans which will be used/overriden/extended by the other modules. Just package all the beans and the corresponding context xml file in core.jar, and the other modules just use the parent attribute to override/extend it. You only have to list this context xml file in the contextConfigLocation parameter in the web.xml file. That's it!

    Btw, I don't understand this mine vs yours attitude of many open source developers. If, hypotethically, Spring doesn't support what you want, why don't you contribute to Spring instead of inventing something new?

    Ara.
  10. HiveMind vs. Spring[ Go to top ]

    This is not the same thing. For the spring example, you still have to recode your application to use "inheritsWithDifferentClass" bean. The HiveMind implementation mechanism allows a declarative replacement of functionality with no code changes required. It literally means replacing the bean (or service in HiveMind speak) with id "tapestry.bar.Foo" with a new implementation.

    Richard.
  11. HiveMind vs. Spring[ Go to top ]

    This is not the same thing. For the spring example, you still have to recode your application to use "inheritsWithDifferentClass" bean. The HiveMind implementation mechanism allows a declarative replacement of functionality with no code changes required. It literally means replacing the bean (or service in HiveMind speak) with id "tapestry.bar.Foo" with a new implementation.Richard.

    AFAIK Spring doesn't complain that two beans with the same name (let's say bean name="securityManager") are defined in two context xml files. It returns "the last" bean definition from the set of context xml files. So to "replace" a securityManager with another securityManager, I only have to define it again in my module.

    So let's say the core module has a securityManager bean defined there. Now in my othermodule I want to replace it with a different bean but with the same name, so that the other parts of core that depend on a bean with that name use my replaced bean. I don't have to do any magic. I just add coreContext.xml before othermoduleContext.xml in the configLocationParam's list of xml files and in othermoduleContext.xml I define securityManager with exactly the same name again but differently. Ok?

    Ara.
  12. HiveMind vs. Spring[ Go to top ]

    This is not the same thing. For the spring example, you still have to recode your application to use "inheritsWithDifferentClass" bean. The HiveMind implementation mechanism allows a declarative replacement of functionality with no code changes required. It literally means replacing the bean (or service in HiveMind speak) with id "tapestry.bar.Foo" with a new implementation.Richard.

    Not necessarily. I wouldn't consider changing a beanId a "recode". I can change quite a bit of my apps without changing in code. If you, for example, use the XmlBeanFactory and hardcode a beanid string, yes you would have to change the code. 99% of my beanids are only specified in the XML files and are quite declarative. The remaining 1% are localized to our "framework" code and not something that day to day development would change.
  13. HiveMind vs. Spring[ Go to top ]

    Btw, I don't understand this mine vs yours attitude of many open source developers. If, hypotethically, Spring doesn't support what you want, why don't you contribute to Spring instead of inventing something new?Ara.

    Ara,

    So, I need to embrace and extend Spring? Although you can do most of the things in Spring that you can do in Tapestry, there are many things (related to configuration data) that you can not. Further, many of the the things that are important to me are streamlined (in terms of code and/or XML) in HiveMind and are quite verbose in Spring. And I don't build anything complex without line precise exception reporting.

    From a development point of view, the process of engaging with the Spring community, gaining commit privs, etc., would be a long process. The reality is that even today, only Rod and Aslak (sp?) regularily make changes to the Spring core, so for a relative unknown (me, in 2003) to show up demanding to make disruptive changes to the core is unlikely.

    In talking with Rod at several symposiums, he never shared your opinion, that HiveMind is disruptive to Spring or the IoC community. In fact, Rod is all in favor of alternatives to Spring that are compatible with Spring ... and the fact that compatibility (based on simple interfaces and POJOs) is so easy is one of the tenets of lightweight container development.

    Perhaps the most important thing about HiveMind in Tapestry is that you can ignore it entirely and continue to use Spring, with a few lines of boilerplate XML to hook Spring in. Using annotations:

    @InjectObject("service:app.MyHiveMindService")
    public abstract MyHiveMindService getService();

    @InjectObject("spring:mySpringBean")
    public abstract MySpringBean getBean();

    It was an express design goal that injecting Spring beans would be as easy as injected HiveMind services. Because of Spring's flat naming, it's even less typing!

    I think HiveMind has contributed to Spring in the same way that Tapestry has contributed to JSF.
  14. HiveMind vs. Spring[ Go to top ]

    Although you can do most of the things in Spring that you can do in Tapestry, there are many things (related to configuration data) that you can not. Further, many of the the things that are important to me are streamlined (in terms of code and/or XML) in HiveMind and are quite verbose in Spring. [...] In talking with Rod at several symposiums, he never shared your opinion, that HiveMind is disruptive to Spring or the IoC community. In fact, Rod is all in favor of alternatives to Spring that are compatible with Spring ... and the fact that compatibility (based on simple interfaces and POJOs) is so easy is one of the tenets of lightweight container development.

    Well, I just wanted to know what were your reasons for writing an IOC container from scratch. You listed some items that you said you thought were not possible in Spring and at least imho they are possible and quite easy to do in Spring.

    I'm in favor of alternatives too, competition is good. But even better is strong converged products which are widely used :)

    What I like in Rod is his "harmonic" way of thinking. Perhaps it's because of his background in music. I feel what he wants in his professional life, is too have harmony around him :) Smooth competition... products and frameworks that work smoothly with each other... and so on. We need more Rods in this profession!

    Ara.
  15. HiveMind vs. Spring[ Go to top ]

    This is not the right forum for me to show you things I do using HiveMind that I believe are not possible with Spring.
  16. HiveMind vs. Spring[ Go to top ]

    This is not the right forum for me to show you things I do using HiveMind that I believe are not possible with Spring.

    Where is the discussion going, then?
  17. HiveMind vs. Spring[ Go to top ]

    This is not the right forum for me to show you things I do using HiveMind that I believe are not possible with Spring.

    Ok I'm looking forward to reading about it on your weblog :) I just want to see what are your proofs for believing "we are the best!" ;-) I've used Tapestry before, and it's great. Keep up the good work!

    Ara.
  18. Re: Tapestry 4.0 Released[ Go to top ]

    The Tacos Tapestry components put Tapestry in the same league as RoR for creating AJAX-enabled applications, but clearly this is only achievable by leveraging the complex and sophisticated environment provided by Tapestry. Will the existing third-party component libraries (like Tacos) continue to work with Tapestry 4?

    Jesse Kuhnert, one of the main Tacos devs, joined the Tapestry team in November. I assume he'll be integrating AJAX goodness into the core component library at some point (though not necessarily in time for 4.1, as per the roadmap).
  19. it will be in time for 4.1[ Go to top ]

    Sorry about the roadmap wording, but everything I added into the roadmap was definitely for ajax integration. It ~will~ be in tapestry 4.1 .
  20. Re: It will be in time for 4.1[ Go to top ]

    Sorry about the roadmap wording, but everything I added into the roadmap was definitely for ajax integration. It ~will~ be in tapestry 4.1 .

    Nice. Thanks for clearing that up!
  21. this is awesome[ Go to top ]

    I moved up from Tapestry 3 to Tapestry 4 not too long ago and I like Tapestry 4 much better. I like that HiveMind is integrated in.

    I like the concept of Application State Objects that can be bound to the current execution thread, or the application, or whatever. And I really like how I can use java annotations (or the page descriptor) to inject objects or services right into the page without needing any other code.

    It did take me some time to get how Tapestry did things, to really think of a page as an object. I burned through Howard's book "Tapestry in Action" and also "Enjoying Web Development with Tapestry" and now I feel like I get it.

    Once I got all the frameworks integrated well (hibernate, spring, acegi, tapestry, hivemind, etc.) my web applications are just solid. I finally started doing test driven development too.

    Kudos to the Tapestry development team.
  22. That was/is the goal of the next release of tapestry (from my contributions at least), http://wiki.apache.org/jakarta-tapestry/Tapestry41Roadmap.

    The roadmap may be a little misleading in that it doesn't specifically say anything about it, but that is my intention. The framework is definitely ripe and ready to provide some unbelievably cool ajax behaviours not seen in typical implementations, all of which I ~hope~ to get added to the 4.1 release of tapestry. It will be a fun few months :)
  23. Great Work[ Go to top ]

    Congrats to the Tap team on this release.
    I began my java experience 3 years ago with regular servlet/jsp home grown framework. From there learned Struts, which cleaned up my code significantly. Then on to Tapestry 3 after trying out a bunch of different web frameworks. Tap3 ended up being more of a learning curve than I originaly thought but with the help of Tapestry's great mailing list and community I was able to get almost all the answers I needed. Which by the way I continue to use and gain knowledge from today. Since converting to tap4 j2ee programming gets easier by the day. The reuse of components, and great line by line error reporting makes this the best framework that I've used.

    Congrats again and keep up the good work.
  24. Tapestry 4.0 Released[ Go to top ]

    Congrats Howard

    Been impressive to see how quick you were to introduce the JSR 168 support in Tapestry!

    Long live to that new version...
  25. Tapestry 4.0 Released[ Go to top ]

    Didn't expect to see this go live until Monday morning. Hope it doesn't get buried.
  26. Why Tapestry?[ Go to top ]

    I plan to learn a component based java web framework. Why would I choose Tapestry over JSF (or others...)?

    10x in advance and congratulations to the Tapestry team!
  27. Why Tapestry?[ Go to top ]

    I plan to learn a component based java web framework. Why would I choose Tapestry over JSF (or others...)?10x in advance and congratulations to the Tapestry team!

    Depends on what you are looking to do! If you are going to be looking for a job or your current job requires maintenance of older J2EE system , JSF is the way to go.

    If you are an architect starting out on a new project, go with Tapestry.
  28. Why Tapestry?[ Go to top ]

    If you are going to be looking for a job or your current job requires maintenance of older J2EE system , JSF is the way to go.

    Why? Tapestry and JSF are both good frameworks, and both are under active development. Why should JSF have any disadvantage for new projects - or any advantage for maintenance of older systems? There are many valid ways to compare the two frameworks, but this isn't one of them.
  29. Re: Why Tapestry?[ Go to top ]

    If you are going to be looking for a job or your current job requires maintenance of older J2EE system , JSF is the way to go.
    Why?

    I think BM's basic premise is that Tapestry is superior in most respects to JSF, but JSF is a standard. Makes sense to me.
  30. Re: Why Tapestry?[ Go to top ]

    If you are going to be looking for a job or your current job requires maintenance of older J2EE system , JSF is the way to go.
    Why?
    I think BM's basic premise is that Tapestry is superior in most respects to JSF, but JSF is a standard. Makes sense to me.

    Both are good frameworks. They have different advantages. One of the reasons I prefer JSF is because of the ability to use different renderkits. That may not be of use to some people, in which case Tapestry may well be the better solution. It is good to have choice - particularly when one of the choices is of the quality of Tapestry.

    I am sorry, but it seems to me that to come up with phrases like 'superior in most respects' without backing that up with reasoned arguments sounds more like flamebait than debate. And, this still shows relevance whatsoever as to why one or other should be better for new projects or maintenance, which seems to me to be a clumsy attempt to tarnish JSF with the 'legacy' label.

    However, this is probably not the place for such a discussion - it is more appropriate here to be grateful that quality Java web frameworks like Tapestry continue to progress.
  31. Re: Why Tapestry?[ Go to top ]

    Howard has a few blogs on this topic:

    http://howardlewisship.com/blog/2005/02/tapestry-jsf-and-fud.html
    http://howardlewisship.com/blog/2004/06/more-on-tapestry-and-jsf.html

    -James
  32. Why Tapestry? Try Wicket![ Go to top ]

    I plan to learn a component based java web framework. Why would I choose Tapestry over JSF (or others...)?10x in advance and congratulations to the Tapestry team!

    And while here don't forget to check out Wicket. Wicket is actually Tapestry on Rails! So powerful!

    J
  33. Why Tapestry? Try Wicket![ Go to top ]

    I plan to learn a component based java web framework. Why would I choose Tapestry over JSF (or others...)?10x in advance and congratulations to the Tapestry team!
    And while here don't forget to check out Wicket. Wicket is actually Tapestry on Rails! So powerful!J
    Wicket is very nice, but is not Tapestry on Rails. It doesn't include scaffolding, meta-programming, integrated databse access or any of the other things that make Rails what is is ... especially the Ruby language itself.

    Wicket is an interesting refactoring of Tapestry that has a small, very vocal community built around it. However, if I was to fork the Tapestry community and create a new code base from scratch, you can guarantee that what I came up with would not be as unambitous as Wicket!

    Instead, I/we are tasked with something far more difficult; which is reaching that ambitous refactoring of Tapestry in increments, one release at a time, while maintaining some semblance of backwards compatibility.

    In the meantime, Tapestry has become a fertile ground for integration, not just with Spring but with complex extensions and add-ons (which makes sense, it was expressly designed to support such things). A great suite of Ajax-enabled components is available from http://tacos.sf.net , and a Rails-like RAD environment from https://trails.dev.java.net . In fact, there is a rabidly expanding number of such projects, more than I can keep up with.

    P.S. Maybe four years ago, I had the awful habit of jumping on other project's release notices as you have today. As I gained confidence in Tapestry, I grew out of it (prompted by a few polite complaints such as this).
  34. Why Tapestry? Try Wicket![ Go to top ]

    Wicket is an interesting refactoring of Tapestry that has a small, very vocal community built around it.

    That's a very funny joke, Howard!
  35. Speaking of using Spring with Tapestry has anybody here found a proper way to use hibernate lazy loading done through spring's dao support in Tapestry pages ?
  36. Hibernate + Spring + Tapestry[ Go to top ]

    Cosmin asked:
    Speaking of using Spring with Tapestry has anybody here found a proper way to use hibernate lazy loading done through spring's dao support in Tapestry pages ?

    The trick is to open a database session and park it in a ThreadLocal when the request arrives, then clear it out when the request/response cycle is done. In Tapestry 3, I did this by overriding the engine and intercepting the start and end of request processing.

    From there, Spring DAOs, lazy loading, etc. all work as they should. One catch is if you want to carry the objects across from one DB session to another; if you want to do this, you have to make sure you associate them with the new session, which you could do in the engine. For our application (large and with multiple concurrent users), we're only carrying object IDs around in the visit and re-read them from the database as needed.

    If you need more detail, please come over and ask on the Tapestry mailing list. :)
  37. Speaking of using Spring with Tapestry has anybody here found a proper way to use hibernate lazy loading done through spring's dao support in Tapestry pages ?

    We don't use Spring, only Tapestry 3.x + Hibernate 3.1

    We use servlet filter from Open Session in View pattern http://hibernate.org/43.html and generic DAO pattern http://hibernate.org/328.html, which makes DB layer as compact as it can possibly be even without Spring.
  38. words of wisdom :)[ Go to top ]

    Wicket is very nice, but is not Tapestry on Rails. It doesn't include scaffolding, meta-programming, integrated databse access or any of the other things that make Rails what is is ... especially the Ruby language itself.Wicket is an interesting refactoring of Tapestry that has a small, very vocal community built around it. However, if I was to fork the Tapestry community and create a new code base from scratch, you can guarantee that what I came up with would not be as unambitous as Wicket!

    Sorry for replying, not trying to start any flam wars...Just that I was reading the original post with one of my friends who is/has done a lot of ror contributions who was declaring that a very large beating of some sort was in order until we saw your reply. ;)
  39. Why Tapestry? Try Wicket![ Go to top ]

    Wicket is an interesting refactoring of Tapestry that has a small, very vocal community built around it.

    I used Tapestry 3.0 in a small project years ago, but now I choose developing with Wicket. IMHO, two frameworks are *completely* different. The only similar part is both choosing plain html as template (but still with quite different approach), and that's all. There is no dependency between these two projects. Things/Ideals/Concepts you learn from Tapestry can not apply to Wicket and vice versa.
  40. Why Tapestry? Try Wicket![ Go to top ]

    Wicket is an interesting refactoring of Tapestry that has a small, very vocal community built around it. However, if I was to fork the Tapestry community and create a new code base from scratch, you can guarantee that what I came up with would not be as unambitous as Wicket!

    This I call ego magnification!

    J
  41. Finally! Awesome!![ Go to top ]

    Howard! Tapestry Team!

    I'm very proud of you! Congratulations!

    I've been using Tapestry 3 in a production environment and just love it. Ive only started using pre-releases of Tapestry 4 recently but am very impressed. Honestly, I came up doing JSP/Servlets or PHP and and I always cringed at my situation. Surely there's something better in Java? If JSP/Servlets were just a java language CGI script then why would anyone submit to it on purpose? Where was the elegance? The true technical superiority? I tried Struts, which, while a step in the right direction, didn't offer much more in the way of power than any canned CMS would.

    Anyway, I shall stop my rant -- but needless to say I'm a huge fan. Congratulations to the team and thanks for the hard work.

    Joshua
  42. Tapestry 4.0 Released[ Go to top ]

    Congratulations!
    Just a few words to add that this release also brings a much better documentation.
    By the way, nice article here : http://www-128.ibm.com/developerworks/java/library/j-tapestry1/
  43. Tapestry 4.0 Released[ Go to top ]

    Congratulations. Tapestry is an excellent presentation framework.

    Kent Tong has published a book on Tapestry 4 at http://www.agileskills2.org/EWDT/. I believe this book could dispell the idea that Tapestry has a steep learning curve.

    Check out the free chapters for yourself.
  44. Tapestry 4.0 Released[ Go to top ]

    Howard, thanks for the clearest explanation yet of the differentiators between Spring and Hivemind. There are a lot of third-party frameworks out there that could benefit from the use of Hivemind injection.

    I am really struck between the difference between the persistence framework space and the web framework space. On the surface, it seems that the requirements for persistence are roughly as complex and diverse as the needs of a web framework.

    Yet, the major persistence providers ( Hibernate, TopLink, EJB, JDO ) have basically converged around a JSR persistence spec that is good enough for most use cases.

    Meanwhile, the web framework space continues to explode in the opposite direction. Tapestry, JSF, and Echo all bring very different approaches to component-oriented development. With the release of Spring 2.0, it appears that Spring MVC will finally become a usable product (in my opinion).

    And just for fun, next year there will be no fewer than three products under the Struts brand. Struts 1.x will continue its current development. Webwork is basically being rebranded as Struts 2.0. And Struts Shale will be an entirely different animal. Does it strengthen the Struts brand if nobody knows what you mean when you say Struts anymore?

    A lot of Java developers are so frustrated that they look outside the Java language for a solution that meets their needs. And even in such a crowded space, brand new frameworks still arrive on the scene that seem to be much better than what has come before.

    I'm not bemoaning a choice in web frameworks. But it distresses me that each year we seem to be further and further from discovering a product or set of concepts that can even displace Struts 1.x as the dominant framework.
  45. Humans are more complex than DBs![ Go to top ]

    Howard, thanks for the clearest explanation yet of the differentiators between Spring and Hivemind
    +1
    ... the major persistence providers ( Hibernate, TopLink, EJB, JDO ) have basically converged around a JSR persistence spec that is good enough for most use cases.Meanwhile, the web framework space continues to explode in the opposite direction.

    I think this is because web frameworks exist to support the use cases of interfacing with human users with all their complexities and foibles, whereas interfacing with a DB has far less variability. And by "user" I don't just mean the end user. There is the developer, CTO, sales director, sysadmin, all of whom seem to want a say in what the framework should be capable of.

    Talk about beating your head against a brick wall ...!

    Kit
  46. Tapestry 4.0 Released[ Go to top ]

    Howard, thanks for the clearest explanation yet of the differentiators between Spring and Hivemind. There are a lot of third-party frameworks out there that could benefit from the use of Hivemind injection.I am really struck between the difference between the persistence framework space and the web framework space. On the surface, it seems that the requirements for persistence are roughly as complex and diverse as the needs of a web framework.Yet, the major persistence providers ( Hibernate, TopLink, EJB, JDO ) have basically converged around a JSR persistence spec that is good enough for most use cases.Meanwhile, the web framework space continues to explode in the opposite direction.

    Corby,

    I wouldn't agree that all persistence solutions have converged around the persistence JSR, there are other popular solutions like iBatis available too. This example draws a good example of what you are seeing with web frameworks too. Here you have iBatis, a lightweight, possibly stateless, persistence framework and then you have full ORM solutions like EJB/Hibernate. With Web Frameworks, the same difference exists-- you have the lightweight request-based frameworks like Struts or WebWork, then you have the stateful component frameworks like Tapestry. The two types will 'always' exist in the market.

    I really wish Howard would join the next JSF EG though ;-)

    Please?

    -- Jacob
  47. HLS on JSF EG[ Go to top ]

    I think very few of the people on the EG are independent software consultants like myself. With the need to extend the framework, do Tapestry projects, train and mentor Tapestry (including creating new labs), keep abrest of Tapestry developments (Tacos, Trails, KickStart, etc.), write a book on 4.0, and otherwise earn a living ... well its about priorities. I suspect most of the people on the EG have a salaried position or are otherwise underwritten by a larger organization (such as Sun, IBM, BEA, JBoss, etc.).
  48. Congratulations[ Go to top ]

    Congratulations to the Tapestry development team.

    I would like to know if there are any users of Tapestry 4.0 developing portals applications using Tapestry JSR-168 portlets within BEA WebLogic Portal 8.x. Any chance of TSS rewriting the site using Tapestry 4.0 using portlets running on top of BEA WebLogic 9.2?
  49. Tapestry 4.0 Released[ Go to top ]

    A lot is happening in the Tapestry world all at once.

    A new article on Tapestry has appeared on DeveloperWorks: n tune with Tapestry. It's written by Brett McLaughlin, and part 1 covers installing and building Tapestry, and running the demos.

    In addition, there's a link on Slashdot to that article, with a typical mad jumble of a discussion attached.
  50. Tapestry 4.0 Released[ Go to top ]

    A lot is happening in the Tapestry world all at once.A new article on Tapestry has appeared on DeveloperWorks: n tune with Tapestry.
    Considering the emblem, "In tunnel with Tapestry" seems more appropriate ;-)
  51. Tapestry 4.0 Released[ Go to top ]

    A lot is happening in the Tapestry world all at once.A new article on Tapestry has appeared on DeveloperWorks: In tune with Tapestry.
    Considering the emblem, "In tunnel with Tapestry" seems more appropriate ;-)

    I couldn't figure out what that image was. Seemed nice and abstract, like the old apress book covers.
  52. Tapestry 4.0 Released[ Go to top ]

    A lot is happening in the Tapestry world all at once.A new article on Tapestry has appeared on DeveloperWorks: In tune with Tapestry.
    Considering the emblem, "In tunnel with Tapestry" seems more appropriate ;-)
    I couldn't figure out what that image was. Seemed nice and abstract, like the old apress book covers.
    Very much like Swedish Tunelbana sans yellow color.
  53. Tapestry 4.0 Released[ Go to top ]

    Howard, Tapestry team, congratulations!

    I know I'm not the only one who is very happy with 4.0 finally being out. It took its time, yes, but the result is very much worth it in my opinion.

    For instance, I love the way HiveMind is integrated in 4.0. Overwriting services - or intercepting them for that matter - is a simple, yet powerful way to modify the framework's behaviour to suit your needs.

    I'm looking forward to seeing Tapestry evolve even more in the future.
  54. Tapestry 4.0 Released[ Go to top ]

    Congratulations to the Tapestry team!!
    This 4 release is quite a milestone.
    Our website (www.actualis.com) is 100% tapestry (version 3 and we are current migrating to version 4) and we very happy on the results. Our load is constantly increasing and the app is constantly evolving. Our previous website was based on php and with all the evolutions it ended up as spaghetti code...
    What we really like about tapestry:
    - complete separation from layout/code, our webdesigner can edit the pages (and components!) in dreamweaver as much as he likes even after we integrated all the tapestry tags
    - separation from code/navigation: you don't hardcode any link and URLS are fully managed by tapestry
    - componentization: this is not the natural way to write html apps but it allows to create fully modular html applications. We ended up having lots of components, and simple pages. You can hide the complex technical parts in components and keep the page/navigation code short and clean
    - javascript: Howard got this concept right, javascript can be attached to components, so you don't need to manage javascript manually, just plug a component that provides the js features
    - forms: validation and form management are incredible
    - speed: tapestry is very fast, the framework has a low overhead
    - high level code: ognl + hibernate are killers
    - stability: the quality of tapestry code is top notch

    Henri Dupre
    www.actualis.com
  55. More Kudos[ Go to top ]

    Hey Howard, et al.

    Congrats on the new release. Although I've only worked w/ Tap3 so far, I have to say it brought a huge breath of fresh air to my development experience. I had just completed about 95% of a struts based project before we started another (similar) project, which I was lucky enough to pick tapestry to work with.

    I heard great things about the framework but so many people always said there was a 'large learning curve' ... I didn't find it as such, it all kind of gelled with my style. It was fun to learn how to use, and offered a quicker development pace than struts did for me.

    Just my personal experience, hopefully I'll be starting up on another (largish) project within the next 2 months or so and I look forward to using Tap 4.

    Thanks again!
    -steve
  56. Hi,
    just tire kicking, but has anyone dropped JSF in favor of other frameworks like Tapestry/WebWorks/etc.?

    JSF is alright,but some of the nuances of it are beginning to get annoying and make me wonder if there are more solid/straightforward frameworks out there.

    JSF works alright when coupled with using session objects,but trying to go stateless as much possible is a lot of extra overhead, especially w/ manipulating the jsf lifecycle calls to make sure the view compoonents are using the correct updated model rather than only random parts of it....
  57. Hi,just tire kicking, but has anyone dropped JSF in favor of other frameworks like Tapestry/WebWorks/etc.?JSF is alright,but some of the nuances of it are beginning to get annoying and make me wonder if there are more solid/straightforward frameworks out there.JSF works alright when coupled with using session objects,but trying to go stateless as much possible is a lot of extra overhead, especially w/ manipulating the jsf lifecycle calls to make sure the view compoonents are using the correct updated model rather than only random parts of it....

    Isn't it what the UI component transient property is intended for? Or maybe I just don't understand what you mean.
  58. JSF is not dropped[ Go to top ]

    JSF benefits from good architecture, but suffers from
    bad implementation (and design also) of some it's components (especially html visual component).
    I read jsf1.2 spec several times and I'm sure that jsf can do all styles of development found in Tapestry or Wicket. Change behaviour of JSF is easier and more transparent than Tapestry with dozens of one(-two) method IIntefaces and hivemind xml bloat (althought that interfaces and abstract classes in JSF are pretty coarse-grained).
    So I abandoned Tapestry in favour of JSF. But I don't use vanilla JSF, I use many extensions (like Facelets instead of JSP, or home-grown ajax components library instead of horrible Html components or even worse MyFaces' extras).
    Out-of-the-box Tapesty is more solid then out-of-the-box JSF.
    But I stay with JSF.
  59. JSF is not dropped[ Go to top ]

    JSF benefits from good architecture, but suffers from
    bad implementation (and design also) of some it's components (especially html visual component).
    Out-of-the-box Tapesty is more solid then out-of-the-box JSF.But I stay with JSF.

    There is no single 'out-of-the-box' JSF. I know of at least three implementations - the RI, MyFaces and Oracle ADF. Problems with components in one implementation may not be there in another, perhaps? I had significant problems with Sun's initial release of the RI.
  60. JSF is not dropped[ Go to top ]

    JSF benefits from good architecture, but suffers frombad implementation (and design also) of some it's components (especially html visual component).I read jsf1.2 spec several times and I'm sure that jsf can do all styles of development found in Tapestry or Wicket. Change behaviour of JSF is easier and more transparent than Tapestry with dozens of one(-two) method IIntefaces and hivemind xml bloat (althought that interfaces and abstract classes in JSF are pretty coarse-grained).So I abandoned Tapestry in favour of JSF. But I don't use vanilla JSF, I use many extensions (like Facelets instead of JSP, or home-grown ajax components library instead of horrible Html components or even worse MyFaces' extras).Out-of-the-box Tapesty is more solid then out-of-the-box JSF.But I stay with JSF.
    And you can always developp a new renderer and not a whole new component. That's what we do with Tomahawk components.
  61. Tapestry 4.0 Released[ Go to top ]

    Well done work!
  62. Howard. Im just started reading your book "Tapestry In Action", im in chapter 4 right now. Are there too many variations in version 4 compared with 3 (which the book explains) ?? Id like to finish the book first and then begin with version 4 (i read its fantastic).
  63. Tapestry 4.0 Released[ Go to top ]

    Yay! Tapestry rocks.
  64. Tapestry 4.0 Released[ Go to top ]

    Tap4 rocks! The errors reporting is unreal. To answer someones question earlier we moved from JSF to Tapestry. In all fairness, it was earlier release of JSF. Our main motivation was the strict seperation of html and java that tapestry provides. Our ui designers (limited to html/css/javascript) couldn't tolerate editing JSF pages manually and most of the rad tools for JSF at the time were clumsy at best.
  65. Tapestry 4.0 Released[ Go to top ]

    Our ui designers (limited to html/css/javascript) couldn't tolerate editing JSF pages manually and most of the rad tools for JSF at the time were clumsy at best.

    I am interested in this point, as it is commonly mentioned, but I simply don't understand it: Why couldn't they tolerate editing JSF pages manually? It is simply using JSP taglibs to construct a page. Surely if they could handle the complexities of CSS and Javascript, then they should be able to handle a few tags? I realise that if this is a problem, then Tapestry has a real advantage here. I apologise if this seems a silly question. I'm simply trying to find out what the problem is, as I want to make sure I understand what the relative benefits of these web frameworks are.
  66. Tapestry 4.0 Released[ Go to top ]

    Our ui designers (limited to html/css/javascript) couldn't tolerate editing JSF pages manually and most of the rad tools for JSF at the time were clumsy at best.
    I am interested in this point, as it is commonly mentioned, but I simply don't understand it: Why couldn't they tolerate editing JSF pages manually? It is simply using JSP taglibs to construct a page. Surely if they could handle the complexities of CSS and Javascript, then they should be able to handle a few tags? I realise that if this is a problem, then Tapestry has a real advantage here. I apologise if this seems a silly question. I'm simply trying to find out what the problem is, as I want to make sure I understand what the relative benefits of these web frameworks are.

    Well, I would imagine the main issue is my main issue with JSP pages, the rendering. You cannot see the page on any level without rendering the tags. My understanding of Tapestry was that you could see the page in any standard tool because said tool would ignore the Tapestry tags.
  67. Tapestry 4.0 Released[ Go to top ]

    Well, I would imagine the main issue is my main issue with JSP pages, the rendering. You cannot see the page on any level without rendering the tags. My understanding of Tapestry was that you could see the page in any standard tool because said tool would ignore the Tapestry tags.

    I still don't see this as that much of an issue. After all, how much effort does it take to edit a live JSP page in a decent editor and re-load to see the consequences of an edit?

    However, I see what you are saying.
  68. Tapestry 4.0 Released[ Go to top ]

    Well, I would imagine the main issue is my main issue with JSP pages, the rendering. You cannot see the page on any level without rendering the tags. My understanding of Tapestry was that you could see the page in any standard tool because said tool would ignore the Tapestry tags.
    I still don't see this as that much of an issue. After all, how much effort does it take to edit a live JSP page in a decent editor and re-load to see the consequences of an edit?
    Exactly. JSP-based application does not need xml config files, even web.xml file. Just drop the JSP file and reload your browser. This "Tapestry lets mee see page without running servlet/JSP container" refrain works only for simple pages with scalar properties. What if you want to show a list or a tree or to show/hide a subview depending on a condition? Plain HTML won't help in this case, and HTML authoring tools do not understand OGNL. I agree that creating page mockups is simpler with Tapestry, but different page subviews still have to be simulated by commenting out certain sections on a page. Am I wrong here?
  69. Tapestry 4.0 Released[ Go to top ]

    Well, I would imagine the main issue is my main issue with JSP pages, the rendering. You cannot see the page on any level without rendering the tags. My understanding of Tapestry was that you could see the page in any standard tool because said tool would ignore the Tapestry tags.
    I still don't see this as that much of an issue. After all, how much effort does it take to edit a live JSP page in a decent editor and re-load to see the consequences of an edit?However, I see what you are saying.

    Not much effort for you or me. But for an HTML person. You've got to install, at least once an appserver or servlet container, and TEACH them how to use it.

    I've actually been trying to do just that at me job. We currently have non-java people mocking pages in Dreamweaver to show to custmers. Then, we take the pages and jsp-ize them, but that only works so well, especially if you use Tiles or similar layout tool.

    The result: Doing the pages at least twice!! Bugs me. I've suggest installing, say, Tomcat, and showing the people how to do this and suggesting that they learn just enough Struts tags to eliminate this effort. I personally don't think this is hard, but I'm running into considerable resistance and this is from a place where I've introduced a slew of open source tools, Idea, and other things without blowback.
  70. Tapestry 4.0 Released[ Go to top ]

    Well, I would imagine the main issue is my main issue with JSP pages, the rendering. You cannot see the page on any level without rendering the tags. My understanding of Tapestry was that you could see the page in any standard tool because said tool would ignore the Tapestry tags.

    Except in reality, all but the most simple pages are made up of recurring elements, which in Tapestry (or JSF/simple JSPs for that matter) would be 'components', i.e. separate snippets of annotated html which get compiled into a single page at runtime.

    So I don't think Tapestry quite delivers on the promise that html designers can create the html, then developers can annotate with code, and then we can give it back to the designers who will be none the wiser. The pages get chopped up into components and so can't really be viewed and understood by the designers in the form they created them.

    On a side note, one thing I like about JSP is the fact that you write Java inside them and tools understand that. Hence you get code completion, but most importantly compile-time checking of package, class and method names. A huge benefit over hard coded references as in Tapestry templates.
  71. Tapestry 4.0 Released[ Go to top ]

    On a side note, one thing I like about JSP is the fact that you write Java inside them and tools understand that. Hence you get code completion, but most importantly compile-time checking of package, class and method names. A huge benefit over hard coded references as in Tapestry templates.

    This is pure FUD and appears based on guesses on how Tapestry operates, rather than actual experience. What goes into the HTML templates are component ids you assign, and (if you wish) OGNL expressions, which are typically references to the properties of the Java classes you create. There are occasional places in the XML files where you might mention a complete class name, but those exist for legacy purposes at this point.

    In terms of editor, Spindle does a great job of input completion and cross-checking (its for Tapestry 3, with Tapestry 4 coming soon). In addition, a new plugin, for IntelliJ, is now in the works as well.

    Because Tapestry has a rich meta-data model, its quite tractable (I won't say easy) to build editors for it, or integrate it with RAD/MDA systems.
  72. Tapestry 4.0 Released[ Go to top ]

    Spindle does a great job of input completion and cross-checking (its for Tapestry 3, with Tapestry 4 coming soon). In addition, a new plugin, for IntelliJ, is now in the works as well. Because Tapestry has a rich meta-data model, its quite tractable (I won't say easy) to build editors for it, or integrate it with RAD/MDA systems.
    So, support from tool vendors is as important as for, say, JSF?
    I would imagine, with Tapestry, you don't care much about data when doing the design and layout. With JSP, you cannot even do that much with JSP tags because the page won't even render.
    Can one preview a componentized Tapestry template page in a browser so it would show you the full composite page? Everything is in the tools. It would not be hard to develop a tool to create JSP components, especially now, when untraceable scriptlets scattered throughout the page are being replaced with JSTL tags. The problem is that JSP is no longer considered component technology.
  73. Tapestry 4.0 Released[ Go to top ]

    Can one preview a componentized Tapestry template page in a browser so it would show you the full composite page? Everything is in the tools. It would not be hard to develop a tool to create JSP components, especially now, when untraceable scriptlets scattered throughout the page are being replaced with JSTL tags. The problem is that JSP is no longer considered component technology.

    This is not possible today; it is something I expect to add in the future; the ability to run the application in a preview mode. This will be the kind of concern (in the "seperation of concerns" definition) that will be possible to add once I break the inheritance requirement ... the need to subclass from Tapestry base classes.

    Once the Tapestry class and the user provided class are peers of each other, I'll be able to make significant changes to the Tapestry class without breaking user code. I'm looking forward to that.
  74. So, support from tool vendors is as important as for, say, JSF?

    Nope. I'm building an application for a client in Tapestry 4.0, so I'm not using Spindle, at least, not yet. Not a problem. The simplified Tapestry HTML templates are easy enough to view using ordinary editors (I'm using Eclipse and oXygen). I'm using mostly annotations, with very simple XML page and component specifications (mostly just to use the <component> element, which is easier than doing the same in Java code).

    Mostly, it's Tapestry's approach to exception reporting that obviates the need for a tool. Tapestry has been built from day one with best-of-breed exception reporting. So, I use Jetty, execute directly from my workspace (no package/deploy stage) and see detailed exception reports when I make mistakes. Productivity is not a problem, even without complicated tool support, because the framework doesn't hang you out to dry when there's an error.

    A Tapestry exception report displays:

    * The <em>full</em> stack of nested exceptions
    * The JavaBean properties of each exception
    * The stack trace of the deepest exception
    * Request headers, query parameters and attributes
    * Session attributes
    * ServletContext attributes
    * JVM System properties
    * Internal state of key Tapestry services

    Most exceptions are located, meaning they are associated with a specific HTML template or XML descriptor. Tapestry 3.0 told you about those locations, Tapestry 4.0 will display the actual file, highlighting the line in error. What I call line precise exception reporting is that these locations are kept long after the files are parsed, meaning that all kinds of runtime exceptions can still be identified in terms of where to go to make the fix, even when the files parsed properly. BTW ... this is something I've been asked about for years by the Spring guys, and one of the reasons I use HiveMind (this functionality migrated from Tapestry 3.0 to HiveMind 1.0).
  75. Live changes[ Go to top ]

    Mostly, it's Tapestry's approach to exception reporting that obviates the need for a tool. Tapestry has been built from day one with best-of-breed exception reporting. So, I use Jetty, execute directly from my workspace (no package/deploy stage) and see detailed exception reports when I make mistakes. Productivity is not a problem, even without complicated tool support, because the framework doesn't hang you out to dry when there's an error.

    Howard. Firstly congrat on the new release. Tapestry have for a long time been on my 'cool stuff to check-out'. I even got the Tapestry in Action book. However at work we haven't had any webprojects for a while. But this is changing now.

    I was curious how productivity using Tapestry could be high, regarding changes to pages and refreshing from the web browser (like changing a .jsp page).

    So in the quote above you say that using Jetty it's possible to change a page, refresh and see the changes live?

    Yesterday I breifly tried the new WebWork 2.2 and it had such a QuickStart feature - can Tapestry leverage the same feature from Jetty to gain high productivity?
  76. What I do is set up my workspace to effectively mirror my deployed, exploded WAR. You can run Tapestry in a developer mode where it doesn't cache data parsed from HTML and XML files ... so when you make changes you can see those changes immediately (you add -Dorg.apache.tapestry.disable-caching=true to the Jetty launch configuration).

    It isn't perfect; if you change code (which happens a bit more often now, since more is done using annotations) you have to restart Jetty. On my (three year old) laptop, Jetty restarts in just a few seconds, Tapestry takes about eight seconds to initialize, and the first request takes about 20 seconds. After that, each request takes about two - three seconds (much longer than normal, of course). To be honest, when I see how much work Tapestry has to do on each request (including tons of XML parsing and bytecode generation) I'm impressed but just how fast Java is!

    I'm hoping, in the future, to be able to do a smarter job of handling "touched" values, and do a more efficient job of invalidating caches. Ideally, the application would run at full speed until it hits a page that has changed (of course, this change may be to a file directly related to the page, or to any component anywhere within the page).

    I also want to get better with classloader technology, to support reloading when a Java class changes.

    I have a lot of ideas for a "rewrite" of Tapestry but I'm sticking to the much harder road ... of evolving the existing code base closer to my ideal framework.
  77. Re: Tapestry 4.0 Released[ Go to top ]

    Except in reality, all but the most simple pages are made up of recurring elements, which in Tapestry (or JSF/simple JSPs for that matter) would be 'components', i.e. separate snippets of annotated html which get compiled into a single page at runtime. So I don't think Tapestry quite delivers on the promise that html designers can create the html, then developers can annotate with code, and then we can give it back to the designers who will be none the wiser.

    I've run into this as well, but I can't for the life of me figure out how you could improve on the current model. You can have devs annotate the code in such a way that the designers still see recurring elements (say, for example, rows in a table), and have those static rows thrown out at runtime. But at that point you're stuck with maintaining and synchronizing both the dynamic and static rows (or whatever the recurring element might be). So it comes down to a choice: do you want/need to make it easy for non-devs to edit the HTML? or are you more interested in following the DRY (don't repeat yourself) principle? I wish we didn't have to make this choice...
  78. Tapestry 4.0 Released[ Go to top ]

    Well, I would imagine the main issue is my main issue with JSP pages, the rendering. You cannot see the page on any level without rendering the tags. My understanding of Tapestry was that you could see the page in any standard tool because said tool would ignore the Tapestry tags.
    Except in reality, all but the most simple pages are made up of recurring elements, which in Tapestry (or JSF/simple JSPs for that matter) would be 'components', i.e. separate snippets of annotated html which get compiled into a single page at runtime.So I don't think Tapestry quite delivers on the promise that html designers can create the html, then developers can annotate with code, and then we can give it back to the designers who will be none the wiser. The pages get chopped up into components and so can't really be viewed and understood by the designers in the form they created them.On a side note, one thing I like about JSP is the fact that you write Java inside them and tools understand that. Hence you get code completion, but most importantly compile-time checking of package, class and method names. A huge benefit over hard coded references as in Tapestry templates.

    I don't agree that putting Java in a page is a virtue. While you cannot use the more dynamic portions, I would imagine, with Tapestry, you don't care much about data when doing the design and layout. With JSP, you cannot even do that much with JSP tags because the page won't even render. IMO, if you are putting Java in the page, you are making a maintainence nightmare.
  79. Tapestry 4.0 Released[ Go to top ]

    It’s really about previewability. Designers can quickly mock up portions of a website with Simple html with the toolset they are accustomed to and pitch them over the fence to the developers. I agree that for the most part JSF taglibs are almost equivalent to their html counterparts but in order to benefit from JSF code completion specific toolsets need to be used. At the time in order to see any changes to a JSF page we either had to redeploy or edit the pages live which was painful.
  80. Tapestry 4.0 Released[ Go to top ]

    It’s really about previewability. Designers can quickly mock up portions of a website with Simple html with the toolset they are accustomed to and pitch them over the fence to the developers.
    Did you want to say "pitch them over the fence to the management/marketing"? Because preparing HTML for developers means accurate page definition using structural markup and applying proper, compatible and gracefully-degrading CSS. This takes time and I would not characterize it as a "quick mockup". Those who understand CSS inheritance can understand how to start up Tomcat. I presume that designers in your shop do not chop images into table cells like they did 7-8 years ago, do they?
  81. Tapestry 4.0 Released[ Go to top ]

    This was to answer a previous question about a particular aspect of Tapestry that I find appealing. This was by no means to play down the role of the UI Designer but to demonstate the strict seperation of team development that you gain from html template based approaches. At no point did I say that was the final cut .. and the app is suddenly shuttled off to production. There are many iterations that we go through before the final look and feel of the site is complete.
  82. Tapestry 4.0 Released[ Go to top ]

    It’s really about previewability. Designers can quickly mock up portions of a website with Simple html with the toolset they are accustomed to and pitch them over the fence to the developers. I agree that for the most part JSF taglibs are almost equivalent to their html counterparts but in order to benefit from JSF code completion specific toolsets need to be used. At the time in order to see any changes to a JSF page we either had to redeploy or edit the pages live which was painful.
    I don't want to hijack this thread about Tapestry, wich a very good framework indeed but some people should do really a little of research on Facelets or Shale-Clay if you like the html template approach. Our web designer is editing our JSF applications in Dreamweaver, so it is possible :)
    Enough of JSF, this thread is about Tapestry.
    Good job guys, the web frameworks evolved a lot because of you!
  83. Tapestry 4.0 Released[ Go to top ]

    It’ I don't want to hijack this thread about Tapestry, wich a very good framework indeed but some people should do really a little of research on Facelets or Shale-Clay if you like the html template approach. Our web designer is editing our JSF applications in Dreamweaver, so it is possible :)Enough of JSF, this thread is about Tapestry. Good job guys, the web frameworks evolved a lot because of you!

    if you read the original post .. it says earlier release of JSF notably when tool support was very weak .. I am sure alot has changed since then ... again merely stating a feature that I like and not to say other frameworks are not taking this approach or that it's the only way to go.
  84. Congratulations[ Go to top ]

    Congratulations To the tapestry team.

    Tapestry is a wonderful product. I use Tapesty 3 on my J2EE project and it was about converting a client server swing application to Webbased Applications. The Swing Application took us close to 1 year to develop. The entire conversion which included a practical rewrite took 3-4 months thanks to tapestry and hibernate both of which took efficiency to whole new levels.

    How I wish these great products such as Tapestry, Hibernate and Spring had certification exams to prove your credentials. It is something that all open source projects are lacking big time. Taking an exam forces you to study all aspects of an API whereas working on the API usually exposes you to a limited set which you use on a project.

    I really wish this shortcoming of open source projects is addressed eventually. People do not think much of certifications but they have an enormous value in forcing already experienced developers to prove and refresh their skills and new and dedicated developers to show their ability to program in an API without prior experience.

    Sameer
  85. Certification for open source[ Go to top ]

    Certification for leading Java open source frameworks would be great. I don't know how it could be managed, however.

    I just (a couple of hours ago!) attended a JUG with a session on Sun's Java Programmer Certification. All the way through I was thinking to myself, this is all very well but the SCJP exam isn't really showing me anything about a programmer that has real-life relevance.

    For example, one sample question was presented, the answer of which hinged upon the precedence of short-circuit forms of boolean operators vs non short-circuit forms. All it proved to me was that you should never mix the two in one expression, and generally should avoid the non short-circuit forms as they are not idiomatic Java.

    It occurred to me that a more useful certification exam would deal with the proper use of JDBC or Servlet APIs, or even better, a good knowledge of leading open source frameworks that work on top of those APIs.

    I do realise that the "Java Programmer" cert is the entry level, and there are several other certifications that do deal with enterprise APIs. Open source would be a great addition. Again though, I don't know how it could be managed.

    Regards
    John Hurst
    Wellington, New Zealand

    P.S. We like Tapestry 4, too. We've been using it since beta5.
  86. Congratulations[ Go to top ]

    Congratulations To the tapestry team.Tapestry is a wonderful product. I use Tapesty 3 on my J2EE project and it was about converting a client server swing application to Webbased Applications. The Swing Application took us close to 1 year to develop. The entire conversion which included a practical rewrite took 3-4 months thanks to tapestry and hibernate both of which took efficiency to whole new levels.How I wish these great products such as Tapestry, Hibernate and Spring had certification exams to prove your credentials. It is something that all open source projects are lacking big time. Taking an exam forces you to study all aspects of an API whereas working on the API usually exposes you to a limited set which you use on a project.I really wish this shortcoming of open source projects is addressed eventually. People do not think much of certifications but they have an enormous value in forcing already experienced developers to prove and refresh their skills and new and dedicated developers to show their ability to program in an API without prior experience.Sameer

    I disagree about certs. I've worked with far too many people who had certs, but where awful programmers. Certs, IMO, mean you can pass a test. This doesn't necessarily translate to good programming abilities.
  87. Certifications[ Go to top ]

    You're right, but at the same time I wish there was some way to encourage more programmers to learn about the great open source libraries out there, to complement their "officially certified" J2EE knowledge.

    Regards
    John Hurst
    Wellington, New Zealand
  88. Certifications[ Go to top ]

    You're right, but at the same time I wish there was some way to encourage more programmers to learn about the great open source libraries out there, to complement their "officially certified" J2EE knowledge.RegardsJohn HurstWellington, New Zealand

    Definitely agree! Of course, if other companies are spending time writing in-house web-frameworks and persistence layers AND not using the obvious advantages of a Spring, that means that those using such stuff can move just a bit faster and that's more money in your pocket.

    Quite the conundrum.
  89. Certifications[ Go to top ]

    I disagree about certs. I've worked with far too many people who had certs, but where awful programmers. Certs, IMO, mean you can pass a test. This doesn't necessarily translate to good programming abilities.

    However, if the questions are not direct, certs do test the following basic knowledge and are useful as a screening tool:

     * concepts
     * apis
     * syntax(!)

    The questions in some IBM tests are quite oblique and require more than just memory.

    Certifications also do force one to look at the nooks and crannies of the technology. Even an experienced professional could fail in a test because, apart from understanding the underlying concepts, he has not gone beyond what is required for his immediate tasks and explored the full breadth of the technology, or because he has not kept upto date with new developments.

    In view of the large and growing number of shops using open-source technologies IMHO there is now a definite need for certifications in FOSS technologies. Many of these shops may shy away from o/s technologies because of this dark area (not knowing how to hire people). Many of them take it for granted that a certification fully measures the technical side of a candidate. Correspondingly, the paucity or non-existence of such certifications mean that such people are not easily available and hence the technology is not viable for adoption.

    For the above reason, a certification program could also help in the spread of o/s technologies, increasing community, which is a critical factor in their success.

    Also, many people would want to get that initial career start with a certification like "Rod Johnson Certified Spring Developer" RJCSD or HLSCTD (guess) or "Apache Certified Server Administrator".


    Certifications could be a good source of income for open-source projects and give the authors more independence from funding sources thus making them more free to explore and innovate.

    However, it needs to be established first whether this can indeed be a source of income.

    Knock on effects would be a proliferation of certification books, more people talking about it, more people seeing this as a alternative 'qualification' to obtain on par with the others, like CCNA, CCNP, SCJD, etc.

    Linux already has a few certifications: RHCE, LPI, SAIR GNU LINUX, etc. So does JBoss.


    Alec
  90. Congratulations!!![ Go to top ]

    I just wanted to say that after trying many frameworks, Tapestry is the one that I enjoy developing with the most. It's component based architecture allows you to really create reusable components and with the introduction of Hivemind in Tapestry4 is really easy to define services that you can use across your application via dependency injection. Not to mention the cool projects surronding tapestry such as Tacos, Spindle, Trails, Tassel, Palette
  91. The Problem with Tapestry[ Go to top ]

    .. is interoperability with existing frameworks like Struts. We happen to have built up a huge application with Struts , J SPs and filters. Whereas other competing frameworks like Spring MVC, Webwork (which is merging with Struts) and JSF offer backward compatibility paths to play nice with existing code, Tapestry does not. In a Struts based application, I can keep on adding new struts-config.xml or Spring's application-context.xml to continue to extend the application functionality and they all play nice -- sharing data, tasks and session information as needed. I am not sure that this is possible in Tapestry.

    And that is a problem for me.
  92. from a .net perspective...

    i am a csharp .net developer of 3/4 years experience and have recently (last few weeks) moved to tapestry and java. i can definately recommend tapestry: it is extremely flexible, powerful, and easy to use / learn. the ioc stuff in particular is awesome...

    perhaps the best bits are the component template files. they give you so much control over the html output. oh yeah and the way it handles javascript is really cool... cant say enough good things about it. give it a go, im sure you will like it. it p0wns .net :P

    there is a good community it would seem too, the mailing list is certainly very busy with prompt replys to problems.. ace :D

    respect to howard lewis-ship and t'others for putting in all the hard work.
  93. from .net to tapestry... schweeeeet[ Go to top ]

    not to discredit tapestry or anything, but for 'jabbing' at Wickett's community and their self-promoted exuberance, i find this kind of funny--

    http://article.gmane.org/gmane.comp.java.tapestry.user/30514
  94. not to discredit tapestry or anything, but for 'jabbing' at Wickett's community and their self-promoted exuberance, i find this kind of funny-- http://article.gmane.org/gmane.comp.java.tapestry.user/30514

    sad :(
  95. from .net to tapestry... schweeeeet[ Go to top ]

    not to discredit tapestry or anything, but for 'jabbing' at Wickett's community and their self-promoted exuberance, i find this kind of funny-- http://article.gmane.org/gmane.comp.java.tapestry.user/30514

    I don't understand why you posted this message. I thought you were the guy from JSF/Facelets. I don't see anything wrong with the quote: "Wicket is an interesting refactoring of Tapestry", do you?
  96. from .net to tapestry... schweeeeet[ Go to top ]

    I don't see anything wrong with the quote: "Wicket is an interesting refactoring of Tapestry", do you?

    Jan, to be fair, there was more in that response, yet Wicket guys didn't need to plug themselves-- I hadn't mentioned any of my musings, although I do really want Howard's innovative insight in the next EG though :-)
  97. from .net to tapestry... schweeeeet[ Go to top ]

    I don't see anything wrong with the quote: "Wicket is an interesting refactoring of Tapestry", do you?
    Jan, to be fair, there was more in that response, yet Wicket guys didn't need to plug themselves-- I hadn't mentioned any of my musings, although I do really want Howard's innovative insight in the next EG though :-)

    Heheh, if Steve Jobs can go Intel, maybe Howard can go JCP ;-)
  98. Wicket bash?[ Go to top ]

    ... yet Wicket guys didn't need to plug themselves

    Just for the record: no one of the development team did any plugging here. I hope you don't blame us (the Wicket team) for a remark that was made by someone we don't even know.

    HLS could have been a little bit smarter about that too. I have never been involved in any Tapestry bashing (I have actually been promoting it as a viable alternative) and certainly hope that HLS stays out of any further mud slinging in the future. Especially when it involves untruths like Wicket being a branch of Tapestry. Really...
  99. I don't see anything wrong with the quote: "Wicket is an interesting refactoring of Tapestry", do you?

    Well, I do. It states that Wicket is a refactoring of Tapestry, which it is not.
  100. Tapestry to Masonry[ Go to top ]

    As hopeless tapestry is for Web Develpment in Java, Ship seems to have concluded a long time ago that tapestry was the way to go.

    Of course Lord. Ship, tapestry is the only way to develop web apps. in your own little well. In my, little well I'll stick to JSP, JSTL and JSF.

    You and your "COMMUNITY"?

    THHHUUUPCCCHHHHUK !!!!!

    What's next? Masonry? Idiot!!!!!!! ?
  101. Horward advised people on his mailing list not to bash other frameworks but here is he bashing Wicket. Consistency is one of the main goals of Tapestry, claims Howard in his TIA book. Unfortunately, the man himself can't be consistent.

    J
  102. Tapestry and PDA[ Go to top ]

    Anyone got experience using Tapestry for PDA web applications?

    At work we have an old inhouse messay .jsp web application used by PDA's. We have especially problems with running JavaScript on the different PDA hardware.

    We can't avoid using JavaScript as we want to minimize the net traffic, so we use it for:
    - validation
    - simple page layout changes (by clicking a radio button etc.)
    - automatick timeout if idle for 5 mins (for security reasons the PDA must automatically blank the screen, so we can't just rely on the server session timeout)
  103. Tapestry 4.0 Released[ Go to top ]

    * Tapestry 4.0 includes optional JDK 1.5 annotation support (but Tapestry still works with JDK 1.3).

    Tapestry does not currently run under JDK 1.3 because of a bug (in HiveMind 1.1 which Tapestry depends upon). So do yourself a favor and don't waste hours trying to make it work under 1.3 until this bug is fixed (like I just did).