Not very far at all :) Most of the impl has already been done, it will need to be completely re-done the new way, but that's just monkeys typing on a keyboard.
The design is all sitting up in my head. I just need subversion access and a reasonable plan/ok from the general community and we're off :) On 12/1/05, Dan Adams <[EMAIL PROTECTED]> wrote: > > very rough estimate, how far do you think tacos and tapestry are from > this kind of thing? what are the major limitations blocking it? > > On Thu, 2005-12-01 at 15:31 -0500, Jesse Kuhnert wrote: > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
