In fact I'm currently working with someone who did a lot of early contributions to Echo a long long time ago, when it was still known that it was based off of its smalltalk counterpart.
I do have some disagreements with the swing model, but it only applies to layout managers and such. IE wtf is the html for if not to help layout our stuff? There are some other things that would be nice to take from it. But you are right Mark. There are a lot of things that are nice about it, and whether tapestry knows it or not it is already kind of there ;) It was a good idea (besides the part about html, which is the same reason I don't like wicket) , so we'll soon see what is possible :) jesse On 12/1/05, Mark Stang <[EMAIL PROTECTED]> wrote: > > If you want to see another: > > In fact I think the internals of tapestry look more like swing code than > any other web framework I've seen thus far, and if you've ever done a lot of > swing (rendering with Graphics) objects you'll know what I'm talking about. > > Take a look at Echo: > > The Echo2 Web Framework is the next-generation of Echo, a platform for > developing web-based applications that approach the capabilities of rich > clients. The 2.0 version holds true to the core concepts of Echo while > providing dramatic performance, capability, and user-experience enhancements > made possible by its new Ajax-based rendering engine. Echo is an open-source > product, licensed under the Mozilla Public License (also available under the > LGPL), which makes royalty-free development of both commercial and > open-source products possible. > > http://www.nextapp.com/products/ > > Echo is where we want to go. I proposed it here and it was shot down due > to the need for developers to understand Swing. > > regards, > > Mark > > -----Original Message----- > From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] > Sent: Thu 12/1/2005 1:31 PM > To: Tapestry users > Subject: Re: daydreaming of tapetry and ajax > > I think the tacos4 approach has changed from 3.0.3 in kind of an apples > and > oranges sort of way. The things you mentioned are being addressed: > > -) The only area in tacos that requires people to acknowledge javascript > code is the ProgressBar. > > -) All exceptions, client-side AND server side are being handled in a very > transparent and easy way in tacos. Any server exception will pop open a > FloatingPane with all of the gory details. > > -) The debug console makes debugging what's going on as easy as debugging > anything else in java. The javascript framework that we're using, dojo, > has > a built-in logging backbone similar to log4j in the way that it let's you > control things. The debug console utilizes this to provide a > FloatingWindow > (hideable or showable, also supports clearing log entries/color coded log > message types, etc..) that makes this much much easier to work with. > > I don't agree with completely about Tapestry only being able to support > the > concept of pages. I think the portlet code is a very good example. > In fact > I think the internals of tapestry look more like swing code than any other > web framework I've seen thus far, and if you've ever done a lot of swing > (rendering with Graphics) objects you'll know what I'm talking about. This > is the largest part that I would like to focus on with tapestry. It > already > supports direct renders of "areas", save for one tiny little part, which > are > Loops. This is already being addressed so I'm fairly confident we'll be > seeing some very impressive new functionality soon-ish. > > My last and final point would be that a very large and driving goal behind > tacos has been to eliminate the need for anyone to understand what any > javascript has been doing on the page, as well as what's involved in most > of > the process. I think what's sitting in cvs head for tacos4 right now does > a > pretty good job of doing that. > > The other part(ok so one more point) that gives me a great deal of > confidence is that tacos has tried, in every circumstance to defer all > javascript to the http://dojotoolkit.org javascript library. That makes > our > risk of introducing bugs/ability to quickly move forward much easier than > lots of custom javascript. > > It's also funny that you mentioned some of the big names around who has > been > working with ajax. I think everyone would be very surprised/relieved to > learn just who exactly is using the library(dojo) as well as who actively > develops it's contents. I can't say(or even know) all the players > involved, > but if anyone is familiar with Flickr, one of the original pioneers of the > whole "web 2.0" style of doing things (ajax included) you'd be happy to > know > that one of their lead developers is also an active contributor to that > library. Basically, dojo has an intensely > dedicated/knowledgeable/experienced set of industry leaders driving it's > development, which I personally think makes it the best choice > around...I'm > just happy that tacos has been able to bridge the two worlds somewhat. > > jesse > On 12/1/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > > > > I really want to like AJAX as a more general case solution, but > > I'm > > with Konstantin on this one. It's got a *whole lot* of loosely coupled > > moving parts that all have to work together seamlessly in order to > produce > > the desired output. > > > > Framework tools like Tacos or DWR help by hiding a lot of the > > moving > > parts, but they also restrict what you're doing to those things the > > framework designers had in mind. For the 99% use case, this is where the > > tools are going to have to evolve if normal humans are going to work > with > > them. Trying to build an AJAX app from the ground up where you're > writing > > both the javascript and the server side code is buying a world of pain > as: > > > > 1) You've got to write in two different languages. > > 2) One of the languages (the javascript) has poor debugging > > capabilities (the best I've found yet is the venkman debugger an it's > > still > > flakey). > > 3) Any change you make has to be done in both places. > > 4) The underlying transport layer (XML over HTTP) has no error > > handling at all except for wire errors so if, for example, your server > > dumps, your client has no clue and it'll just sit there unless you code > > in, > > say, a heartbeat timer, etc. > > > > The whole point is that "raw" AJAX, imho at least, is *way*, > *way* > > too complicated to be productive. It took a whole *host* of developers > at > > Google, what, two years to get google maps working? And it has all of > *one > > screen* :). Which means a component based architecture (where an ajax > > expert > > can build a reusable piece of code), is a much better approach. > > > > The one concern with this approach I have vis-à-vis tapestry is > > that > > AJAX is all about taking little "nibbles" out of a page e.g. I want to > > submit just *part* of a form, or I want to replace "click here to > search" > > with an actual search form that comes up from the server. > > > > Tapestry though, is architected around the concept of whole page > > rendering. One can't guarantee that a component will render properly > > outside > > of the context of its page. Which means, even if I only want to refresh > > 1/100th of a page, I still need to render the whole thing on the server, > > trim out the part I want to refresh, and push that back to the client. > So > > I > > cut down on my wire traffic, and I save the user a page load, *but* the > > server is still building a full page. > > > > Maybe the Tacos lads have found some clever ways to mitigate > this > > in > > the newer libraries, but last time I checked (the 3.0.3 libraries), I > > didn't > > see an easy alterative to this approach. > > > > --- Pat > > > > > -----Original Message----- > > > From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, December 01, 2005 11:43 AM > > > To: Tapestry users > > > Subject: Re: daydreaming of tapetry and ajax > > > > > > Neither do I. > > > Ajax has it place, but it is relatively small IMO and > > > Ajax is not good in many cases even seems like good > > > choice. > > > > > > > > > --- Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > > > > http://www.w3.org/2006/webapi/ > > > > > > > > I don't think ajax is going away anytime soon ;) > > > > > > > > On 12/1/05, Konstantin Ignatyev > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I think you and many AJAX fans need a cold shower > > > > :) > > > > > > > > > > > > > > > > > http://www.theserverside.com/news/thread.tss?thread_id=37106#187945 > > > > > > > > > > > > > > > --- Dan Adams <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Excuse my daydreaming for a minute here. I know > > > > that > > > > > > same ajax > > > > > > components exist (and I have not yet personally > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > >
