We were thinking of taking steps in this direction ourselves but by dropping in (as if it would be so simple...) React or Angular. I believe there was some previous discussion on the list surrounding this vague sort of topic.
Is there any consensus or drive - or have any of you even taken steps of your own like this? Would love to hear it! Especially if you're able to open source what you've done!! Kind regards, Peter Anders Hvass <https://www.linkedin.com/in/peterhvass> CTO, James Innes Group <https://www.jamesinnes.com> On 23 March 2018 at 01:22, 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? > > What can we expect by Tapestry 5.5? > > 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 > >
