About client and server separation, I meant that the application should be split into one server/back-end part providing a rest interface and a web application part which can use a completely different framework like Angular. That way no dependencies exist between the two which helps a lot during upgrade of libs etc. From my experience that has worked well.

I believe there is no need to split Tapestry itself for this purpose and I am aware of that there are still use-cases for handling everything in a single application. It is good with choices :-)

Mats


On 2018-11-27 19:56, Thiago H. de Paula Figueiredo wrote:
On Tue, Nov 27, 2018 at 11:39 AM Mats Andersson <mats.anders...@ronsoft.se>
wrote:

I have been using Tapestry in different setups since the beginning of
Tapestry 5. First I found the IOC and the client components useful.

In my day job, which uses Tapestry, even the people who dislike
Tapestry-the-web-framework actually like Tapestry-IoC very much.


Then I realized the benefits of the genious way the filters works.

Yes, you can handle, decorate and protect with Tapestry's filters even
requests which aren't served by Tapestry itself. I'd also include the
dispatchers too. Similar to servlets, but way better (live class reloading,
no XML configuration, Tapestry-IoC).


Now if not already done, in my opinion, it is time to separate client and
server parts.

I'm not sure what's your line between client and server. Client usually
includes just JavaScript, but your description seems to include pages and
components too. If you mean a Tapestry-minimal framework including just
RequestFilter and Dispatcher, that's doable, not a huge effort, and
something similar was already done in the past without breaking changes
(separating the BeanModel classes from tapestry-core).


The main problems I would say is the lack of an updated best practices

Well, the best practices are the same since Tapestry 5.4 was released, and
I'm saying that specifically due to the change in JavaScript support. The
rest hasn't changed much since Tapestry 5.0.


and the missing Java 11 support.

It's being worked on right now, starting with Java 9 first, then 10 and 11
to follow.


I am not updated with the latest on Java 11 support but for my own sake I
am not that worried. About the best practices it is mainly a problem for
Tapestry acceptance. When people see that pages are rendered server side in
Tapestry they see a conflict with the powerful way to build web
applications using Angular or similar. What they don't see is the beautiful
backend framework that is so complete that it do not require continuous
updates. Just opinions, but hopefully it will be of use to someone.

Thanks for your insights!

--
Thiago

--
---------------------- Mats Andersson | Ronsoft AB | +46(0)73 368 79 82


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to