on 4/16/00 6:36 AM, Ship, Howard <[EMAIL PROTECTED]> wrote:
> I would vastly prefer to simply release Tapestry as Open Source right now
> (okay, after I get back from vacation). The way things are going right now,
> we'll be doing an internal review of it at Primix first ... we may be using
> it for some upcoming engagements. I developed it on company time and am
> trailblazing the whole concept of open source within Primix.
Great! When I was at Clear Ink, I was doing the same thing for the last 5
years. :-)
> Somehow when I was researching similar projects before I started on Tapestry
> I missed Turbine.
I find that funny considering that you have a reference to Jason Hunters
page and it mentions Turbine quite a few times in the reactions.
> They do share a number of things in common. I need to do
> more research as a good comparison. Although you've pointed out specific
> things Turbine will do that Tapestry doesn't, that's just a matter of
> creating the necessary components.
I read that as "that's just a matter of re-inventing the wheel"...:-)
> Tapestry is not an XML based markup language. Tapestry is a web application
> framework. Component templates are HTML or HTML snippets. Tapestry weaves
> together a network of components to create a page. The only XML-like things
> are the <jwc> tags in the HTML templates, which are used to identify where
> components are placed on the HTML templates, and what other elements of the
> template they wrap.
<jwc> tags is an XML based markup language. Period. There is no hiding that.
You are parsing the document looking for those tags and then evaluating them
to return a result. That is a language.
> It's true I have not yet released the source code (for the reasons mentioned
> above). I have gone out on a limb and release UML diagrams and the complete
> Javadoc.
That stuff doesn't mean anything to me. Sorry. "Going out on a limb" and
releasing pretty pictures really doesn't matter in the world of Open Source.
Yes, it is required for a successful project to have these things to provide
the end user documentation, but they are not as required as the source code
is. You can write up documentation till you are blue in the face, but if
your code sucks then it doesn't matter one bit.
> It was never my intention that the built-in components of Tapestry would be
> all that's used in an application. In fact, just the opposite. Tapestry is
> all about creating new components (each page in a Tapestry application is a
> component). The blue border around each page in the demo is a component.
> The navigation bar along the left side of the border is a component embedded
> in the border, as is the inspector.
In Turbine those are called Modules.
> None of the built-in components is "special" in any way. None of them has
> any code that would not be in an end-user developed component; they have no
> special typecasts in them, they make use of nothing but the public
> interfaces (IApplication, IRequestCycle, IResponseWriter, etc.).
In Turbine those are called Modules.
> Under Tapestry, new components can be created with little or no code through
> aggregation (inheritance plays a part, but you'll more often be creating new
> components in terms of existing components). Each component has a
> specification file (which is an XML document) that defines it's Java class,
> it's HTML template, it's bindable parameters and each of the components
> embedded within it. This is the information that the inspector shows.
In Turbine those are called Modules.
> I don't see any scripting frameworks, such as PHP, WebMacro, JSP, ASP, etc.
> as being MVC because the 'view' gets polluted with control logic. Tapestry
> differentiates itself from such systems through its complete seperation of
> model, view and controller. It accomplishes this through very strong
> specifications.
Have you really looked at WebMacro? I don't think you have, otherwise you
would not have grouped it in with the rest of those languages.
It is pretty hard to pollute the view using WM since there isn't any logic
in it. There is three bits that are necessary...foreach, if and the ability
to do introspection on the variables. That sums up the entire language.
I agree with you on the rest of the languages though. I used PHP back in the
1.0 days through 3.0 and finally got fed up with it when they added their
3000th new function. JSP is marketed as an ASP killer and two wrongs don't
make a right. :-)
> The specifications are what allows Tapestry to manage all the control flow
> of the application. This is where Tapestry really differentiates itself
> from other solutions. Most solutions (though not, as much, Turbine) are
> great for renderring a page, even when sections of it are dynamic ... but
> they leave the application developer with the responsibility of weaving
> together the application from servlets (or equivalent). That lots of ad-hoc
> solutions for naming servlets, building URLs and processing URLs, encoding
> operations and parameters into URLs, etc., etc.
Turbine doesn't have these problems and also has a lot of "helper" code to
make this stuff easy. The end goal for Turbine is to be that bridge that
makes it easy for designers and developers to work together. The beauty of
Turbine is that each time someone comes up with a new page template
language, Turbine can be easily adopted to work with it. Right now, Turbine
works with Cocoon, Freemarker, Webmacro and has initial support for JSP, but
it hasn't been finished for obvious reasons. Essentially, the "View" portion
of Turbine is pluggable. How cool is that?
> Tapestry uses its component object model to do all of that automatically.
> Well behaved components just work. Very well behaved components work
> efficiently.
One would hope so. It would be funny to have you say that it doesn't work
well. :-)
> Tapestry has components to handle forms and form elements just as
> gracefully. It's HTML might look something like:
>
> <p>Select from the following:
> <jwc id="select">
> <jwc id="e">
> <jwc id="option"/>
> </jwc>
> </jwc>
>
> You would then supply a specification for select, e and option. select
> provides the <SELECT> element. e will be an enum component, that will pull
> an array, Vector or Enumeration from your application (via a parameter
> binding) and enumerate its contents. These object will likely by business
> objects of some form defined by the application.
No offense, but I find that syntax ugly and VERY hard to read and not "View"
at all. On top of it, you now have to teach a designer how to write some
funky XML markup language that you invented out of thin air...
If you use WM and Turbine's SelectorBox module, it is simply:
<p>Select from the following:
$selectBox
Now, you tell me which one is easier to teach to designers and entry level
engineers...:-)
> option will extract a property from the current business object as the label
> for an <OPTION> element. option components have a read/write 'selected'
> property that can be bound to some JavaBeans property of the business object
> .... the selected property is read when the HTML page is generated and
> updated when the form on the page is submitted.
Yuck.
> If you find in your application that you are building this option list in
> multiple places (with the same business objects and so forth), you can use
> aggregation to create a code-less component (that is, the existing class
> com.primix.tapestry.BaseComponent provides the code and doesn't need to be
> extended). Then your HTML template will look like:
>
> <p>Select from the following:
> <jwc id="customSelect"/>
Yuck. Coldfusion sucks for this very reason. Do you really believe that you
will be able to get designers to write this stuff?
> One of the neat things about Tapestry is that the form component and the
> form element components work together to do things like set HTML parameter
> names ... one more mechanical thing the framework does that the developer
> can simply take for granted.
Ok, this is kinda interesting but not hard to implement...one thing that
would be cool to add to the SelectorBox would be to have it generate its own
values for the name= attribute and then "register" that with the framework.
> Tapestry's model is a bit different than what I understand about Turbine.
> Rather than stuffing data into a context, Tapestry works by pulling data
> from some source using JavaBeans properties. Most components pull data from
> the component which contains them, but using property paths, they can
> navigate to the page, or application and into business objects.
Turbine itself isn't about doing anything with a Context.
Webmacro is about stuffing OBJECTS into a Context which uses introspection
(ie: Javabean properties) to retrieve.
Using Turbine + Webmacro gets you the same thing that you are talking about
above and you don't have to write some non standard XML markup...on top of
it if you DO want to write XML markup into your pages, you have the option
to integrate Turbine with Cocoon which implements W3C standards.
> I definately agree with you on the "bad vibes" thing, I would rather release
> Tapestry first ... I just want to make sure it has the right home.
Good luck.
-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]
