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 . 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/ 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
