Some very interesting points. I have to aggree on several things.
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.
Somehow when I was researching similar projects before I started on Tapestry
I missed Turbine. 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.
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.
You can see this interactively by clicking "[Show inspector]" on any page in
the demo. The inspector dynamically displays the construction of a Tapestry
application while the application is running. It allows you to navigate the
component hierarchy for the page and view HTML templates, embedded
components, bindings, etc.
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.
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.
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.).
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.
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.
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.
Tapestry uses its component object model to do all of that automatically.
Well behaved components just work. Very well behaved components work
efficiently.
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.
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.
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"/>
Through the use of parameters and bindings, you could allow the same
component to be configured differently on different pages ... you can define
a parameter to set the number of visible rows.
In fact, I use something like this in the demo. Go to the survey page of
the demo and use the inspector to dig down into a 'simpleradiogroup'
component.
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.
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.
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.
-----Original Message-----
From: jon *
To: Java Apache; Ship, Howard
Sent: 15/04/00 19:33
Subject: Re: Update: Tapestry -- Possible contribution to the Java Apache
proj ect
on 4/15/00 1:00 PM, Ship, Howard <[EMAIL PROTECTED]> wrote:
> Sorry ... there's some kind of DNS issue that suddenly cropped up.
>
> Try by IP:
>
> http://206.35.141.116/tapestry
>
> This appears to work from outside the Primix firewall.
Woopps...accidentally hit the wrong key before I was ready to send it...
Ok...I have spent more time thinking about all of this and I'm -1 on
your
suggestion of adding your product to the Java Apache Project _today_. As
with all -1's here is my reasoning...
#1. We don't need yet another XML based markup language. Putting XML
into
HTML is a really bad design idea because it does not foster a MVC design
model like WebMacro and Freemarker does. Coldfusion and many other
products
blatantly suck for this reason. Cocoon is the best solution for putting
XML
into HTML because it follows the W3C specifications.
#2. Your end functionality is very similar to Turbine. No need to
re-invent
the wheel in my opinion. Instead you should partner with Turbine.
#3. the tapestry.component.* classes is the wrong way to do things
because
they never end up being enough. DatabaseQuery is obviously a bad idea,
you
state that yourself in your Javadocs. These object should be useful for
generating a MVC model, not for hiding things from the end user. The
HTML
components in the least, you should integrate with ECS.
For example, I just added a SelectorBox class to Turbine that solves a
problem in Webmacro where it is really hard to generate a <select> that
has
been populated from the database containing <option> elements that may
or
may not be selected. In this case, the best MVC model would be to
populate
the SelectorBox in the java code and then stuff that into the context
where
it can be retrieved by the designer and placed anywhere. Specifics like
the
size of the box and such can also be set by the designer. Example:
<td>
$selectorBox.setSize(5).setMultiple(true)
</td>
The beauty of the above is that the designer does not need to worry
about
setting the selected items on the option elements. They only need to
worry
about where it is placed into the design. On top of it, the HTML
generated
from the selectorbox class is built with ECS so that one can also take
advantage of the features of ECS.
#4. My impressions from your documentation is that you are trying to go
up
against JSP/ASP/PHP/etc...that is the wrong way to do things. You are
not
attempting to create anything new, you are simply trying to create an
alternative to those tools. Not useful IMHO. My suggestion to you is to
remove the comparisons to those tools.
#5. As I said before...I get bad vibes from people who shop their
technology
around first for a project. Making acceptance into a project a condition
for
giving out source code is a really bad way to do things because it makes
me
feel like all the hard work that I have done MUST not be as cool as what
you
have hidden under your covers...lets see how good and clean and useful
your
source code is FIRST! and then I will personally consider you (Note that
I
am speaking for myself only and I happen to have -1 privs. Someone else
with
-1 privs on this project can freely object to what I say). Not the other
way
around. Every other project that has been incorporated into the Java
Apache
Project (and Apache Software Foundation as a whole) has done this.
> I'm currently in the process of garnering internal support to release
Tapestry
> as an open source project on the Giant Java Tree
Why are you posting here then?
#6. You said that your product does not lock you into the Module
methodologies like Turbine does. Well, I have already stated that is
completely wrong. Now I have something to fire back at you...from what I
can
see (I don't have source code)...your product seems to lock people into
some
XML markup language scheme that you invented. On top of it, there is
quite a
bit that is missing from your product that is already available and well
thought out (and pluggable) in Turbine such as
#7. You are either going to go OS or you aren't. Pick a license and just
put
it up on your website. If another project, such as Java Apache likes
your
code, then we will ask you if you are interested in joining forces ...
otherwise, feel free to come up with yet another alternative to doing
the
same thing over and over and over again...
I really wish you good luck with your code. You have obviously spent a
lot
of time with it. I hope that it becomes a successful project and gets a
lot
of mindshare because regardless of what I might think of it, it will
help
the overall cause of getting people to recognize that Java Servlets are
the
future.
-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]
