On simple substitutions, the <jwc> element introduced by Tapestry is just as
awkward as any other system. One of my design goals for Tapestry was a
minimal "hit" on HTML syntax and I realized I could achieve all my goals by
creating a fake "<jwc>" element.
Tapestry differentiates itself at the next level up, by leveraging its
component object model to take over the the mechanical tasks of defining
URLs and the like.
Example, using ordinary HTML:
<form method=post action="/servlet/accept-form">
<input type=text width=20 name=nameField>
<input type=submit value="Go!">
</form>
In Tapestry, you would use components:
<jwc id="form">
<jwc id="inputName"/>
<input type=submit value="Go!">
</jwc>
>From what I've seen of Turbine, the Screen code would have to figure out all
the URLs that will be needed, ahead of time; then invoke the renderring
engine (FreeMarker, WebMacro, etc.) passing this information in an
engine-specific way.
With ordinary servlets or JSPs, the developer must write and configure an
entire servlet to parse the form parameters, move data from the parameters
to business objects and do all the other work. The developer is also
responsible for naming the form elements.
With Tapestry, you use the form components, and create bindings to move the
data between the components and the business objects. You define an inner
class as a listener object for the form that receives control after all the
form components have done their thing. The URLs, names of form elements and
all that logic is provided by Tapestry.
Likewise, instead of
<a href="/servlet/do-some-action">a link</a>
You use a Tapestry component:
<jwc id="actionLink">a link</jwc>
Again, Tapestry takes care of the URL. You supply another listener that
receives control when the link is triggered. Regardless of how many pages
are in an application, or how many actions and forms are contained in the
pages of an application, an application will always use exactly one servlet.
However, since environment here is very negative towards Tapestry it looks
like I'll be putting it up as SourceForge after our internal review next
week. Once the dust has cleared, we can see about how Turbine and Tapestry
can work together.
> ----------------------------------------------------------------------
>
> Subject: Re: Update: Tapestry -- Possible
> contributiontotheJava Apacheproj ect
> From: "Justin Wells" <[EMAIL PROTECTED]>
> Date: Wed, 26 Apr 2000 13:12:39 -0400
>
>
> Quoting Nic Ferrier ([EMAIL PROTECTED]):
>
> > I'm wih Jon most of the way here... to be honest I can't see much
> > difference between:
> >
> > $substitution
> >
> > or
> >
> > <substitution/>
>
> Do you see a difference here:
>
> <a href="$substitution">$substitution</a>
>
> versus
>
> <a href="<substitution/>"><substitution/></a>
>
> Your only option really if you want to do it in an XML
> friendly way is
> to define it as an entity, and write this:
>
> <a href="&substitution;">&substitution;</a>
>
> but if you try and use an XML parser alone to catch this
> stuff, it does
> become problematic. For example
>
> <option name="hello" value="world" &selected;>
>
> versus
>
> <option name="hello" value="world" $selected>
>
> While you can solve these problems in many cases, you
> eventually wind up
> with a big headache at some point.
>
> However, if it's really important to you, you can plug and play with
> WebMacro's parser. It's not integral to the application, and can be
> replaced with an XML parser if you like with probably less than 500
> lines of code.
>
> Justin
>
>
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
