Re: In which direction is Tapestry heading?

On Tue, Mar 27, 2018 at 4:49 AM, <[email protected]> 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.