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" <thiag...@gmail.com> An: "Tapestry users" <users@tapestry.apache.org> Betreff: Re: In which direction is Tapestry heading? Hello! On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <herr_re...@gmx.at> 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: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
