Hello Reinhold, Peter shares the same sentiments as me. I see Tapestry as a framework that fulfills some specific needs, and is even capable of async DOM manipulation, but I don’t see it as a driver for “modern” client-server web-architectures (whatever this means…).
For architectures like these I recommend using something that can easily generate JSON-API on the server and Ember on the client-side. Ember is a JavaScript framework that understands JSON-API, so that you are capable of working with objects on the client-side. You fetch, modify & store data just like with an ORM. Ember also has the same opinionated and rigid structure like Tapestry (I prefer this kind of thought-through framework architectures). I don’t know enough about Angular & React, but I imagine they have similar adapters. From what I observe Tapestry development isn’t very active these days, and I’m thankful for every commit and improvement. I would rather see the energy focused on API & documentation improvements, instead of implementing functionality that you can achieve somewhere else. Best Rafael > On 2018-23-03, at 07:46 AM, Peter Hvass <peter.hv...@jamesinnes.com> wrote: > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
