Discussions

News: Tapestry 3.0.2 Released

Bookmark and Share Get thread feed

  1. Tapestry 3.0.2 Released (20 messages)

    Release 3.0.2 of the Tapestry web application framework has been released. This is the final bug fix release for Tapestry 3.0, addressing some minor problems and enhancements that could not wait for Tapestry 3.1.

    Tapestry is a comprehensive, component-based web application framework, written in Java, and available under the Apache Software License. It features minimal Java coding, a high degree of reuse, and overall attention to developer productivity - especially on large development teams.

    Tapestry is the web framework which powers TheServerSide itself.
    Reply to this

    Threaded Messages (20)

  2. Tapestry 3.0.2 Released[ Go to top ]

    Congratulations. Good work.
    Now for the more interesting one: when will 3.1 alpha be available? I'm dreading the hivemind colonization of Tapestry and I want to see how all of that will look. Hopefully, all my fears are just a result of an incomplete grasp of hivemind and wild imagination, and I will not need to install an XML parser in my parietal lobe :).
    Reply to this Reply to original

  3. Tapestry 3.0.2 Released[ Go to top ]

    Provide an inter-operability path with Struts -- Please!!!!

    I would love to dump Struts (who wouldn't ?) but there is now way I can recode hundreds of actions and commands to move to a new technology.
    Reply to this Reply to original

  4. Tapestry and Struts[ Go to top ]

    With "friendly URLs" built in, and some other stuff coming, it will be very easy to have Struts (WebWork, Servlets, etc.) and Tapestry interoperate.
    Reply to this Reply to original

  5. Tapestry and Struts[ Go to top ]

    With "friendly URLs" built in, and some other stuff coming, it will be very easy to have Struts (WebWork, Servlets, etc.) and Tapestry interoperate.

    Can you elaborate on how this might work? Are you just talking link-level interoperation?
    Reply to this Reply to original

  6. Tapestry and Struts[ Go to top ]

    I am also interested in how this might work and in what version. We are currently considering integrating JSF or Tapestry into our struts environment. I just went through Kent Tong's excellent tapestry tutorial http://www2.cpttm.org.mo/cyberlab/softdev/tapestry/ and a myfaces tutorial. Tapestry would be a better fit for us.
    Reply to this Reply to original

  7. Tapestry 3.1?[ Go to top ]

    We're currently running a vote to release 3.1-alpha-1.
    Reply to this Reply to original

  8. Not Invented Here Syndrome ?[ Go to top ]

    We have tried and trusted Spring and Pico. But instead of re-using that , why do we have to learn a brand new one ?
    Reply to this Reply to original

  9. Not Invented Here Syndrome ?[ Go to top ]

    We have tried and trusted Spring and Pico. But instead of re-using that , why do we have to learn a brand new one ?

    You don't have to learn anything. If you don't want to know about HiveMind, you don't ever see it.

    Spring and PicoContainer don't contain the features necessary to support Tapestry.
    Reply to this Reply to original

  10. Not Invented Here Syndrome ?[ Go to top ]

    will spring users still be able to leverage the full power of newer versions of tapestry without hivemind ?
    Reply to this Reply to original

  11. Not Invented Here Syndrome ?[ Go to top ]

    will spring users still be able to leverage the full power of newer versions of tapestry without hivemind ?

    This is getting to be somewhat frustrating. These are frameworks not application servers. There's nothing that keeps you from using both Spring and HiveMind, or every lightweight container you can lay your hands on. That's open source --- freedom of choice, to mix and match to your heart's content.
    Reply to this Reply to original

  12. Tapestry 3.0.2 Released[ Go to top ]

    I have been using Tapestry with Spring, and for 3.1 it will be integrated with HiveMind? Now I have two IOC containers and concepts to deal with ???
    Reply to this Reply to original

  13. Tapestry 3.0.2 Released[ Go to top ]

    I think hivemind can easily wrap spring services and you will be able to continue doing what you have so far. however, i do think some familiarity with hivemind will be necessary.
    Reply to this Reply to original

  14. Tapestry 3.0.2 Released[ Go to top ]

    I have been using Tapestry with Spring, and for 3.1 it will be integrated with HiveMind? Now I have two IOC containers and concepts to deal with ???

    Yep, but the containers are lightweight and invisible.

    In 3.1, if you want to inject a HiveMind service into your page, you add the following to your page spec:

    <inject property="myProperty" object="service:mymodule.MyService"/>

    If you want to inject a Spring bean instead:

    <inject property="myProperty" object="spring:MyBean"/>


    I'm very excited about this; it's cleaner and more efficient than using OGNL and <property-specification> initial-value.
    Reply to this Reply to original

  15. Would Hivemind be a good canditate for StrutsShale?[ Go to top ]

    StrutsShale is looking for a good IoC framework... Perhaps they ought to consider Hivemind since you have already demonstrated its value in Tapestry 3.1.
    Reply to this Reply to original

  16. Tapestry Question about throughput[ Go to top ]

    I'd ever coded a simple program via tapestry, yet be not very familiar with it. And it reminded me of one question about it's performance. Hope someone could answer it, i.e., "Does Tapestry tag would slow down it's performance?". I had this question basically resulted from the tag lib that other framework used, e.g., webwork, may parse the tag, first, then rendering the html tag. Yet it yields a problem of displaying jsp based page, of which only few seconds the page would be shown out in comparison to html tag only page (w/t tag lib plugged).
    Or How to avoid this problem?
    I appreciate any suggestion.
    Sincerely.
    Arsene
    Reply to this Reply to original

  17. Tapestry Question about throughput[ Go to top ]

    Arsene,

    Tapestry pages are compiled to bytecode, like servelets. Then they are cached in an object pool (like db connection pooling). When a user requests a tapestry page, an available instance of that page is drawn from the pool and any persistent data for the requesting user is applied to the instance; then the page is sent to the browser.

    The resulting performance curves wind up being close to servlet performance curves.

    Bill
    Reply to this Reply to original

  18. Tapestry Question about throughput[ Go to top ]

    Arsene,Tapestry pages are compiled to bytecode ...

    Not exactly true. Tapestry does quite a bit of bytecode enhancement (writing ugly but necessary code for you at runtime). This exapnds greatly in 3.1.

    Whereas a JSP compiled to a servlet is quite monolithic, Tapestry uses a goodly number of small objects (components, etc.). Rendering is a tree walk.

    The bad news is that this is more memory and CPU intensive than a pure servlet solution. The good news is in two parts: first, it largely doesn't matter what's going on in the presentation teir; its contribution to the overall request processing time is negligable compared to any backend database access.

    Second: Because Tapestry is based on pooled instances of pages (and the entire heirarchy of objects contained within the page), there's lots of room for optimizations of how and when data moves around. For example, most servlet containers spend a lotof work moving JSP tag objects into and out of pools, re-initializing them each time.

    Tapestry components, roughly the equivalent of a JSP tag, are instantiated and configured once; once so constructed, they work quite efficiently. They aren't pooled directly, just as part of the overall page. Tapestry gains over JSPs in this way, because the granularity of pooling is at a much higher and coarser level, so less effort is expended managing pooled objects.

    Tapestry 3.1 adds a number of improved optimizations that cuts down on the use of reflection for moving data around. This is good, because Tapestry applications can spend up to 50% of their time inside OGNL, doing reflective access. Less of that is more performance, and OGNL 3.0, due soon, is supposed to be much, much faster as well.

    The biggest bottleneck I'm aware of in Tapestry is the conversion ofcharacters from internal Unicode to the (default) utf-8 encoding.
    Reply to this Reply to original

  19. Tapestry Question about throughput[ Go to top ]

    Is there any report/ benchmark test about this comparison?
    Or Is there any article, like "best practice", talking about tapestry? (For I'd ever searched several website, such as on.java as well as javaworld.com; seemly there ain't much stuff talking about tapestry).
    I appreciate all your help, sincerely.
    Arsene
    Reply to this Reply to original

  20. Same technology in TSS.NET?[ Go to top ]

    Very interesting and useful, Howard!!

    I'm curious, TSS.NET was built upon same technology?
    Reply to this Reply to original

  21. Same technology in TSS.NET?[ Go to top ]

    Very interesting and useful, Howard!!I'm curious, TSS.NET was built upon same technology?

    I think if you do a view source on a TSS.net page, you'll be able to draw your own conclusions.
    Reply to this Reply to original