Discussions

News: Tapestry now an official Jakarta Project

  1. The Tapestry project has now officially relocated from SourceForge to the Apache Jakarta project. This followed a five month incubation period at Jakarta, and a sweeping acceptance vote by the Jakarta PMC (Project Management Commitee), Incubator PMC, and Tapestry developers themselves.

    Tapestry is a component-based web application framework that supports a very high level of developer productivity and insanely high levels of code reuse. Tapestry elegantly supports large scale projects and streamlines the interaction between HTML and Java developers within a project.

    Tapestry 3.0 is currently in a late alpha stage, with a beta release due within a week or two. 3.0 streamlines and simplifies Tapestry application development without sacrificing any of the power of earlier releases.

    Threaded Messages (78)

  2. Yahoo!
  3. 3.0 streamlines and simplifies Tapestry application development without sacrificing any of the power of earlier releases.


    Ease of development witout sacrificing power...
    This is the main caracteristic of a good framework/API/library/development environment/programming language/...

    Mileta
  4. Streamlining[ Go to top ]

    Should have mentioned that even Tapestry 2.3 significantly streamlined servlet development (relative to Struts, or other Model 2 approaches). 3.0 is a streamlined version of 2.3.

    The philosophy that Tapestry has used is "strict now, leniant later". It's much easier to carefully releas restrictions than it is to bring order out of chaos.

    Tapestry 2.3 requires a very strict app structure; The servlet must have an init-parameter identifying the application specification, the application specification must list every page and component in the app, giving complete paths to each (within the classpath). Each spec must contain a full list of every component and so on.

    3.0 (a beta is due shortly) eases this; Tapestry uses a default name for the app spec, and searches for it in WEB-INF rather than on the classpath. If there's no app spec, that's OK too.

    Pages and components are simply any .page or .jwc files (respectively) in WEB-INF.

    An HTML file is also a page, even if there is no page specification.

    HTML templates are now in the context root rather than on the classpath.

    Components may now be specified in place in an HTML template, as an implicit component. Example:

    <span jwcid="@Insert" value="ognl:user.name"/>

    For most simple components, such as this Insert, there's no need to put anything in the page specification.
  5. Hi All

    Its good to see Tapestry as a Jakarta project. It really is a relevation if you have been trying to build "components" using Struts or something similar. And it works really well if you can get Javabeans from somewhere (e.g. a JDO implementation or an O/R mapper).

    Cheers
    David
  6. Congrats!

    Long live Tapestry!!!!
  7. Wonderful news. Tapestry deserves the recognition and this will surely increase its user base.

    I am curious though. What does an Apache project buy you that Sourceforge doesn't? Can someone explain the intangible benefits. How will it change Tapestry's feature set, turn-around time on bug fixes, licensing, etc... Is it like listing on NASDAQ versus NYSE?
  8. Apache vs. Sourceforge[ Go to top ]

    I am curious though. What does an Apache project buy you that Sourceforge doesn't? Can someone explain the intangible benefits. How will it change Tapestry's feature set, turn-around time on bug fixes, licensing, etc... Is it like listing on NASDAQ versus NYSE?


    From an outsiders view, I would say that it buys you some credibility. By that, I mean that if I see a new project appear in the Jakarta family, I am pretty sure it is tried-and-true software that I can trust. I have used in production *many* of the Jakarta projects (several Commons sub-projects, Log4J, Lucene, ORO, POI, Struts) and have rarely been disappointed, let alone bitten by a nasty bug. So, by having your project associated with Jakarta, I would say you get a bonus "warm fuzzy" right of the bat.

    Sourceforge projects, OTOH, are hit or miss. Some are very active, useful and production ready (e.g. JBoss, Hibernate) while others are perpetually in "alpha" state. In fact, I don't think I have ever "discovered" an OSS project through the Sourceforge site, while I have "discovered" a new project by scanning the Jakarta home page.

    In other words, Sourceforge projects are OSS projects that *might* be useful to a Java developer, while Jakarta projects (most likely) will be useful to a Java developer.

    Just some thoughts.

    Ryan
  9. Part of this is becase of the meritocracy at Apache and Jakarta.

    It took over five months to move Tapestry from SourceForge to Jakarta. At every step of the way, Tapestry was challenged in a number of ways, and there were many votes on progress ... on the final vote, any of about 18 people involved could have vetoed the progression of Tapestry to full project status.

    That's the key to the Jakarta brand: for Jakarta projects there is a major filter that keeps weaker projects from moving up. You have to have a commitment, a following, multiple active developers, and you must be ready and capable to defend your point of view based on technical merit. It's an uphill battle where nobody owes you anything, but the results are ultimately worth it.

    The best part was early on, where Jakarta members (some with voting rights) would start with the statement "we don't need another web framework", would grudgingly check out the Tapestry code and community, and would end up enthusiastically supporting Tapestry.

    In addition, part of the change was a conversion from LGPL to ASL. I now vastly prefer the ASL because it fills my personal goals: that Tapestry should become all pervasive. I look forward to a time when JBoss, WebLogic and Websphere all bundle Tapestry with their products (even though the ASL allows them to tweak the implementation and call it something different).
  10. Apache vs. Sourceforge[ Go to top ]

    Part of this is becase of the meritocracy at Apache and Jakarta.


    <sigh>

    This is really quite an absurd statement, Howard. If you compare sourceforge.net projects as a group with apache.org projects as a group, you are comparing a situation where anybody can put something up there to a situation where there is a filtering mechanism. So there is no need for any particular explanation of why an apache.org project is better quality on average than a random sf.net project.

    I mean, the output of even a very mediocre technical publishing company will be of far a higher standard on average than the material out there on the web and usenet -- since, in the latter cases, there is absolutely no filter. The publishing company has some editorial staff who vet out obvious crap.

    To say that the average apache project is better than the average sourceforge project because it's such a great meritocracy and so on... that's surreal. I mean, it couldn't possibly be otherwise! Anybody can put up a project on sourceforge!

    A more relevant comparison, IMO, would be between apache projects, and <em>fairly well-known</em> projects on sf.net. And then, already, the conclusions would be less obvious. Many people would argue that hibernate is better than ojb. I probably shouldn't say it, because of my involvement, but I will say it: FreeMarker is clearly superior to Velocity. Velocity is not currently competitive. And I am sure there are literaly tons of non-apache web app frameworks that are superior to Struts and Velocity. Come to think of it, Tapestry was one such example until recently.... :-)

    >
    > It took over five months to move Tapestry from SourceForge to Jakarta. At every step of the way, Tapestry was challenged in a number of ways, and there were many votes on progress ... on the final vote, any of about 18 people involved could have vetoed the progression of Tapestry to full project status.
    >
    > That's the key to the Jakarta brand: for Jakarta projects there is a major filter that keeps weaker projects from moving up. You have to have a commitment, a following, multiple active developers, and you must be ready and capable to defend your point of view based on technical merit. It's an uphill battle where nobody owes you anything, but the results are ultimately worth it.

    Well, I congratulate you on joining the club. You are doing well. I have noticed over the past couple of years that you have put a herculean effort into Tapestry. However, I am puzzled as to what "results" you are referring to above?

    Is Tapestry a better piece of software than it was before joining Jakarta?

    >
    > The best part was early on, where Jakarta members (some with voting rights) would start with the statement "we don't need another web framework", would grudgingly check out the Tapestry code and community, and would end up enthusiastically supporting Tapestry.

    Well, that is gratifying, I'm sure. Of course, you've done all the hard work of building that community. If ASF had recognized Tapestry's potential a couple of years ago when it was not so well known, I think there would be more legitimate reason to laud their role. To have that brand-name recognition would have made things a lot easier for you. As things stand, I don't know what ASF has brought to the table. They admit you into their club when you probably don't need them anyway.

    That's my honest reaction. Don't really take this as a flame. I can understand that you're happy about this. OTOH, if I were a moderator of these forums, I would have filtered out your announcement, because basically... I don't think it's really news per se.

    Best Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project, http://freemarker.org/
    FreeMarker 2.3pre2 is out!
  11. Apache vs. Sourceforge[ Go to top ]

    Part of this is becase of the meritocracy at Apache and Jakarta.

    >
    > <sigh>
    >
    > This is really quite an absurd statement, Howard. If you compare sourceforge.net projects as a group with apache.org projects as a group, you are comparing a situation where anybody can put something up there to a situation where there is a filtering mechanism. So there is no need for any particular explanation of why an apache.org project is better quality on average than a random sf.net project.

    But we're not talking about random projects. We're talking about having the discipline to learn the Apache rules, to create proposals, to motivate people. Running an SF project is a cry in the wilderness ... it very easy to be dismissed because what you produce is not evaluated by your peers. Moving to Jakarta is a process of evaluation that it absent elsewhere. Jakarta is not an exclusive club, but you'd be hard pressed to find any dead wood there; the average Jakarta contributor has enough discipline to build a good product and work within a good process ... if not, they would not have become a contributor. On SF.net, you can have individuals with very high standards (for instance, me) but there's no way to evaluate the horde of projects to find the good ones.

    > Well, I congratulate you on joining the club. You are doing well. I have noticed over the past couple of years that you have put a herculean effort into Tapestry. However, I am puzzled as to what "results" you are referring to above?
    >
    > Is Tapestry a better piece of software than it was before joining Jakarta?
    >

    I've found that perception is reality. The cache of the Jakarta brand has motivated many in the Tapestry developer community to step forward and put new efforts in ... perhaps they feel that Tapestry is more of a going concern now, perhaps they want to extend their resume, ride Tapestry's coattails. New contributors have come on board and new mentors have appears in the mailing lists. It's a feedback cycle ... these contributions further enhance the perception of Tapestry and, by extension, Jakarta. That's not accidental, that's the system working.

    Tapestry 3.0 (beta due shortly) is many times improvement over Tapestry 2.3, and 2.3 already kicked ass. How much of that is related to the move to Jakarta? Impossible to say, much of the work was done by me and would have occured, eventually, anyway. I can say that the increased vibrancy of the developer community has lead to improvements that may not have otherwise occured. The drive to use bytecode enhancement was led by Mind Bridge, not me. Line precise exception reporting was a challange (by, I believe, a Mr. Abraham?) Some of the new components (DatePicker, espcially) were contributed by people I hadn't heard of before the move to Jakarta. The move to Jakarta has energized the community and Tapestry is that much better for it.
  12. SourceForge vs Jakarta[ Go to top ]

    But we're not talking about random projects. We're talking about having the discipline to learn the Apache rules, to create proposals, to motivate people. Running an SF project is a cry in the wilderness ... it very easy to be dismissed because what you produce is not evaluated by your peers. Moving to Jakarta is a process of evaluation that it absent elsewhere. Jakarta is not an exclusive club, but you'd be hard pressed to find any dead wood there; the average Jakarta contributor has enough discipline to build a good product and work within a good process ... if not, they would not have become a contributor. On SF.net, you can have individuals with very high standards (for instance, me) but there's no way to evaluate the horde of projects to find the good ones. <

    I respectfully disagree with much of this.

    I am far more interested in being evaluated by actual *users* than by "peers", whoever you mean by that. Especially in a case like Tapestry, Hibernate or Freemarker, where users are actual developers, quite capable of evaluating the quality of code for themselves, I'm not at all certain what extra expertise is being brought by these "peers".

    From my point of view, if I find an sf.net project with >5000 posts in the user forums, of mailing lists, then I *know* it has something special to offer. To get to that level of success, it had to stand out among thousands of other projects!

    OTOH, there are quite a number of items on Jakarta that would certainly NOT have attracted any attention at all without the Jakarta brand. (eg. some of the commons stuff.) This is not to say that theres anything wrong with them, merely that they owe their success mainly to placement. In addition, Jakarta hosts a number of virtually dead projects (and its quite difficult to tell the difference).

    Of course, none of this is meant as negativity toward Apache; there are a number of Apache products I use every day and others that I would certainly like to use. The standouts to me are:

    * log4j
    * Ant
    * Lucene
    * and Tapestry itself

    OTOH, the following projects are *not* hosted by Apache:

    * XDoclet
    * WebWork / XWork
    * dom4j
    * Hibernate

    Which of those is a more impressive list of projects? Its hard to say - about equal I think.
  13. SourceForge vs Jakarta[ Go to top ]

    It sounds like Jakarta needs to implement some sort of statistics on its projects like sf.net has. On sf.net, it is a great indicator to gauge projects that have traction versus those that never make it past the idea stage.

    In the case of Tapestry, it is Apache that owes a debt of gratitude to sf.net for providing the low barriers to entry for worthy ideas. sf.net appeals to early adopters and visionaries while Apache appeals to conservative late adopters. I hate using technologies that lose mindshare. It's also a better business decision and an easier sell to select an Apache project. And as such, Apache offers Tapestry a better business argument since a technical argument seems to only go so far with non-technical decision makers. But it was sf.net that provided the environment that allowed Tapestry to get started.

    Let&#8217;s not forget Jakarta&#8217;s blue-blood lineage. Crimson and Tomcat were Sun technologies. Log4j and Xerces were based on IBM technology. Struts is a half-child of Sun's that, in turn, spawned lots of commons projects. It is only Ant that grew out of the Tomcat project as a true child of Apache. These vendor projects were graciously contributed technologies that were instant defacto standards and flourished under a vendor neutral flag. Tapestry represents a new breed of project that won on popular merit rather than vendor channel.

    I&#8217;m a little taken back with the critical comments about sf.net. It is they who have graduated a superstar and should be proud of it.

    cheers
  14. SourceForge vs Jakarta[ Go to top ]

    It sounds like Jakarta needs to implement some sort of statistics on its projects like sf.net has. On sf.net, it is a great indicator to gauge projects that have traction versus those that never make it past the idea stage.


    I know I'd like that.

    >
    > In the case of Tapestry, it is Apache that owes a debt of gratitude to sf.net for providing the low barriers to entry for worthy ideas. sf.net appeals to early adopters and visionaries while Apache appeals to conservative late adopters. I hate using technologies that lose mindshare. It's also a better business decision and an easier sell to select an Apache project. And as such, Apache offers Tapestry a better business argument since a technical argument seems to only go so far with non-technical decision makers. But it was sf.net that provided the environment that allowed Tapestry to get started.

    > I&#8217;m a little taken back with the critical comments about sf.net. It is they who have graduated a superstar and should be proud of it.

    SF.net and Jakarta have different purposes. There have been discussions at Jakarta about having a lower-entry-cost incubator for new projects at Jakarta; they simply don't have the vast bandwidth of SF.net.

    There's absolutely nothing wrong with building a following at SF.net. I simply found that Tapestry was not gaining the necessary mindshare there, and at Jakarta it can compete on a level footing with the other big players such as Struts, Turbine, WebWork, etc. I do understand the need to market to the non-technical decision makers and that's a part. However, my cynicism about the move has been tempered by the intangibles that have come about since the move, the greater involvement of the other committers and the greater sense of team within Tapestry.

    I think Tapestry "suffered" at SF.net because the scope of a web application framework varies from implementation to implementation; Tapestry does so much that requires some study to understand or appreciate ... on a checklist (like a wafer.org) it doesn't stand out.

    Perhaps other categories (O/R mapping frameworks?) do work better in that kind of comparison.
  15. SourceForge vs Jakarta[ Go to top ]

    \Howard\
    There's absolutely nothing wrong with building a following at SF.net. I simply found that Tapestry was not gaining the necessary mindshare there, and at Jakarta it can compete on a level footing with the other big players such as Struts, Turbine, WebWork, etc. I do understand the need to market to the non-technical decision makers and that's a part. However, my cynicism about the move has been tempered by the intangibles that have come about since the move, the greater involvement of the other committers and the greater sense of team within Tapestry.
    \Howard\

    As a complete aside, it's been fairly widely observed that the most successful open source projects of all time have all been created by developers who were solving a problem they had for themselves. Growth happened because other developers not only recognized the problem was real, but the solution was applicable to them becuase the author(s) really were trying their damnedest to solve something real which was bugging them.

    With that in mind - hearing the phrases "mind share", "compete on a level footing", "big players", and "market to the non-technical decision makers" kind of freaks me out.

    If you have a problem, find no one else has solved it to your satisfaction, then you may find that solving it on your own (well!) and "publishing" it as open source will create a cult following of people with similar problems looking for a solution. And over time people will use the base to solve other problems of their own that are slighly different. And above all, the code will continue to grow in applicability and quality because it's melded inextricably with real problems that real people are trying to solve on real projects.

    But when you're talking about marketing and mind share and competition - it sounds like you're not trying to solve any problem, you're chasing phantoms. What is the need to "compete" with struts, or market the thing to non technical decision makers? I thought the point was to the thing work really well and solve your problems, and to branch out as other people used it solve theirs.

    IMHO the minute you go from thinking about solving real issues real people have to "competing", and to thinking about things like a feature's checklist, that the downward slide begins.

         -Mike
  16. SourceForge vs Jakarta[ Go to top ]

    But when you're talking about marketing and mind share and competition - it sounds like you're not trying to solve any problem, you're chasing phantoms. <


    As a technical director of a company that develops predominantly web applications, I can assure you, Tapestry solves very real problems and it solves them really well.

    But what is the point of a great tool if no one knows about it? If you know of something wonderful, wouldn't you want to tell the world? Wouldn't you feel anxious if people do not know about it?

    You are quite right that if the focus changes the way you've described, the product is bound to go off course. But this is not what is going on here at all -- one look at the mailing lists would quickly convince you of that.

    Best regards,
    -mb
  17. SourceForge vs Jakarta[ Go to top ]

    \Mind Bridge\
    You are quite right that if the focus changes the way you've described, the product is bound to go off course. But this is not what is going on here at all -- one look at the mailing lists would quickly convince you of that.
    \Mind Bridge\

    My comments weren't about the now - Tapestry seems quite popular with a number of people for excellent, um, non-marketing reasons.

    My concern was for the future.

    As for "....if no one knows about it" - it seemed quite well known on SourceForge. And perhaps moving to Jakarta will "help" it in some way, but I find it disturbing to hear marekting and competition and mindshares at this point in time. In my experience, when you start hearing those sorts of phrases, it's generally marks the end of an era.

        -Mike
  18. SourceForge vs Jakarta[ Go to top ]

    As for "....if no one knows about it" - it seemed quite well known on SourceForge. And perhaps moving to Jakarta will "help" it in some way, but I find it disturbing to hear marekting and competition and mindshares at this point in time. In my experience, when you start hearing those sorts of phrases, it's generally marks the end of an era.


    Well then, the end of this era started around January 2000 (when I first started coding Tapestry) and there is no end to the end in sight.
  19. Consulting for Tapestry[ Go to top ]

    Hi, does anyone know of consulting companies offering support for Tapestry yet?
    (Management might consider this a crucial point...).

    Does anyone have "statistics" how long it took consulting companies to support e.g. Struts once it became a Jakarta project?

    Thanks, Carsten
  20. Consulting for Tapestry[ Go to top ]

    It depends on what you mean by "providing consulting". Our company provides consulting for Tapestry, but not in the form of a "formal" support contract (like e.g. the Linux vendors do). So that would probably not qualify for convincing management. I'm also pretty sure that doing this would not be much of a business model - with Tapestry's rather low usage (sorry, but that's the case compared to something like Linux).

    On another issue: I believe that Tapestry is great, and from my perspective there is one simple reason why it's excellent that it is now a Jakarta project - I believe that Struts has gained its wide acceptance not because of technical merit, but because of its high visibility. Now Tapestry gets the same, and with this, the two frameworks will (hopefully) be compared and evaluated based on ease of use, productivity, design, and other *real* issues.

    Stefan
  21. SourceForge vs Jakarta[ Go to top ]

    As a complete aside, it's been fairly widely observed that the most successful open source projects of all time have all been created by developers who were solving a problem they had for themselves. Growth happened because other developers not only recognized the problem was real, but the solution was applicable to them becuase the author(s) really were trying their damnedest to solve something real which was bugging them.


    Tell me about it. A lot of people are complacent and believe in "pain on developers". They think, "Struts is hard, but everyone else is using it, so it must be as good as it gets."

    >
    > With that in mind - hearing the phrases "mind share", "compete on a level footing", "big players", and "market to the non-technical decision makers" kind of freaks me out.

    Sorry, but marketing is as big an issue as technology. I created Tapestry to use it ... but I come from a consulting background, where the client (alas) has a say in the technologies that are used ... because the project is going to extend past the consultant's involvement. Those types of managers are unwilling to take on a "radical" technology, even if it is a good one, for fear of not being able to maintain the project for its lifespan. Lots of people put Struts on their resume, only a few now put Tapestry (but we hope to change that!)

    Those same people are swayed by marketing concerns ... and perception-as-reality. If you lose the game, or even fall behind by too much, then all the effort is wasted. So from a marketing standpoint, lining up with Jakarta is important. As I said, additional benefits have been forthcoming within the project ... still tied up, even within the core Tapestry developers, with the cache and marketing potential of Jakarta.

    Open source is still an economy, but the currency is respect and mind share instead of dollars. You make investments and even occasionally mergers. You market your product and you take your dividends ... in my case, the chance to use Tapestry and see it used.

    And like any economy, competition is good! It guides us away from complacency, that's for sure.

    Of course, all this talk about marketing is just a necessary distraction from the core proficiency of Tapestry: the technology. Check out the history of Tapestry and see the problems it faces head on ... check out what people who are using it have to say or go look at the source code.
  22. Apache vs. Sourceforge[ Go to top ]

    Part of this is becase of the meritocracy at Apache and Jakarta.

    > >
    > > <sigh>
    > >
    > > This is really quite an absurd statement, Howard. If you compare sourceforge.net projects as a group with apache.org projects as a group, you are comparing a situation where anybody can put something up there to a situation where there is a filtering mechanism. So there is no need for any particular explanation of why an apache.org project is better quality on average than a random sf.net project.
    >
    > But we're not talking about random projects.

    Well, frankly, it's not clear what we're talking about. The ostensible topic of discussion, the title of this thread, "Apache vs. Sourceforge", is completely ludicrous. It amounts to comparing something where there is some filtering mechanism to something where there is no filtering mechanism at all. Anybody can set up a project on sf.net. To make any sort of comparison, and discuss the topic at all rigorously, you would at least have to qualify it by taking some subset of sf.net projects that have achieved some level of recognition, but nobody qualified the statement in any way, so this is really a kind of absurd, ersatz discussion.

    >We're talking about having the discipline to learn the Apache rules, to create proposals, to motivate people. Running an SF project is a cry in the wilderness ... it very easy to be dismissed because what you produce is not evaluated by your peers. Moving to Jakarta is a process of evaluation that it absent elsewhere. Jakarta is not an exclusive club, but you'd be hard pressed to find any dead wood there; the average Jakarta contributor has enough discipline to build a good product and work within a good process ... if not, they would not have become a contributor.

    Well, there you go again, Howard. Anybody can start a project on sf.net and commit code, whereas you have to go through some peer approval process to become a committer on an apache project. Therefore, obviously the average Jakarta contributor is of a higher standard than the average person involved in an sf.net project. But it could not possibly be otherwise. What you are saying is totally and utterly vacuous! The basic comparison you are making is absurd.

    >On SF.net, you can have individuals with very high standards (for instance, me) but there's no way to evaluate the horde of projects to find the good ones.

    And now, this statement, is, as far as I can tell,... utterly false. At least, in my own subjective experience, there is no particular difficulty in identifying the better projects on sourceforge. Well, at least for anybody who wasn't born yesterday. Now it is true that there are a horde of projects there. After all, anybody can start a project on sf.net, so you get a very large number that are started. But the vast majority simply never release any files and have an activity statistics of 0.0% and that's that. Other ones have some code you can download, but there is no documentation of any sort, and no real community activity. So there are very simple criteria which allow you to narrow down a short list of projects to evaluate in any given domain.

    Anyway, sf.net maintains some activity statistics and I don't know exactly how they're calculated, but there are statistics on projects' activity level and there are projects that are consistently in the 98th or 99th percentile -- such as jedit, or hibernate, or tapestry itself when it was on sf.net.

    But really, in my own experience, the whole idea that there is any particular difficulty in finding the more solid projects on sf.net is about 180º contrary to fact. And thus, the idea that Apache.org plays such an important role in the "ecosystem" by helping us poor disoriented masses identify the good projects does not at all ring true to me.

    >
    > > Well, I congratulate you on joining the club. You are doing well. I have noticed over the past couple of years that you have put a herculean effort into Tapestry. However, I am puzzled as to what "results" you are referring to above?
    > >
    > > Is Tapestry a better piece of software than it was before joining Jakarta?
    > >
    >
    > I've found that perception is reality. The cache of the Jakarta brand has motivated many in the Tapestry developer community to step forward and put new efforts in ... perhaps they feel that Tapestry is more of a going concern now, perhaps they want to extend their resume, ride Tapestry's coattails. New contributors have come on board and new mentors have appears in the mailing lists. It's a feedback cycle ... these contributions further enhance the perception of Tapestry and, by extension, Jakarta. That's not accidental, that's the system working.

    Well, that's kind of a self-fulfilling prophecy mechanism in action, it seems to me. I'd call it the "Wizard of Oz" phenomenon.

    >
    > Tapestry 3.0 (beta due shortly) is many times improvement over Tapestry 2.3, and 2.3 already kicked ass. How much of that is related to the move to Jakarta? Impossible to say, much of the work was done by me and would have occured, eventually, anyway. I can say that the increased vibrancy of the developer community has lead to improvements that may not have otherwise occured. The drive to use bytecode enhancement was led by Mind Bridge, not me. Line precise exception reporting was a challange (by, I believe, a Mr. Abraham?) Some of the new components (DatePicker, espcially) were contributed by people I hadn't heard of before the move to Jakarta. The move to Jakarta has energized the community and Tapestry is that much better for it.

    <sigh>

    You know, Howard, I am reluctant to pursue this discussion that much. I'm wary that people will brand me a heretic and start accusing me of bitterness and sour grapes and whatnot. OTOH, there is such an amount of logical fallacies in the air here, that I feel I should say certain things about this.

    Look, in the classic movie, the Wizard of Oz, Dorothy sets off on the yellow brick road to see the Wizard, accompanied by the lion, the scarecrow, and the tin man. Each one of them wants to see the wizard to request something different. The lion wants courage, the scarecrow wants brains, and the tin man wants a heart.

    Now, it becomes clear, in the course of the tale that the lion is actually quite brave in a crunch, the scarecrow can be very resourceful when necessary, and the tin man has plenty of heart. So, ultimately, the wizard gives each one what he already had.

    Now, it may be that if everybody believes in the wizard's magic, that there are beneficial side effects. The scarecrow suddenly is confident in his intelligence and other people begin to treat the scarecrow as intelligent because they know that the wizard gave him these great brains. So, the scarecrow gets some benefits even though the wizard did not really give him anything per se...

    But the fact remains that the lion already had courage, the scarecrow had brains, and the tin man already had a heart. And Tapestry was already a quality project with a good development process and an active community and so on, before it had anything to do with ASF.

    Now, okay, the scarecrow is grateful for his new brains, the lion for the courage that the wizard gives him, and so on.... and it is right and proper that you, Howard, should be grateful for this wonderful seal of approval that ASF has bestowed upon you. But, if we're going to talk about this at serious level, we have to recognize that ASF didn't bring anything real into the equation. AFAICS, it's basically a pure Wizard of Oz phenomenon.

    The wizard's magic may work, but only because people believe in it.

    Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    FreeMarker 2.3pre2 is out!
  23. Apache's project have historically been associated with quality code/work.
    Most of projects (if not all)under Apache are actively being developed unlike 100s of Sourceforge projects.

    So to answer your questsion: IMHO Apache project buy you Trust and Quality.
  24. OTOH, one could argue that in terms of an O/R mapper framework, Hibernate from Sourceforge is more advanced than Apaches OJB. Its not always black & white.
  25. Apache's project have historically been associated with quality code/work.

    > Most of projects (if not all)under Apache are actively being developed unlike 100s of Sourceforge projects.
    >
    > So to answer your questsion: IMHO Apache project buy you Trust and Quality.

    More than that. Apache is there to make sure that the projects can outlive their initial creators, by giving strength to the communities that will take care of it.

    So, a better answer would be: Apache projects buy you Trust and Quality you can depend on
  26. I like echo(http://nextapp.com) for complete java based web developpment
  27. Apache's project have historically been associated with quality code/work.

    > > Most of projects (if not all)under Apache are actively being developed unlike 100s of Sourceforge projects.

    Well, the comparison with SF projects is ludicrous. When you download the code from sf.net, there is no guarantee whatsoever -- not even that the code compiles! If you find something useful, it's useful and that's that.

    OTOH, there are some very high-profile projects hosted by sf.net, such as hibernate, jython, and jboss and so on, that really are as "tried-and-true" as anything from ASF.

    > >
    > > So to answer your questsion: IMHO Apache project buy you Trust and Quality.
    >
    > More than that. Apache is there to make sure that the projects can outlive their initial creators, by giving strength to the communities that will take care of it.

    Well, that's the theory, but I don't see what mechanisms are really in place to guarantee the continuity of the projects. Now, I grant that, typically, when ASF adopts a project, it has a fairly active community -- at least at that point in time. Thus, there is a better chance of persistence over time than something that is relatively inactive to start with. OTOH, I don't see what guarantee there is of continuity, since the developers can lose interest, just like with a non-apache project.

    IOw, the mere fact that an OSS project is hosted on apache.org infrastructure as opposed to sf.net infrastructure does not AFAICS guarantee a continued active development effort.

    As a case in point that I am quite familiar with, Velocity is a jakarta.apache project where all development has come to a complete stop. The main developers have not committed any code for at least a year. Meanwhile, people have posted bug-fix patches and feature requests, that simply get ignored. I don't know how many other apache.org projects are in a similar state. That is just one that I am quite familiar with.

    Quite frankly, I feel that there is a lot of mythology associated with ASF at this point and that there is a real gap between reality and perception.

    Jonathan Revusky
    --
    lead developer, FreeMarker project, http://freemarker.org/
    FreeMarker 2.3pre2 is out!
  28. Community[ Go to top ]

    As far as I know (I heard this statement at the JAX 2003: Java Apache XML Conference 2003 in Frankfurt, Germany from one of the Apache's co-founder) the most important part for Apache is the "community" itself and not the "quality" of the code. To become an Apache project you need to have a very active community. Only a very good quality of code doesn't count.

    So, the formula looks like this:
    Your Open Source software is perfect -> no bugs, everything is fine -> people just download and use it without complain -> no feedback, no discussion -> no community -> your Open Source project won't become an Apache project.

    In other words if you change the word "perfect" with "not perfect" and "no bugs" with "buggy" and calculate the formula again, you will find... Just kidding, guys ;-)

    But anyway the community is most important part for Apache project.

    Lofi Dewanto.
  29. Congratulations, all developers/those involved in Tapestry.
    Steve
  30. Congradutions Howard and all the Tapestry team members. :)
  31. Congratulations Howard and co. Tapestry is truly a great piece of work.
  32. Fan Mail ![ Go to top ]

    Howard,

    I just want to tell you what a fantastic product you've developed here - and tell a few others about it!!!

    I've used every other java based web framework out there and in my opinion Tapestry beats them all. As far as I'm concerned, the explosion of web applications over the last few years without a proper framework to build on took the software industry back 20 years in terms of developing reliable, robust and half reuseable systems. Just when most of us started clicking on to proper object oriented design principles, clients starts screaming for web apps, and the only tools out there to use are JSPs and templating engines - uuuurghhhhhh . I know people have differing opinions on this, but i just cannot handle using any non object oriented methodologies. My productivity goes down the toilet and code bug count goes through the roof when I can't design through inheritance. I've done procedural languages and do NOT want to go back - for business-app space projects anyway.

    Finally, in tapestry, i get it all back. In all of my designs I define a nested swag of classes that extend the Tapestry BasePage - is this page only viewable by a logged in user? can it only be viewed from an SSL connection, is it only viewable by a privileged user? Set up the navigation menu automatically? etc. I write it once, then build subpages extending these and get all of their base functionality without a second thought (how do you do that in JSP???). Struts can do some of that (subclassing actions), but it only goes half way. The tight binding between Tapestry page definition and implementation means most of your errors are caught at page build time when you first access the page, and error messages are descriptive enough to zero in on the problem immediately. Another great thing is that components hold state, so when you develop, you can just assume each user has their own unique page and their state follows them around just like in a regular local GUI app - no more hassle with manual form data / session management. The templating features such as RenderBody and RenderBlock allow me to build a whole complex app without any static markup replication whatsoever.

    And I can now build real full blown reusable OBJECTS that comprise java code, html markup and javascript and actually REUSE them (SHOCK! HORROR! - yes everybody, you heard me correctly) in other pages or projects. This itself is THE yardstick by which I have tried to measure EVERY other framework before tapestry - and I did not come remotely close with any other. To those who want to prove me wrong on this, please do - use your alternative framework to create an object as described above (java-html-javascript) on one page, then put ten of them on the same page, then export a jar file that fully describes the object and use it in another unrelated project without changing any code or resource associated with the jar file - just like putting a new JButton on a Swing form. I'm not trying to be smart here - if somebody can do it - i'd like to know how - I never could figure out how to do it in the web space before tapestry came along.

    Every new project I now develop is already half complete because of the vast chunks of common code I pull in from previous work, common library code, and increasingly, some of the third party components contributed to tapestry. I actually don't mind doing web apps so much anymore, whereas previously the thought of all the mind-numbing, repetitive, error-prone crap I had to do to get a web product out the door after completing the business logic (ahhhh - Hibernate!!!) just filled me with absolute dread.

    For those of you considering tapestry, it is a fairly radical departure from tradtional web apps. A tapestry app resembles a traditional app more than a web app (in my opinion) - which is why I like it so much. My time is spent refining the object model in the java code, where i get the full benefit of a type safe, object oriented language and development environment (Eclipse!). Those who come from a non-OO background will find the learning curve steepest.

    Anyway, thanks again Howard for such a great tool. Hopefully, now that Tapestry's got the Apache stamp of approval, it will become more well known and take a front row place next to the other A-list open source jakarta projects like tomcat, ant, log4j (the ones managers don't get so nervous about when they find out they're being used in a critcal app). It would be great if a thriving developer community started building up a huge library of contributed components that together would greatly benefit us all.

    Tapestry and Hibernate - a killer combination!
  33. Fan Mail ![ Go to top ]

    "Tapestry and Hibernate - a killer combination! "

    Try Tapestry and Cayenne - then you are as close to WebObjects as you can get (and save $699:)
  34. The company where I work has been developing enterprise applications with
    WebObjects 4.5 for the past three years. Now we're getting ready to
    switch to J2EE. That is, I convinced the company it's worth the
    effort to make the switch. It helped that all the new software we'll need
    is open-source. The zero cost got the "foot in the door", but since then
    I've kept pointing out how much better the quality will be... every time
    some weird bug or work-around pops up in our ancient platform. We'll be
    using Tapestry for our front-end development because it's the only J2EE
    framework I've found (so far) that supports reusable, customizable web
    _components_. That's a concept we've gotten very dependent on after three
    years with WebObjects.

    Anyway, I remember three years ago when about a dozen developers were
    learning WebObjects at the same time. We all thought that the learning
    curve was pretty steep, compared to other, mostly scripting-oriented
    approaches we knew. Usually it took a developer a few months to become
    useful and six to twelve months to become proficient. (Part of the problem
    was the limited amount of documentation available -- there wasn't a single
    WebObjects textbook at the time. I think Tapestry is already even or
    ahead on that score. I especially like the Component Reference... just
    imagine how useful it will be when the examples are brought up to date. :-)

    But in hindsight, I think the biggest problem was that the concepts were new
    to most developers. It takes time to get one's head around the
    idea of reusable components. (Plus eomodels and editing contexts in
    the WebObjects case.) A developer's first reaction was often that it was
    non-intuitive and too much work. "I have to create three files for each
    page?" "Do I have to jump through hoops for javascript to see my data?"

    _After_ getting through the learning curve, I saw the points.

    * Much greater productivity, for enterprise-sized apps anyway. I don't have
    a good story for why that is... except that the developer can spend most of
    the time working in a language/code mind-set. There's less need for
    context-switching to other issues like the web request/response loop or
    database commits or (shudder) scripting in the html.

    * The ability to keep all the logic in server-side code where your tools are
    available. You know, those helpful little things like production-strength debuggers and compilers.

    * The ability to reuse complex view components.

    On the last point... we developed some pretty fancy components: a
    BatchNavigator for paging large lists; a SwappingPopup for multiple
    synchronized selection lists; our standard navigation framework with header,
    footer, frames and menus (which we call the "donut" for some strange
    reason); a standard add/delete/save button-bar; a CollapsibleComponent that
    shows its content only when you click on its icon; automatic city/state
    lookup from zipcode; currency formatters; and spell-checking text fields.
    The point is that once such a component is developed, reuse is easy... just
    drop it in and specify the bindings. No (ugh) cut-and-paste... usually
    there'll be exactly one new line in the html template.

    I evaluated Struts first and couldn't imagine how I'd bring all those components over. Maybe by converting them to Velocity templates... that was going to be my next evaluation.

    After we developers became converts, we began grousing about what
    a pity it was that the WO platform hadn't been marketed and supported better.
    Why couldn't the unconverted see all those wonderful points? I think it's
    basically a hard thing to explain, especially to people who haven't had a lot of experience at building enterprise-sized apps. I've seen the Tapestry docs
    struggle to explain it and I get deja vu from three years ago.

    Case studies would be good, especially of converting an app from other
    approaches. Three years ago, when we converted the previous Active Server
    Pages app to WebObjects (because the old app wouldn't stay running for
    more than a few hours once it had more than a few users), we reduced the
    lines of code from 200K to 70K. There was a LOT of cut-and-pasted code
    embedded in the HTML. Eliminating all that made a huge difference in
    reliablity, performance and maintainability.


    P.S. Real men learned WebObjects when it cost $50,000. :-)
  35. "P.S. Real men learned WebObjects when it cost $50,000. :-) "

    Yes. And Objective-C.
  36. It seems to me that Struts is almost like a standard in the java world , loads of books , articles etc .Did a quick search on Tapestry on amazon and couldent find one book!!.Do you think this has a lot to do with struts been a Jakarta project ,with high visibility ?
  37. Struts - bit of a standard ?[ Go to top ]

    Howard is working on a book to be published by Manning sometime in the Fall.
  38. how about public reviews[ Go to top ]

    how about publicly revieuwing that book at tss like done with
    aspectj in action etc. I'd be really interested in that especially since tapestrys documentation seems rather outdated
  39. how about public reviews[ Go to top ]

    That's a great idea and its been mentioned before. I guess that's up to Manning.

    If readers here post a note showing interest in a public review, maybe Manning will take notice!
  40. vote[ Go to top ]

    +1 on the Tapestry book review ;-)
  41. Struts - bit of a standard ?[ Go to top ]

    Struts might be a standard and used by the masses but cannot be compared to the sophistication Tapestry offers. A Tapestry project is like working on some finely carved jewel, like bringing something to perfection. It makes you feel good. Good like "creative". Good like "artist". Struts projects are more like bringing in the big sledge hammer and hit on a bunch of rocks for 8 hours, then go home depressed, hoping only that some TV show is on that can cheer you up. Struts makes me feel bad. Bad like "Waste of time". Bad like "Waste of life".
    <P>
    Seeing Tapestry on Jakarta makes me happy. It gives it finally the visibility this framework deserves. And hopefully, through this it will not disappear from the landscape like WebObjects pretty much did (If Howard is the father of Tapestry, then WebObjects is its mother/grampaw :)
  42. Tapestry and WebObjects[ Go to top ]

    This difference is, this parent didn't reject his offspring. Apple could have OWNED what is now the J2EE markup, but since they couldn't do it with translucent plastic they let WOF go to the hounds.
  43. Tapestry and WebObjects[ Go to top ]

    Saying that WOF is "gone to the hounds" is ridiculous.

    WO 5.2 has such incredibly strong support for advanced application building with all the DirectToSomething technologies that you can't really compare it to something like Tapestry (which is great and certainly a good deal better than Struts or - yuck - JSP).

    So, building the use-case app "WebLog" mentioned before takes about a day and a half when you know what you are doing and leverage built-in technologies and the open source resources that are available. And you will get localization, validation, automatic error messages (in English,German and Japanese), auto layout and tons of other things for free.

    Anyone interested in what is available for WO might want to check out Project Wonder (http://wonder.sourceforge.net/) which offers about 250 components, Ognl bindings, localization, very advanced validation tools, a very cool reporting engine and a ton of other things. Oh, and there is a WebLog, too.

    It may be that WO has lost mindshare, but it by no means a "gone" technology. At least not for those that actually need to get some work done.
  44. Tapestry and WebObjects[ Go to top ]

    WebObjects was a great technology. NeXT developer tools were ahead of its time.
    However,

    Cayenne, Hibernate or TopLink can compete with EOF.
    Eclipse or Intellij are better IDEs than ProjectBuilder.
    Ant is more natural to java than make.
    Foundation is a proprietary and innecessary API (NSArray, NSDictionay, etc.).
    Instead of EOModeler you can use XDoclet, Middlegen, AndroMDA with a UML Tool to generate EOs (POJOs).
    Need to say more?

    I know WebObjects since version 1.0.
    We developed a big project using AppKit aka YellowBox aka Cocoa, WebObjects 4.5, EOF and of course Objective C.
    Then we migrated some of the web applications to version 5.

    Currently we developed an online banking solution including brokerage house services and WAP using Tapestry and Session Beans and integrated with Weblogic portal.
    I'm qualified to say that there is no project that I would choose WebObjects over Tapestry.

    Regards

    David
  45. Tapestry and WebObjects[ Go to top ]

    WebObjects was a great technology. NeXT developer tools were ahead of its time.

    > However,

    [comparisons]


    > I'm qualified to say that there is no project that I would choose WebObjects over Tapestry.


    I won't argue with that, to each his own. I merely wished to point out that this "WO is gone" claims simply are not true. I even agree with *some* of your points (especially the Ant and Eclipse part) but this does not mean that you can't use them with WO.

    And I'm also glad that Tapestry has such a strong following that it could become a jakarta project. This means there are enough people who recognize component-based development makes a lot of sense.

    But I'd also suggest you check out what you can to with the DirectToWeb technology, especially when used with Project Wonder - I gave a few presentations on them and people where pretty much blown away.

    They enable a very small team to create extremely large and complex solutions with tight timeframes.
  46. Tapestry and WebObjects[ Go to top ]

    I agree. WO is still alive mostly because is an internal tool at Apple.
     
    You are right. Ant and Eclipse can be used with WO. Objectstyle guys have a WO plugin for Eclipse.

    I already know Direct2Web.
    IMO it is great for kind of CRUD prototypes and data model driven applications, too rigid for other applications.

    I'll check the Wonder Project. I guess many of ideas and components could be migrated to Tapestry.
  47. Tapestry and WebObjects[ Go to top ]

    I already know Direct2Web.

    > IMO it is great for kind of CRUD prototypes and data model driven applications, too rigid for other applications.

    Now you may be assured that people where not blown away (as I claimed) because of a simple CRUD app:)

    > I'll check the Wonder Project. I guess many of ideas and components could be migrated to Tapestry.

    Be my guest:)
  48. Struts may have been a standard in the yesteryears, but to me its history now!!
  49. Struts - bit of a standard ?[ Go to top ]

    Struts projects are more like bringing in the big sledge hammer and hit on a bunch of rocks for 8 hours, then go home depressed, hoping only that some TV show is on that can cheer you up.

    LOL!!

    -- Andreas
  50. Great, YAUIF...[ Go to top ]

    ...or Yet Another User Interface Framework...

    So, now we've got Struts, Tapestry, Turbine and Velocity all under the "Jakarta Brand", in addition to the also rans Echo, JPublish, Expresso and a myriad of other frameworks. Plus, we've got JavaServerFaces coming along (with it's impending blending with Struts). What's a developer to do? How does one seperate the wheat from the chaff?

    As far as I can tell, the "Jakarta Brands" shake out like this (disclaimer: I'm a Struts user, so...):

       (1) Struts: has all the mind-share, yet leaves some wanting more;
       (2) Velocity: specifically for JSP haters;
       (3) Tapestry: the "pesky little brother", or the little dog nipping
                      at your heels. Has a fervent following (much like the
                      Mac, hence the Steve Jobs-like "insanely" adjective).
                      Leaves some wondering, "Why bother?";
       (4) Turbine: Many people know of it yet know little about it.

    What's really needed is an objective comparison of these technologies with any dogma or favoratism checked at the door. If Apache projects fall flat on their face, it's in the documentation department. And, not just in the area of 'how' but also in the 'why'. Everyone acknowledges the 'how' problem, but little is said of the 'why'. What motivated the developers of "Product X" to spend all that time developing it? What did they find lacking in other products that led them to develop their own (and not work within an existing project)? Why would one choose Product X over Product Y? What are the advantages of Product X, and more importantly, what are it's shortcomings over other tools?

    I know I would find this very useful.

    J
  51. Impossible Task[ Go to top ]

    What's really needed is an objective comparison of these technologies >with any dogma or favoratism checked at the door


    Where are you going to find this JMT (Java Mother Teresa)? To objectively compare the frameworks you need somebody who knows the problem space but has never used any of the frameworks? To know the problem space means that that person has used *some* framework and therefore is biased.

    The best I think you could get is to find a few people, who are willing to declare thier bias up front, review one, a couple, or all the frameworks mentioned. Still doesn't mean a single reviewer might trash another framework just 'cause its not Struts/JSP/Tapestry/etc. But, hopefully, a trend might appear across serveral reviewer's opinions. Then its up to you to interpret the results.
  52. Great, YAUIF...[ Go to top ]

    ...or Yet Another User Interface Framework...

    >
    > So, now we've got Struts, Tapestry, Turbine and Velocity all under the "Jakarta Brand", in addition to the also rans Echo, JPublish, Expresso and a myriad of other frameworks. Plus, we've got JavaServerFaces coming along (with it's impending blending with Struts). What's a developer to do? How does one seperate the wheat from the chaff?

    You're definitely mixing and matching here. Struts and Tapestry are general purpose, presentation-only frameworks. Turbine includes a significant presentation aspect but has an entire services framework for persistance, security, logging, and a bunch of other stuff.

    Expresso is a vertical framework; from what I know if it, it is more like Turbine but more tightly constrained and focused, and uses Struts for its front end.

    JSF is anyone's guess. The examples I've seen online (and in the EA3 download) were horrific. Lots and lots of code and JSP markup to get anything done. That's a separate rant.

    I understand that Echo is a strong Tapestry competitor with a different approach; I believe you don't get precise control over the HTML but the rest of the coding is more like Swing.

    Other frameworks, such as JPublish, are more problem-domain specific.

    >
    > As far as I can tell, the "Jakarta Brands" shake out like this (disclaimer: I'm a Struts user, so...):
    >
    >    (1) Struts: has all the mind-share, yet leaves some wanting more;
    >    (2) Velocity: specifically for JSP haters;
    >    (3) Tapestry: the "pesky little brother", or the little dog nipping
    >                   at your heels. Has a fervent following (much like the
    >                   Mac, hence the Steve Jobs-like "insanely" adjective).
    >                   Leaves some wondering, "Why bother?";

    Hey, somebody noticed "insanely".



    >    (4) Turbine: Many people know of it yet know little about it.
    >
    > What's really needed is an objective comparison of these technologies with any dogma or favoratism checked at the door. If Apache projects fall flat on their face, it's in the documentation department. And, not just in the area of 'how' but also in the 'why'. Everyone acknowledges the 'how' problem, but little is said of the 'why'. What motivated the developers of "Product X" to spend all that time developing it? What did they find lacking in other products that led them to develop their own (and not work within an existing project)? Why would one choose Product X over Product Y? What are the advantages of Product X, and more importantly, what are it's shortcomings over other tools?

    http://www.waferproject.org/index.html

    I contributed a Tapestry implementation of the example WebLog application, using an early version of Tapestry 3.0. I may go back and update it with the latest 3.0 features when I can catch my breath.


    Still, nothing is truly objective. Which is objectively better: an apple or an orange? How about a tweezer or a jack hammer? It's all situational.

    What are your objective measures? Most comparisons turn into a meaningless checklist. It's hard to objectively identify the most important features: developer productivity, ease of maintenance, overall "agility". I firmly belive that Tapestry scores very high (if not best-of-breed) in all these categories.

    The Jakarta brand is about separating the wheat from the chaff; Tapestry wouldn't have made it all the way to being a Jakarta project if it didn't have strong technology and a strong, committed (even "rabid") developer community.

    Comparisons of Tapestry to other frameworks are hard because of all the stuff
    you must unlearn. The book will help when its out, because it shows in just a few examples just exactly how fast and easy it is to assemble an application ... and just little you have to think about all that HTTP and Servlet API stuff. It's just objects, methods and properties.


    >
    > I know I would find this very useful.
    >
    > J

    And I just can't resist:

    Shut up, Big-booty, you coward! You are the weakest individual I ever know!

    http://us.imdb.com/Quotes?0086856
  53. Re: Great, YAUIF...[ Go to top ]

    Other frameworks, such as JPublish, are more problem-domain specific.


    Uh, what? JPublish is hardly domain specific0 It has the same type of features as other frameworks available (multiple template languages, actions, etc.) as well as some which are unique (virtual file system). Its also hardly an also-ran as another poster mentioned. JPublish 2.0 is currently in beta-testing and JPublish 3.0 is already in alpha and includes features such as an underlying virtual file system, integration with XWork, pluggable caching, etc. JPublish is used by several large organizations. In addition JPublish is the framework used in the Open For Business project with FreeMarker for the template language.</p>

    Look, we have many different frameworks available. All of the frameworks have merits and drawbacks. In the end using any framework will probably be better than using no framework. The framework you choose should be dependent on the way that you work. One poster said that their productivity decreases when they leave the OO space and so for them Tapestry is the answer. Other developers want to use the mainstream tools like Struts because their is a large pool of developers and development materials. Still others, such as myself, prefer an easy way to mix Java with scripting languages such as Jython or BeanShell for building our webapps so we use JPublish. I am happy to have the choice of different frameworks in the same way that I am happy to have different web servers, databases, application servers, etc.</p>

    I am happy for Howard and crew that they have successfully migrated to Apache. I wish them, and all framework developers, the best of luck.</p>
  54. JPublish[ Go to top ]

    Sorry about that; I remember you promoting JPublish as being more focused on publishing content.

    Side note: Tapestry 3.0 has limited integration with Jython (and other BSF supported languages) and that'll probably be extended further in 3.1.
  55. 3.0[ Go to top ]


    > Side note: Tapestry 3.0 has limited integration with Jython (and other BSF supported languages) and that'll probably be extended further in 3.1.

    Just one question, where can I find 3.0? sf.net only has 2.4.beta5 in download section.
  56. 3.0[ Go to top ]

    http://jakarta.apache.org/site/cvsindex.html
  57. 3.0-beta-1 soon[ Go to top ]

    Just doing some final touchups on 3.0-beta-1 ... probably have a release up within a day or so.
  58. Re: Great, YAUIF...[ Go to top ]

    Laugh-a while you can, monkey boy!


    PS ....That's Bigboo-tay....
  59. BB quote[ Go to top ]

    Yes, the IMDB quote isn't quite right.
  60. When will the book published by Manning be available and will it be covering version 3.0?
  61. Updated Docs[ Go to top ]

    Along the same lines ... any estimates on when the online docs will be updated?
  62. Working examples[ Go to top ]

    Hi Guys,
       I am new to Tapestry and today I downloded and starting working on it.
    At first glance it looks very powerfull framework.
    As a developer to feel what Tapestry is doing and what it can do we have to run examples and in those lines I tried to run WorkBench Application and encountered couple of problems. ( like javascript error and Popup link error).
    Will this be rectified when the framework is ready for beta distribution!!

    Howard, Keep up the good work, its truely a great work.

    thanks and Good luck
  63. Working examples[ Go to top ]

    alpha-5 had some teething problems. beta-1 is much more stable. A vote is in progress to release it ... could be this weekend.
  64. I had taken a 3 month sabbatical to write the book; I'm back at WebCT full time and not quite done with the book. Probably still be a bit before I finish it ... still expecting it to be in stores this fall, hopefully early fall.

    It covers 3.0 extensively; in fact, some 3.0 features were written in parallel with the book. That is, I would realise it is easier to make a change to the framework than to explain why you, the developer, have to do something awkward.

    After the beta, we have a few minor code touchups and the rest is the fill in the unit test suite, build under Maven, and finish the docs.
  65. I've never cared for most Java web UI frameworks. Tags that most wysiwyg editors don't recognize or creating custom tags, yuck. Although just learning about this Tapestry, I like how the UI can be edited using wysiwyg editors and the logic is cleanly separated. It reminds me of Enhydra's Barracuda framework now attempting to be revived at www.barracudamvc.org. Unlike Barracuda, I was able to download and deploy the Tapestry demos in JBoss within seconds.
  66. Oh my god! That means you actually read the Readme! That will not do ... I think I'll have to encrypt it. Can't have people actually reading the documentation ... we'll never be able to keep up the rate of positings on the mailing list that way.
  67. Such is life...[ Go to top ]

    I begun programing at the end of 80 when Microsoft loomed as the big brother standard it became latter, I've fall in love with OOP tantalizing mesage with Borland c++2.0, it took more than 10 years to became mainestream , and sudendly just when it did (thanks to java much more than to C++ ), http fall like a giant mess over everything, "desconstructing programing" would have been the name of the movie.
    Since middle 90 people has been in the search of the holy grail,everybody knows something's rooten in programing's kingdom,and IMHO the metaphore suits as in the former battle (OOP against procedural) the destiny was clear it was just a matter of endurance whereas now....like exhausted ghosts attempts are made one after the other....
    Scepticism rules, after 10 years , just do it, no matter how, fast and cheap that's the only requierement nothing lasts.
    Said that , I like tapestry they try hard at the impedance problem between http and any, let's say Object oriented model of the application being developed.Of course it is not yet the final answer...they might be never such an answer.
    Nevertheless long life and prosperity to the grial seekers!
    Very Good luck!
  68. Yes, Tapestry gets rid off the procedural work and the ugly plumbing required in the archaic web frameworks and lets the developer focus on objects, but in IMO, "COMPONENT"s is really the key to Tapestry. Everything here is a component including a page. Complex components can be built using simpler ones as building blocks. These components can be made generic by parameterizing them (even behaviour can be parameterized!). Also nothing is stopping one from passing a component as a parameter to another. A component thus built once can be used anywhere by just declaring it. The more I think about it the more amazing it is! Tapestry, I don't think needs good luck - it'll shine for what it is.
  69. Components v Objects[ Go to top ]

    Yes you are completly right, it's the component nature of tapestry wich make it fascinating, of course at the end components amount to objects.To me tapestry is to JSP developement what Delphi was to VB or the windows api, as you said components are the key, what amazes me is the amount of time it is still taking to shift from the rough http protocol to a higher level of abstraction, that was all. I just hope tapestry gets the general acknowledgement it deserves , I'm not so sure if it'll need some luck to get in to or not,but I hope you don't mislead my words If I desire best luck for it once again :-)
  70. Components v Objects[ Go to top ]

    Guess a little bit of luck wouldn't hurt! But I would like to humbly point out that a Tapestry component is not only objects but its associated template and specification. Cheers!
  71. aboutface[ Go to top ]

    Howard,

       It wasn't long ago you were being ignored (i.e. http://www.theserverside.com/home/thread.jsp?thread_id=13272&article_count=47)

    When your in good company it changes your odds.

    ;^)

    congrats
  72. I love it!!.

    I downloaded and tried, those of you who haven't tried it must do.... It is what I need!...

    I am impressed with the component-based framework, I am going to try it in my current project which luckily will start from June.

    I look forward to both the release of the book and the 3.0 beta

    Once again congratulations to HS and the team....
  73. Can someone compare the two?
  74. I've had a good hard look at JSF back when the EA3(?) was released:

    http://www.theserverside.com/home/thread.jsp?thread_id=15227#57692

    Here's a summary of thoughts on JSF. I don't want to spread any FUD on JSF (it doesn't need my help :-) ), so I'll try to avoid JSF particulars where my understanding is limited.

    JSF is code heavy (at least compared to Tapestry). You have to register a bunch of objects in the Servlet Context (various event listeners) to even get started.

    Tapestry is very code light. You can get a huge amount done, even simple applications, with little or no coding. This is because:
    - The servlet class is provided for you
    - Much functionality is simply provided by components
    - OGNL expression language is very, very powerful
    - You can express much more in templates and specs, without resorting to code

    At least as of EA3, it looked like all your JSF "components" filtered through a single method of a single listener object. How is that component-oriented? Perhaps they've fixed this since because it was horrifying to see ... think of an application with many pages, and think of the nested if-thens that would clutter this central class! This looks like a new anti-pattern, "Magic Listener" (and "Bitter JSF") in the making. Of coure, you would home brew some smarter dispatch mechanism, but ...

    Tapestry is designed from the ground up for components (that have behavior and state independent of their containing page), and for pages to be independant of the containing application. Tapestry's component object model allows the framework to do all the dispatching, not some central "Magic Listener". Each Tapestry page is like a mini-application unto itself.

    JSF has an add component naming; as the developer, when forms are involved, you are responsible for naming your JSF "components" to reflect how they are enclosed. So you might name your form element "form" and your text field element "form/userName". Note: this may have changed, based on the tutorial at http://java.sun.com/j2ee/javaserverfaces/docs/Using4.html#1011998.

    It is not clear to me how JSF handles loops and conditionals inside forms.

    In Tapestry, you often don't have to provide an id for your components (Tapestry assigns a unique id for you). Tapestry handles both simple forms and complex forms (forms with loops and conditionals) equally well, using the same mechanism.

    Tapestry has phenominal support for client-side JavaScript built in. It has a specialized markup language and related classes just for creating custom JavaScript from a template, and differntiates between "ordinary' JavaScript, and JavaScript for initialization (executed from the window.onload event hander). The Tapestry rendering model allows all this JavaScript to be collected into a single block, just inside the <body> tag.

    JSF emits long "javascript:" attributes, which is as much as it can do.

    Tapestry templates are still valid HTML. I've found that when using Struts and a lot of localization, the JSP becomes very, very cryptic ... it is very hard to relate incorrect HTML in the application back to where that HTML was produced in the JSP.

    Tapestry HTML templates are designed to be viewable in a WYSWIWYG editor. It includes provisions for including things in the template that will be discarded at runtime, just so you can see what they look like in your editor ... things like extra rows on tables, non-localized text that will be replaced with localized, etc.

    Tapestry extensions to HTML are:
    - The addition of the "jwcid" attribute to mark some tags as elements
    - The requirement that component tags be balances (even <img> or <input>)
    - Special syntax in some attribute to indicate that they are OGNL expressions, or localized messages

    In other words, Tapestry "hides in plain sight", so that your Java developers and HTML developers can work together, not at odds.

    A few other notes on Tapestry (don't know how JSF compares):

    Tapestry can localized images and stylesheets, not just text. You provide alternate versions and Tapestry chooses the one appropriate to the user's selected locale.

    Tapestry applications can run in a stateless mode until there is a need for server-side state.

    Tapestry has an advanced concept of a component library that can package components, pages, services, and even assets (images, stylesheets, etc.) inside a JAR. Drop it in and run ... Tapestry takes care of exposing those assets (through the Tapestry servlet, or by copying the files out onto a web-folder-mapped directory).

    Tapestry has a suite of WML components, in addition to the standard HTML component.

    Tapestry can support multi Tapestry applications in a single WAR.

    Tapestry has the best exception reporting of any web framework I'm aware of. An uncaught exception results in a formatted Exception page with:
    - The complete stack of nested exceptions, top to bottom
    - The name and message of each exception
    - The name and value of each property of the exception
    - The stack trace of the deepest exception
    - A complete rundown of the runtime environment:
    - HttpRequest headers, attributes, parameters
    - HttpSession properties and attributes
    - ServletContext properties and attributes
    - All JVM system properties

    In addition, most Tapestry exceptions are "tagged" with the location of their source. This is the file and line for the source of the runtime object. This is "line precise errror reporting", it means that when you hit a runtime error, Tapestry tells you where to go to fix the error.

    Summary of Tapestry vs. JSF

    Tapestry is code-light, very extensible, very developer friendly at many levels. It was largely designed by one person over a period of years and shaped by field experience and developer feedback. Tapestry has met every challenge put upon it ... it is "strong like the oak, yet flexible as bamboo".

    JSF is code heavy and built on shakey foundations (JSPs). It is an unknown quantity, designed by a committee. It is to be released fait acompli when they feel it is ready, with no proof that it is capable of anything more complex than a (pretty uninspiring) demo.
  75. Tapestry Release[ Go to top ]

    Hello Howard,
          Any release date for 3.0beta1 finalised.
    In our company we are planning to evaluate Tapestry framework as we all think it is true Object Oriented and powerfull framework. But the amount of enhancement gone / implemented in 3.0 beta1 compared to 2.4 alpha 5 are huge and we think it is better we go straight to 3.0 ? When do you think we can download 3.0beta1. We also tried getting latest from CVS but we found that there is some break in the DTD and etc..,
  76. Tapestry Release[ Go to top ]

    3.0 is in progress. This will be the first release of Tapestry to be distributed via the Apache mirrors, rather than on SF, so its taking a bit to set everything up.

    Yes, there was a last minute change to a few things, especially the DTD, between 2.4-alpha-5 and 3.0-beta-1. You'll only see it if you are using localization features.

    Perhaps you are referring to the DTD systemId URLs not pointing to actual files? Remember that the systemId doesn't have to point to a real file, "ownership" of the URL is enough ... but with the ascendency of Tapestry we can now put the DTD files in the matching locations.
  77. Tapestry 3.0-beta-1 has been released.

    http://jakarta.apache.org/tapestry

    It is distributed via the standard Apache mirrors ... it may be a bit before it is widely available except from apache.org itself.
  78. Congratulations![ Go to top ]

    I picked Tapestry 12 months ago for our web application (and it is more 'application' than 'web site'), and have not regretted it. We have a team of 7 developers, of varying levels of experience using Tapestry, and they have all become productive using it.

    The bad thing is that every second J2EE job ad I see say 'struts', and while I can do struts I *really* don't want to! Now I can suggest -- let's use Tapestry, yes, it's from Jakarta too, just a bit different... ;-)

    Tom
  79. I used many technics (JSP, Servlets and XML/XSLT, frameworks ), and one question I permanently ask is:

    What about good, simple, and easy reuse and code writing for UI?

    a. In JSP, imports cause problems. I can't enougth customize them, because imports directly placed in class body. Tags not enougth.
    b. In XSL/XSLT, templates very quickly become overcomplicated with parameters
    c. Struts actions not do anything fo reuse HTML
    d. Cacoon more about pipeline processing.
    e. Velocity have another language, that looks as ugly as JSP

    And only in Tapestry I get right view on reuse, that same as OOP:

    1. Case Tapestry Components are Java classes, you can do many OOP things with them.
    2. The only way of customize something is parameters. Parameters in XSL templates is UGLY and non maintainable. Tapestry do 90% of this. You can get parameters from parent component (It shouldn't be exact type). You can get parameters from any other declared bean. You can access Visit object, that can have access point to all application. So, this is 50% why I love tapestry.
    2a. These parameters are in special places (XML) and looks very natural.
    3. HTML still look very very VERY good. Very easy, very natural.
    4. UI component hierarchy are very closed to source HTML.

    Uffff....., finish here.

    It need to work with Tapestry to understand what is it.