on 4/27/00 6:47 AM, Ship, Howard <[EMAIL PROTECTED]> wrote:
> 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>
Ok...another "html'ish language" for the Html designer to learn. This isn't
horrible, but I personally wouldn't like it.
> 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.
WRONG!
<form action="$link.setAction(/servlet/accept-form)">
That builds up the link for you. I know this is acceptable to designers
because I have seen this tested at Clear Ink and at Collab.Net on at least 4
different very complex web applications with a number of people working on
them.
> 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.
That is why we provide that information for you in Turbine with a
ParameterParsers class. It makes getting the GET/POST/PATH_INFO data
trivial.
You are supposed to be comparing your system to Turbine, not to "ordinary"
systems. :-)
> The developer is also
> responsible for naming the form elements.
This really doesn't matter because a lot of the times, the system is spec'd
out by the engineer so that the designer already knows the form names ahead
of time.
> 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>
Ok. I understand how you are doing this. It is an interesting idea and I can
see how to implement this within Webmacro/Turbine very easily. You use the
WM context to pre-stuff this object into there. The designer simply has to
do a $actionLink to get it out. Even less typing. :-) You might argue that
the developer has to first create the $actionLink and stuff it into the
context, but that is the same as you requiring the developer to create the
listener. Also, what if you have 50 links on the page. Do you have to create
50 listener objects? I don't see that as being very efficient for the
engineer.
> 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.
Again, I don't understand how this is very much different than stuffing
something into the WM context.
> However, since environment here is very negative towards Tapestry it looks
I wouldn't call it negative. Just because we didn't jump up and openly honor
your project within our system doesn't mean that we were negative to you. It
simply means that we feel that your project is re-inventing the wheel or
isn't necessarily a good idea. That isn't a bad thing, it just means that we
aren't as interested in it as you want us to be. :-)
> like I'll be putting it up as SourceForge after our internal review next
> week.
I guess that no one else offered to team with you eh? :-( I know you were
shopping it around to a lot of different people.
What license are you going to put on it? That will make a HUGE difference
about whether we work together or not. For instance, if you go with a GPL
license, I personally won't talk to you because we can't work with GPL here
due to the viral nature of it. :-)
> Once the dust has cleared, we can see about how Turbine and Tapestry
> can work together.
That I would personally like to see. I actually could see Turbine calling
your template engine directly as a service. That would be nice because I
could say that Turbine directly supports 6 different methodologies (Cocoon,
ECS, Webmacro, FreeMarker, JSP (still in development), and yours). :-)
Good luck with your project.
-jon
--
Scarab -
Java Servlet Based - Open Source
Bug/Issue Tracking System
<http://scarab.tigris.org/>
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
