Aw: Re: In which direction is Tapestry heading?

Hello!

I'm struggeling with very dynamic forms on a regular base. Especially an "out of date" t:form-data which does no longer represent the current state/content of the form.
So I found HLS's idea of a form submit paradigmn change --> replacing normal HTTP Posts and their query params with AJAX calls sending JSON which magically don't need the t:form-data information but where the sent data is automatically bound to server side objects very appealing. At least that is what I thought was meant in the article.

I can only speculate whether this feature can be implemented at all and if so how much work it would be. But since you asked me what I would like to see, this functionality would really be awesome.

Best regards
Reinhold
 
 

Gesendet: Montag, 26. März 2018 um 16:47 Uhr
Von: "Thiago H. de Paula Figueiredo" <[email protected]>
An: "Tapestry users" <[email protected]>
Betreff: Re: In which direction is Tapestry heading?
Hello!

On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[email protected]> wrote:

> Hi!
>
> 6 years ago HLS wrote an article on Dzone https://dzone.com/articles/
> tapestry-54-focus-javascript which contained among other things following
> very promising paragraph. See below.
>
> Is this kind of functionality still on the agenda?
>

I don't think so. It would be a huge effort and the team time has been
scarce.

On the other hand, in Tapestry 5.4.3, we added a feature to make it much
easier and with much less code to call event handler methods from
JavaScript code:
http://tapestry.apache.org/ajax-and-zones.html#AjaxandZones-Invokingserver-sideeventhandlermethodsfromJavaScript[http://tapestry.apache.org/ajax-and-zones.html#AjaxandZones-Invokingserver-sideeventhandlermethodsfromJavaScript]
.

I agree with Rafael and Peter that trying to make Tapestry, a mostly
server-focused framework, shouldn't try to compete or do the same as
JavaScript client-side-only libraries. I believe our efforts are better
spent on making Tapestry easier to provide the server-side code needed for
client-side libraries. The feature above and, for example,
http://www.tynamo.org/tapestry-resteasy+guide/[http://www.tynamo.org/tapestry-resteasy+guide/] or my old mental plan to
make an integration between Tapestry-IoC and Apache CXF so you can easily
have a backend implemented as live-class-reloadable Tapestry-IoC services.


> What can we expect by Tapestry 5.5?
>

*We believe our framework has a very mature and flexible foundation, so we
don’t need to add stuff in its core: most innovation can be done in
separate projects. Our main goal for the next version, 5.5, is Java 9
support, out-of-the-box, on-the-fly TypeScript compilation and performance
improvements.*

What would you like to see in Tapestry 5.5? Feedback is always welcome. And
so is new stuff built on top of Tapestry, even more when it's open source.
:)

>
> Best Regards
> Reinhold
>
> ************************************************************
> ************************************************************
> ***************
> Embrace client-side controller logic
> The changes discussed so far only smooth out a few rough edges; they still
> position Tapestry code, running on the server, as driving the entire show.
> As alluded to earlier; for any sophisticated user interface, the challenge
> is to coordinate the client-side user interface (in terms of form fields,
> DOM elements, and query parameters) with the server-side components; this
> is encoded into the hidden t:formdata field. However, it is my opinion that
> for any dynamic form, Tapestry is or near the end of the road for this
> approach.
> Instead, it's time to embrace client-logic, written in JavaScript, in the
> browser. Specifically, break away from HTML forms, and embrace a more
> dynamic structure, one where "submitting" a form always works through an
> Ajax update ... and what is sent is not a simple set of query parameters
> and values, but a JSON representation of what was updated, changed, or
> created.
> My specific vision is to integrate Backbone.js (or something quite
> similar), to move this logic solidly to the client side. This is a
> fundamental change: one where the client-side is free to change and
> reconfigure the UI in any way it likes, and is ultimately responsible for
> packaging up the completed data and sending it to the server.
> When you are used to the BeanEditForm component, this might feel like a
> step backwards, as you end up responsible for writing a bit more code (in
> JavaScript) to implement the user interface, input validations, and
> relationships between fields. However, as fun as BeanEditForm is, the
> declarative approach to validation on the client and the server has proven
> to be limited and limiting, especially in the face of cross-field
> relationships. We could attempt to extend the declarative nature,
> introducing rules or even scripting languages to establish the
> relationships ... or we could move in a situation that puts the developer
> back in the driver's seat.
> Further, there are some that will be concerned that this is a violation of
> the DRY pricipal; however I subscribe to different philosophy that
> client-side and server-side validation are fundamentally different in any
> case; this is discussed in an excellent blog post by Ian Bickling.
> Certainly there will be components and services to assist with this
> process, in term of extracting data into JSON format, and converting JSON
> data into a set of updates to the server-side objects. There's also a
> number of security concerns that necessitate careful validation of what
> comes up from the client in the Ajax request. Further, there will be new
> bundled libraries to make it easier to build these dynamic user interfaces.
> ************************************************************
> ************************************************************
> ***************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>


--
Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]