Re: In which direction is Tapestry heading?

Hello Reinhold,

Peter shares the same sentiments as me. I see Tapestry as a framework that fulfills some specific needs, and is even capable of async DOM manipulation, but I don’t see it as a driver for “modern” client-server web-architectures (whatever this means…).

For architectures like these I recommend using something that can easily generate JSON-API on the server and Ember on the client-side. Ember is a JavaScript framework that understands JSON-API, so that you are capable of working with objects on the client-side. You fetch, modify & store data just like with an ORM. Ember also has the same opinionated and rigid structure like Tapestry (I prefer this kind of thought-through framework architectures). I don’t know enough about Angular & React, but I imagine they have similar adapters.

From what I observe Tapestry development isn’t very active these days, and I’m thankful for every commit and improvement. I would rather see the energy focused on API & documentation improvements, instead of implementing functionality that you can achieve somewhere else.

Best
Rafael


> On 2018-23-03, at 07:46 AM, Peter Hvass <[email protected]> wrote:
> 
> We were thinking of taking steps in this direction ourselves but by
> dropping in (as if it would be so simple...) React or Angular. I believe
> there was some previous discussion on the list surrounding this vague sort
> of topic.
> 
> Is there any consensus or drive - or have any of you even taken steps of
> your own like this?
> 
> Would love to hear it! Especially if you're able to open source what you've
> done!!
> 
> 
> 
> Kind regards,
> Peter Anders Hvass <https://www.linkedin.com/in/peterhvass>
> CTO, James Innes Group <https://www.jamesinnes.com>
> 
> 
> On 23 March 2018 at 01:22, Reinhold Gruber <[email protected]> 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?
>> 
>> What can we expect by Tapestry 5.5?
>> 
>> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]