In which direction is Tapestry heading?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

In which direction is Tapestry heading?

Reinhold Gruber-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

hvass
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

chiefsucker
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

Thiago H de Paula Figueiredo
In reply to this post by Reinhold Gruber-3
Hello!

On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thiago
Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

jmgarrido
Hi Thiago, does it make sense to use tapestry just as a middleware between
a javascript client-side framework and the server? Just for implementing a
REST API that gathers the requests from the client and calls the server
methods that implement the use cases?

You don't need a whole components based web framework like tapestry for
that. And you are not using the web components nor pages, etc. What's the
point of it or which sre the benefits? It would be using tapestry just to
offer a REST API?

Maybe I didn't understand what you mean.

Regards,

Juan.



El lun., 26 mar. 2018 17:44, Thiago H. de Paula Figueiredo <
[hidden email]> escribió:

> Hello!
>
> On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Thiago
>
Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

Peter Skala
In reply to this post by Thiago H de Paula Figueiredo
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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Thiago
>



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

Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

Thiago H de Paula Figueiredo
In reply to this post by jmgarrido
On Mon, Mar 26, 2018 at 6:45 PM, Juan Manuel Garrido de Paz <
[hidden email]> wrote:

> Hi Thiago, does it make sense to use tapestry just as a middleware between
> a javascript client-side framework and the server? Just for implementing a
> REST API that gathers the requests from the client and calls the server
> methods that implement the use cases?
>

Hello!

If you're not using Tapestry components at all, then yes, it may not make
sense to use tapestry-core (i.e. the Web framework), but Tapestry-IoC would
still be very useful for organizing your server-side code.

On the other hand, even without Tapestry components, you could still use
tapestry-core for its pipelines, specially HttpServletRequestFilter (for
security, monitoring, etc) and Dispatcher. Also, using Tapestry pages for
delivering non-HTML and non-JSON files (for example, delivering files
stored in a database or a filesystem) and anything else which doesn't fit a
typical REST endpoint.

--
Thiago
Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

Thiago H de Paula Figueiredo
In reply to this post by Peter Skala
On Tue, Mar 27, 2018 at 4:49 AM, <[hidden email]> wrote:

> Hi,
>

Hello!


> 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.
>

Indeed. This doesn't prevent having separate projects/JARs for making it
easier to use one specific JS framework, though.


> 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.
>

Even not implementing JAX-RS, Tapestry can be used for lots of REST
endpoint scenarios. The ones not covered yet, at least not in an explicit,
easy way, are ones involving non-GET operations. I suspect (I haven't
looked at this yet) that it wouldn't be had to add this to Tapestry, inside
its core or even as a separate project/JAR.

We could also have Tapestry implement at least a subset of JAX-RS. I guess
the starting point would be supporting @GET, @PUT, @POST, @DELETE, @HEAD,
@Produces and @Consumes. The @*Param could probably be easily implemented
by copying and adapting the code of @RequestParameter. Data transformations
would be delegated to TypeCoercer.


> 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?
>

If we had Tapestry implement a subset of JAX-RS, we would probably have
enough information in class transformations in order to feed endpoint
information to Swagger (which I don't know yet) or something similar.
Reply | Threaded
Open this post in threaded view
|

Aw: Re: In which direction is Tapestry heading?

Reinhold Gruber-3
In reply to this post by Thiago H de Paula Figueiredo
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" <[hidden email]>
An: "Tapestry users" <[hidden email]>
Betreff: Re: In which direction is Tapestry heading?
Hello!

On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thiago

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

Reply | Threaded
Open this post in threaded view
|

Re: Aw: Re: In which direction is Tapestry heading?

Peter Skala
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" <[hidden email]>
> An: "Tapestry users" <[hidden email]>
> Betreff: Re: In which direction is Tapestry heading?
> Hello!
>
> On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



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

Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

JumpStart
Great example!

IMHO, this kind of info should be added to the documentation.

> On 28 Mar 2018, at 3:47 PM, [hidden email] 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" <[hidden email]>
>> An: "Tapestry users" <[hidden email]>
>> Betreff: Re: In which direction is Tapestry heading?
>> Hello!
>>
>> On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>> --
>> Thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: In which direction is Tapestry heading?

chiefsucker
+1

> On 2018-28-03, at 10:28 AM, JumpStart <[hidden email]> wrote:
>
> Great example!
>
> IMHO, this kind of info should be added to the documentation.
>
>> On 28 Mar 2018, at 3:47 PM, [hidden email] 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" <[hidden email]>
>>> An: "Tapestry users" <[hidden email]>
>>> Betreff: Re: In which direction is Tapestry heading?
>>> Hello!
>>>
>>> On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[hidden email]> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>>
>>> --
>>> Thiago
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


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

Reply | Threaded
Open this post in threaded view
|

Re: Re: In which direction is Tapestry heading?

Thiago H de Paula Figueiredo
In reply to this post by Reinhold Gruber-3
On Tue, Mar 27, 2018 at 8:20 PM, Reinhold Gruber <[hidden email]> 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" <[hidden email]>
> An: "Tapestry users" <[hidden email]>
> Betreff: Re: In which direction is Tapestry heading?
> Hello!
>
> On Thu, Mar 22, 2018 at 8:22 PM, Reinhold Gruber <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Thiago
Reply | Threaded
Open this post in threaded view
|

Re: Aw: Re: In which direction is Tapestry heading?

Thiago H de Paula Figueiredo
In reply to this post by Peter Skala
On Wed, Mar 28, 2018 at 4:47 AM, <[hidden email]> wrote:

> Hallo Reinhold,
>

Hello!


> 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:
>

Nice example! Thanks!


>
> 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) {
>

This part, specifically finding the URL of the event handler, can be
simplified a lot by using @PublishEvent and
http://tapestry.apache.org/ajax-and-zones.html#AjaxandZones-Invokingserver-sideeventhandlermethodsfromJavaScript
.

--
Thiago