----- Original Message -----
From: "Dru Nelson" <[EMAIL PROTECTED]>
To: "Howard M. Lewis Ship" <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 2:34 AM
Subject: Re: [jetty-discuss] The quickest edit->run cycle with Jetty?
Jetty with Tapestry.
>
> I just finished reading up on your framework. Wow, quite a system.
> I've seen attempts at building systems like this a long time ago
> in my early WebObjects days.
A lot of developers are moving from WOF to Tapestry.
>
> very interesting. I come from a background of many different technologies.
> I'm kind of new to the Java web-app space. I'm very performance
> oriented and don't believe most of the hype. (i.e. J2EE beans, RMI,
> blah blah) So, I've usually used other technologies for web backends.
This is not the solution for absolute performance, though performance is
very
comparable to Model2 or Struts, even though Tapestry is doing far, far more.
I normally say that the presentation layer is not the bottleneck (though
some Tapestry users
have been doing some profiling and finding a couple of hotspots in Tapestry,
mostly related to char-to-byte conversions).
The way Tapestry is constructed helps to ensure that if your application is
working in development, then
it will work properly in a clustered environment. Of course, that just
applies to the presentation layer, there's
still plenty of rope to hang yourself with elsewhere.
>
> However, I'm very interested in programmer productivity.
Tapestry is pretty much unmatched there. Even when the project
first started, three years ago, my concern was to support the developer
first.
This philosophy really seems to have taken root and worked.
Since then, the majority of the work has been to trade runtime processing
expense against
build time developer expense. For example, in Tapestry 1.0, listeners (the
code that gets
executed when a link is clicked, or a form submitted) had to be instances of
a particular
interface, and were normally implemented as inner classes. So you would
have, say, 10 lines of code
surrounding one line of actual business logic ... the accessor method, all
the syntax for the inner class, etc.
Then came listener methods, where you simply define a public method with the
right signature. Tapestry
uses reflection to analyze your class and uses reflection again to invoke
your method. A little slower are run time, but
tons less code.
Now, in 2.4, you can do listener methods in BSF-supported scripting
languages. Much slower, of course, but it supports
a more RAD-style. You can always switch scripting code back into Java code
at any time, the components don't care.
Check out the Workbench demo and tryout the exception page. I've had
some developers say that the exception reporting built into Tapestry is a
reason to swich, just by itself.
>
> >
> > Changes to my workspace files are immediately visible to Tapestry and/or
> > Jetty.
>
> How do you deal with new server classes? I read your FAQ.
> Are you just data driven off of the XML files 'specifications' and
> templates? There must be a place for some code?
> If so, how do you deal with those changes.
Those can require a restart of Jetty ... which is lightening quick. Or, you
can run your app inside Eclipse (or whatever IDE you use) with JDK 1.4 and
rely
on hotswap.
>
>
>
> Mind if I throw in a quick possible FAQ question at you?
>
> How do designers deal with the "I can't see the whole page" problem
> that a web designer might use for a site. According to your talk,
> Tapestry would have to control the entire render process. Some
> templates will be in components. Therefore the designer would have
> to be a little smarter to change things. (ie. instead of editing
> header.template, its find header component (or masthead) and change
> that.
The way Tapestry tags work is designed to be non-intrusive to WYSIWYG
editors. So your HTML
guys may create a template that includes:
Your current balance: $5.00
The Java guys will instrument this, using a Tapestry component to provide
the value, say something like
(and this is using the 2.4 syntax):
Your current balance: <span jwcid="@Insert"
value="[[ account.balance ]]"
format="[[ balanceFormat ]]"
class='[[ account.balance <= 0 ? "negative-balance" : null ]]'>$
5.00</span>
The WYSIWYG editor ignores the <span> tag (it might hickup at the odd
attribute names and values). If that is too scary to put in your HTML
template, you could instead do:
Your current balance: <span jwcid="insertBalance">$ 5.00</span>
And put the rest, in a somewhat different format, inside the page
specification.
At runtime, you might get:
Your current balance: $2032.22
Or:
Your current balance: <span class="negative-balance">$ -18.22</span>
Tapestry knows which components render their body and which don't. It
simply discards the contents of components, such as Insert, that can't
contain a body.
Once you trained the HTML guys to be careful when they see the odd stuff,
both HTML and Java guys can work on the same templates.
There are some limitations to this; if you make heavy use of custom
components in your application, then you may lose the ability to preview
effectively, buty most of the feedback I've gotten is that the Tapestry
approach is the only one that comes close to working in the real world.
>
>
>
> One more... :-)
>
> Since there is a lot of XML, what do you use to get around that
> verbosity. Those specifications would require a lot of typing.
As you can see, in 2.4 you can put a lot into the HTML template and the page
(or component) specification is minimized. Tends to be less typing, fewer
open files in your editor.
For 2.3, there's a plugin for Eclipse called Spindle. It will be a while
before Geoff (the author) can get it updated for 2.4, however ... the
differences between 2.3 and 2.4 are quite extensive.
----
Howard Lewis Ship
[EMAIL PROTECTED]
http://tapestry.sf.net
-------------------------------------------------------
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