I've had some great opportunities to meet with a wide variety of
Tapestry users over the last couple of months of travel.
Here's a few idea that have come up.
MAKE IT EASIER TO DONATE COMPONENTS & CODE
For a lot of people, the trouble of setting up a component library,
and a Maven repository, and maybe a site to store JavaDoc is a bit
much.
I had a bit of inspiration ... what if we set a few basic ground rules
for creating components & mixins as GitHub projects using Gradle to
build.
Now, someone sends us a GitHub repository URL and a branch/tag name
(for a stable version of their code). We have code running somewhere
that pulls all of these community repositories, runs a build, and
creates an "uberjar" of all the components from all the community
projects, all under a single virtual folder ("community" comes to
mind). There might be naming conventions for things like module names
and a way to find the root package for the contributed library. A
single site would provide the JavaDoc for all such modules, as well as
a Maven repository (perhaps a snapshot repository and a stable
repository, or a Nexus, whatever).
Anyway, that's a thumbnail sketch, but the idea is to create an easy
way that people can develop useful components and get them up on
GitHub and we have a process to aggregate those into a useful library.
Obviously, due to licensing, this could not be hosted at Apache, but
perhaps an EC2 instance or something.
MOVE TOWARDS GREATER CLIENT-SIDE FOCUS
The biggest pain point in Tapestry is Ajax ... what Tapestry does out
of the box is fine, but when you hit the limits (AjaxFormLoop) is
becomes very tangled. The central issue is trying to coordinate the
client-side state with matching server-side state (in the form of the
t:formdata contents). Although I can think of ways to make that a
little more straightforward, on the whole, it's a complexity trap
(each new "solution" just adds more leaking complexity).
There's been a lot of advances in terms of client-side JavaScript MVC
libraries and such; things like backbone.js and friends. I think it
would be very good for Tapestry to start leveraging that kind of
logic, make it very easy to have components on the server side render
markup and JavaScript that shifts responsibility to the client. There
wouldn't necessarily be a Form or TextField at that point, something
similar (like an EditableText) that supported in-place editing, and
management of a context of properties and relationships, with the
ability to control when the update is posted to the server. That would
be an Ajax call that would treat Tapestry more like a restful end
point, sending a JSON payload of property updates that would be
applied to the server-side objects (Hibernate entities and the like)
and stored to a database.
There's a few different interaction models to cover: For instance, in
some cases, clicking on an individual bit of text should cause
in-place editting of just that "field". The change may be posted to
the server on field exit, or via an added button, or may be deferred
until some later point (perhaps triggered by a "form-wide" update
button). Alternately, click a field or a "form-wide" edit button may
transform multiple fields into an editable state all at once, and send
updates to the server when a "form-wide" update button is clicked.
Properly done, this would allow much more "desktop" feeling UIs to be
created. It would allow significantly more complex and reactive UIs
to be created. There would need to be a balance of declarative
behavior with the options to "take the reins" to do some kinds of
operations ... again, I need a lot more time to flesh this idea out.
Ultimately, I see Form/TextField/etc. being used rarely, and only for
simple forms (login page, that type of thing).
Although there are some who think a web application should just be
jQuery on the client side and RESTful endpoints on the server side, I
think the things that make Tapestry useful extend well into "modern"
JavaScript heavy applications. jQuery plugins are nice, but Tapestry
adds composibility, robustness, performance, and other factors that
can streamline development on both sides of the HTTP pipe. We want to
make sure Tapestry stays relevant.
IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA DEVELOPERS?
Some Tapestry users have reported back that they love Tapestry, and it
feels very natural to them .. but when they show it to other
developers, they others don't "get it". It's hard to pin down ...
what's not to "get"? Fields, methods, templates and events is most of
what you need to know, and that's really not that much. I'm a bit
perplexed by this feedback, because I show Tapestry to a lot of people
who have not seen it (or not seen it in detail) before and most
people's reaction is that's is simple. But again, there's those who
don't "get it" ... how do we identify those people (who may be a
silent majority), how do we identify what they "don't get", and how do
we get them to embrace Tapestry?
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
