http://community.apache.org/apache-extras/faq.html
On 28.09.2011 02:20, Howard Lewis Ship wrote:
> 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?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
