Hi, tapestry 5.4 made with the requireJS integration a great step towards supporting any of the JS frameworks out there. Supporting only a single one of them would be a step back.
Using tapestry on the server side of dynamic client applications is effective as it possible to initialize the pages in a context specific way and to provide the RESP API for them, everything smoothly integrated with java side components and greatly reusable. This is all working very well in 5.4. Very helpful would be to provide the REST API description endpoints out of the box – something of the art of swagger. What would be the most effective design for it? Peter Skala > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
