+1
> On 2018-28-03, at 10:28 AM, JumpStart <geoff.callender.jumpst...@gmail.com>
> wrote:
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
