Vote to release Tapestry 3.0 and thoughts for 3.1

Discussions

News: Vote to release Tapestry 3.0 and thoughts for 3.1

  1. Howard Lewis Ship and the Tapestry team have submitted a vote to release version 3.0. Howard also discusses his plans for 3.1.

    Excerpt
    This leads me to the following prediction: In Tapestry 3.1, Tapestry applications will be significantly faster that servlet, JSP, Struts or JSF applications with equivalent functionality. Of course, it's pretty much impossible to find applications with "equivalent functionality", but none the less. By improving the efficient of OGNL, and making use of the optimizations possible because of the Tapestry component object model, I believe the overall processing (especially with respect to Java reflection) will decrease noticeably.
    Read Howard Lewis Ship in Vote to release Tapestry 3.0
  2. If you're in the mood for voting, vote here, too: http://www.intellij.net/tracker/idea/viewSCR?publicId=9568
  3. Thanks for the support, I think, but whatever that is, it's pretty far out of date. Tapestry is already a Jakarta project; this latest vote is about releasing the current code base as a final 3.0 release.
  4. Actually this had nothing to do about Tapestry being or not a jakarta project: it's a feature request for inclusion of Tapestry support in IntelliJ IDEA! ;)

    (yes, I know, I know, there's spindle and so on: if spindle was a swing plugin there could be an easy way to port it to IDEA, but since it's SWT...)
  5. I'm all for that .. and Erik Hatcher is as well (he's a die hard IDEA junkie).

    Geoff Longman has done an amazing job with Spindle; I believe the code base for Spindle is about the same size as all of Tapestry. I'm using it myself right now, putting together some more examples and presentations and it really helps. Getting the same thing into IDEA would be a master-stroke.
  6. Actually its Spindle's dependancy on the Eclipse ide api's rather than SWT that makes porting outside Eclipse difficult.

    The Spindle Eclipse feature consists of several plugins, the only ones that matter being the 'core' and the 'ui' plugins. The core provides the project builder and the infrastructure that 'ui' depends on. 'ui' provides the editors, wizards and the like.

    Of 240 classes in 'core', none import swt classes but 11 import jface classes (which depend on swt).

    Of 297 classes in 'ui', 111 depend on swt or jface.

    So, in theory, most of the work would be in porting the 'ui' plugin out of Eclipse. But in practice I don't think that would be easy as both plugins depend heavily on other non-ui related Eclipse classes (documents, java classpath struture, projects, builders, resources and resource change deltas, the list goes on and on). There would need to be equivalent services available in any target environment.

    In any event such a port is way beyond my available bandwidth. Right now I'm using what little free time I have optimizing the Spindle builds for speed.

    So far (and as yet unreleased) I've managed to double the speed of both the full project build and the incremental (auto) build by eliminating some redundant processing.

    Geoff
  7. Actually its Spindle's dependancy on the Eclipse ide api's rather than SWT that makes porting outside Eclipse difficult.The Spindle Eclipse feature consists of several plugins, the only ones that matter being the 'core' and the 'ui' plugins. The core provides the project builder and the infrastructure that 'ui' depends on. 'ui' provides the editors, wizards and the like.Of 240 classes in 'core', none import swt classes but 11 import jface classes (which depend on swt).Of 297 classes in 'ui', 111 depend on swt or jface.So, in theory, most of the work would be in porting the 'ui' plugin out of Eclipse. But in practice I don't think that would be easy as both plugins depend heavily on other non-ui related Eclipse classes (documents, java classpath struture, projects, builders, resources and resource change deltas, the list goes on and on). There would need to be equivalent services available in any target environment.In any event such a port is way beyond my available bandwidth. Right now I'm using what little free time I have optimizing the Spindle builds for speed.So far (and as yet unreleased) I've managed to double the speed of both the full project build and the incremental (auto) build by eliminating some redundant processing. Geoff
    That's what I was suspecting... ;) My opinion is that being IDEA a commercial IDE, Jetbrains itself should be responsible for making it a compelling alternative to open source solutions such as Eclipse, and this means especially providing at least the equivalent of the most important plugins esisting for it.

    Unfortunately it seems that Jetbrains these last days is focusing mainly on the "normal java development" productivity, and the support IDEA gives for web development is somewhat disappointing even for "normal JSP development" (maybe because they're producing another tool focused on RAD for webapps): for this reason I doubt there will ever be some kind of "official" tapestry support from IDEA (except if tapestry takes over the world in the meanwhile, of course). It's a pity, though.
  8. It's accepted knowledge that JSPs are efficient because they are monolithic, stateless, compiled Java classes.

    However, like much accepted, common knowledge, it may not be correct.

    I've had to debug some problems in JSPs using Struts in both Tomcat and WebLogic, so I've seen the kind of code that gets generated.

    What I found interesting is the amount of code related to pooling JSP tag instances. The thing is, the JSP as a whole is stateless, but while the JSP is rendering, the tags within the JSP do have considerable transient state.

    So, each time a JSP tag is referenced in a JSP, the corresponding code obtains a pooled instance of the tag, re-initializes all its attributes, uses it ... then clears it and puts it right back into the pool.

    This is where Tapestry has a bit of an advantage; in Tapestry, the entire *page* is pooled, not the components within the page, so the cost of a component is relatively small. Further, the way Tapestry parameters work allows a component to identify intransient parameters ... parameters whose value doesn't change, such as with a <string-binding> or <message-binding>, or a literal value in an HTML template. In those cases, the component doesn't need to reset the property value after the component renders, or re-initialize the property value when the component is utilized again.

    Tapestry 3.1 will be using even smarter dynamic bytecode generation (using Javassist) to further improve the efficiency with which a component can access its parameters. OGNL will be using Javassist (or a similar library) to build more efficient access paths to object properties, as efficient as ordinary method invocations, rather than reflection.

    So, the optimizations (including the invariant checks), mean that Tapestry is using OGNL less ... and the OGNL improvements mean that when OGNL is used, it works more efficiently.

    Now all we have to do is build "equivalent" applications and start comparing.
  9. & the components?[ Go to top ]

    Howard et al,

    Nice work, you deserve to be proud of it.

    What will make or break Tapestry adoption will be the availability of good and comprehensive components to aid rapid development.
  10. Features needed for tapestry[ Go to top ]

    Tapestry is realy a good framework than others i used, including struts, xmlc, and even a framework named "Object Server Page" which is created myself and something like tapestry. Our teams using Tapestry for about 1 years and 2 middle-scale projects.

    I realy would tapestry support the following feature:
    1. Reload html template automaticly. no need to restart the webapp to active a HTML modification.( the current org.tapestry.disable-caching not works for it at all)
    2. A more simple way to create jwc, support extending a exists jwc just like subclass the parent class.
    3. Provide more static-type check, the current ognl:expression can only be checked at runtime. a static-type check system like JSP provide more rubost application development with the help of compiler.
    4. do internal optimize, when i add the function of feature 1 in our projects, i fond the tapestry internally has many performance issues, eg, a page have dupicate pool in 3 classes, 1 pool the page, 2 pool the ComponentTemplate, that means the internal code is still -)
    5. More reusable jwc, special dhtml jwc to improve the ui's effect, will make tapestry more acceptable. just a good core framework not means a successful framework.
    6. Add a WYSIWYG editor in famous IDE such as eclipse, the spindle is realy a good tool that help me a lot. but a WYSIWYG editor maybe more valueable.
  11. Features needed for tapestry[ Go to top ]

    1. this works on my computer from the faq: Start your servlet container with the JVM system parameter org.apache.tapestry.disable-caching set to true, i.e., -Dorg.apache.tapestry.disable-caching=true.
    maybe you specified it at the wrong place: web.xml or .application?)

    5. I think with all the different browsers, its very time consuming just to brush up the UI a little bit. I think most components are already done very well.

    6. Even HTML editors generate often ugly HTML. I am afraid, for Tapestry it would be even worse.

    7. Its open source. You could always help and improve.

    I really appreciate all the work howard and his collegues have invested in this great framework. I hope Howard will, besides his symposium schedule, still have some time (and money from somewhere: sales from his excellent book, teaching, consultancy) for coding on tapestry and getting 3.1 ( better urls, better directory structure, better testing framework) out quicker than 3.0.
  12. parameter bindings[ Go to top ]

    in a .html page template, i use this syntax...

     for ognl bindings:
     <span jwcid="insert@Insert" value="ognl:someProperty" />

     and this syntax for message bindings:
     <span jwcid="insert@Insert" value="message:someMessage" />

    while in a .jwc (components) or .page (page) specification, i use this syntax...
     for ognl bindings:
      <component id="headingInsert" type="Insert">
         <binding name="value" expression="someProperty"/>
      </component>
      
     and this syntax for message bindings:
      <component id="headingInsert" type="Insert">
         <message-binding name="value" key="someProperty"/>
      </component>

    and yet even more styles for "inherited" bindings, etc. WHEW! All those different xml elements for something as simple as a parameter binding! And we do the same routine with <private-asset>'s and <context-assets>'s! Why not just simplify the syntax?
      
      <component id="headingInsert" type="Insert">
         <bind param="someParam" value="someValue" type="ognl"/>
      </component>

    where type can be "ognl" | "literal" | "message" | "inherited"

    likewise, why not
      <asset name="someName" location="someLocation" type="context"/>

    where type can be "context" | "private"


    i'm a real fan of "pretty" xml. and i'm sure i'm not the only one.