The basic question is, "do we want to make it easier for new developers to switch from Struts/JSP to Tapestry?".
I think the answer is yes. More users is more acceptance is more likely to use Tapestry on your next consulting engagement. The RAD concept I'm floating is basically saying "Tapestry is like JSP, but much more natural. You can start with ordinary looking HTML built like a normal JSP, and expand up from there." Outside of NeXT and IB, I don't know anyone who has created a good component-based WYSIWYG component editor. Tapestry is trying to let ordinary HomeSite and the like be the WYSIWYG editor. So we have a tradeoff; beginning users put more cruft in the HTML, but it still is valid HTML (with extra arguments) ... it's not HTML + JSP Directives + XML-like tag library references + includes. I don't like having two paradigms in Tapestry, and this RAD paradigm is not nearly as capable as the exiting paradigm. I especially don't like the fact that the attributes are treated like OGNL expressions (for anonymous components) and are treated like static bindings (for informal parameters on a traditional component). But if we can get people to sit down and get something working in Tapestry in an hour, then everyone wins. Again, will it be abused? Yes. Will some people get confused about what Tapestry really is? Yes (but they would probably not know about it or understand it anyway). Is it a lot of work? No. The idea is growing on me. I'm not in 100% agreement with Marc; he is confused and thinks that this simplification is what most people should use whereas I see it as a bait-and-switch to ease initial adoption, and get users hooked when they leave the RAD part behind. -- [EMAIL PROTECTED] http://tapestry.sf.net > > On Thursday, Oct 10, 2002, at 18:07 Europe/Zurich, Adam Greene wrote: > > > In regards to Tapestry RAD being able to load *.html and wrap it with a > > generic specification. What about adding a : > > All this sounds "interesting", but would most likely turn into an > exercise in futility. > > If you want to provide true RAD functionality in Tapestry it has > nothing to do with the underlying framework. Instead, the only obvious > choice would be to provide something akin to NeXT's InterfaceBuilder > for the web: wysiwyg "drawing" of the UI. And don't even waste your > time mentioning WOBuilder: it's a utter failure, not even remotely > close to IB. Also, something like IB implies two things: a set of > useful, generic components to get started. And a plug-in API ala > IBPalette to allow third party to provide their pre-build components. > With such a tool there is no need to handle any html template or > description files: the tool takes care of them. Your only "worry" is to > provide an (optional) implementation. > > Such a tool, coupled with a "rapid turn around mode", would go a long > way to provide RAD capacities: draw & run. Nothing much to it. > > Cheers, > > PA. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry-developer ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
