Great example!
IMHO, this kind of info should be added to the documentation.
> On 28 Mar 2018, at 3:47 PM, peter.sk...@ooom.at wrote:
>
> Hallo Reinhold,
>
> Tapestry can be used without classical forms. If you have to include the form
> component because of the dependence of the input components on it, suppress
> its
> default action.
>
> On the client side you can use any DOM event to trigger an Ajax action. A
> typical
> event handler can look like this:
>
> var someEventHandler = function(ev) {
> var pars = {date: dateSelected, time: timeSelected, lid: lid };
> var ciphered = reg.aesCipher( JSON.stringify(pars));
> $.ajax({
> url: "xxx.tapestry.event.handler.url",
> method: "POST",
> data: { ciphered: ciphered }
> }).success( function( response) {
> if( response.result == "OK" ) {
> reInitComponent( response);
> } else if( response.result == "NOK" && typeof response.field == 'string') {
> base.setTextOfEl( response.field + 'Msg', response.msg);
> } else if( ...) {
> handleTimeout();
> }
> });
> return false;
> };
>
> Instead of transferring JSON as a plain string it is better to convert it to
> a HEX
> form, to avoid problems with restricted characters.
>
> On the server side, the tapestry event handler returns a JSONObject, which
> then
> becomes an element of the response above.
>
> Yo can also use
>
> ajaxResponseRenderer.addRender("someTapestryZone", someTapestryZone);
>
> in the event handler to create a HTML snippet. This is then contained in the
> response
> above as well and you can use it to update the client, something like this:
>
> var reInitZone = function( response) {
> var replaceEl = jQueryEl.children('[id^=someTapestryZone]');
> if( "someTapestryZone"==response._tapestry.content[ 0][0]) {
> var replaceReturndata = replaceEl.replaceWith(
> response._tapestry.content[ 0][1]);
> reinitZoneEvents();
> }
> };
>
> The number of zones on a page is not limited, so I find this way of using
> tapestry
> very interesting.
>
> With regards, Peter
>
>> Hello!
>>
>> 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.
>>
>> 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-sideeventhandlermethodsfromJavaScript[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
>>
>>
>
>
>
> ---------------------------------------------------------------------
> 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
