On Tue, Mar 27, 2018 at 8:20 PM, Reinhold Gruber <herr_re...@gmx.at> wrote:
> Hello! > Hi! > 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. > Thank you very much for the feedback! It definitely can be implemented, and I don't believe it needs to be done inside Tapestry at all. If you look at the Form component, which is the one who has the most code in Tapestry's form handling, there's nothing internal to the framework. Dynamic forms could be implemented as a component library. So, even if the Tapestry team doesn't implement it, nothing is preventing someone else to create it and share it. > > 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-sideeventhandlermethodsfromJav > aScript[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 > > -- Thiago
