Re: [ANNOUNCEMENT] Tapestry 5.4.4
By the way, I've just found this ticket, so you don't need to create another: https://issues.apache.org/jira/browse/TAP5-2560 On Tue, Jan 8, 2019 at 7:38 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Thu, Jan 3, 2019 at 7:51 AM Chris Poulsen > wrote: > >> Hi >> > > Hello! > > >> The "fix" for GenericsUtils is attached. >> > > I don't think the attachment worked. Could you please post it inline? Or, > better yet, to a Jira issue? Thanks in advance. :) > > >> I think that Guava is not the proper general solution as it is a rather >> huge beast to bring in, just to get access to its TypeToken. Personally I >> would prefer a lighter solution. >> >> We have been running this code in production since medio '16 without >> requiring any more fixes. I can see from my commit comment back then, that >> I initially attempted to fix GenericsUtils itself, then attempted to use >> the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as >> it was already a dependency of our application. If the reflect stuff from >> commons-lang3 could be made to work, that would not require any additional >> dependencies being added and be a good solution IMO. >> >> I'm not sure I did create a ticket for the GenericsUtils issue, I may >> just have asked on the list to see if anyone else was had experienced >> something similar. >> >> Revisiting our override code I also see that we have a custom >> PropertyAccessImpl in place, that one fixes some cases where the Java >> Introspector fails to locate some setters, but I see that the Tapestry >> class has received some changes after our version was created, so I >> probably need to check whether that one is still necessary. >> >> -- >> Chris >> >> >> On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo < >> thiag...@gmail.com> wrote: >> >>> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen >>> wrote: >>> >>> > Hi >>> > >>> > Hello! >>> >>> >>> > We are using some pretty complex data models with deep interface >>> > hierarchies and generics, and I ended up replacing the internals of >>> > GenericsUtils with calls to com.google.common.reflect.TypeToken >>> (Guava) to >>> > get correct behavior >>> >>> >>> Would it be possible to share your GenericUtils implementation using >>> Guava >>> with the Tapestry project? Also, what's the ticket you posted before? We >>> definitely want to fix it for the 5.5.0 release. I already got another >>> report of a similar problem from another person and it would be nice to >>> reuse your solution if possible. >>> >>> >>> > (often tapestry would complain that some "setter" was >>> > not found or similar because it resolved the type to something higher >>> in >>> > the interface/object hierarchy and missed the correct method override >>> due >>> > to typing or something else. (I spent some time on attempting to fix >>> the >>> > tapestry implementation, but ended up thinking it was a waste of time >>> > trying to replicate functionality that was already coded (more >>> correctly) >>> > by other people, and picked guava as that was already present in our >>> > dependencies). >>> > >>> > Perhaps it is possible to find a lightweight,/focused library with a >>> > compatible license today, that tapestry could rely on, instead of >>> > attempting to implement this on its own. >>> > >>> > This is obviously not a widespread problem, but it is one of >>> correctness >>> > and it tickles my OCD ;) >>> > >>> > -- >>> > Chris >>> > >>> > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo < >>> > thiag...@gmail.com> wrote: >>> > >>> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski < >>> > > raf...@juicycocktail.com> >>> > > wrote: >>> > > >>> > > > Congratulations! Thanks to the core team for your continuous work >>> and >>> > the >>> > > > effort you put into maintaining Tapestry. >>> > > > >>> > > >>> > > Thanks! >>> > > >>> > > >>> > > > I think the whole industry goes the way of trying to simplify >>> things >>> > > (just >>> > > > take a look at the most recent programming languages & >>> frameworks). If >>> > > > we’re talking about modernizing and competing with other >>> frameworks, I >>> > > > would like to see Tapestry reducing the complexity that is >>> currently >>> > > > required to grasp the framework and its various concepts (which are >>> > > > technically great, but sometimes hard to understand if you just >>> start >>> > > > working with Tapestry). I think this will only work by providing >>> old & >>> > > new >>> > > > APIs at the same time and by making the upgrade path and >>> improvements >>> > > very >>> > > > clear in the documentation. >>> > > > >>> > > >>> > > Well, some stuff is indeed not simple, and I'd say the form support >>> is >>> > the >>> > > part which could use some new components to make at least the simpler >>> > > scenarios simpler to implement (for example, when there are no >>> loops). >>> > > Which other areas do you think could or should be simplified? >>> > > >>> > >
Re: [ANNOUNCEMENT] Tapestry 5.4.4
On Thu, Jan 3, 2019 at 7:51 AM Chris Poulsen wrote: > Hi > Hello! > The "fix" for GenericsUtils is attached. > I don't think the attachment worked. Could you please post it inline? Or, better yet, to a Jira issue? Thanks in advance. :) > I think that Guava is not the proper general solution as it is a rather > huge beast to bring in, just to get access to its TypeToken. Personally I > would prefer a lighter solution. > > We have been running this code in production since medio '16 without > requiring any more fixes. I can see from my commit comment back then, that > I initially attempted to fix GenericsUtils itself, then attempted to use > the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as > it was already a dependency of our application. If the reflect stuff from > commons-lang3 could be made to work, that would not require any additional > dependencies being added and be a good solution IMO. > > I'm not sure I did create a ticket for the GenericsUtils issue, I may just > have asked on the list to see if anyone else was had experienced something > similar. > > Revisiting our override code I also see that we have a custom > PropertyAccessImpl in place, that one fixes some cases where the Java > Introspector fails to locate some setters, but I see that the Tapestry > class has received some changes after our version was created, so I > probably need to check whether that one is still necessary. > > -- > Chris > > > On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen >> wrote: >> >> > Hi >> > >> > Hello! >> >> >> > We are using some pretty complex data models with deep interface >> > hierarchies and generics, and I ended up replacing the internals of >> > GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava) >> to >> > get correct behavior >> >> >> Would it be possible to share your GenericUtils implementation using Guava >> with the Tapestry project? Also, what's the ticket you posted before? We >> definitely want to fix it for the 5.5.0 release. I already got another >> report of a similar problem from another person and it would be nice to >> reuse your solution if possible. >> >> >> > (often tapestry would complain that some "setter" was >> > not found or similar because it resolved the type to something higher in >> > the interface/object hierarchy and missed the correct method override >> due >> > to typing or something else. (I spent some time on attempting to fix the >> > tapestry implementation, but ended up thinking it was a waste of time >> > trying to replicate functionality that was already coded (more >> correctly) >> > by other people, and picked guava as that was already present in our >> > dependencies). >> > >> > Perhaps it is possible to find a lightweight,/focused library with a >> > compatible license today, that tapestry could rely on, instead of >> > attempting to implement this on its own. >> > >> > This is obviously not a widespread problem, but it is one of correctness >> > and it tickles my OCD ;) >> > >> > -- >> > Chris >> > >> > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo < >> > thiag...@gmail.com> wrote: >> > >> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski < >> > > raf...@juicycocktail.com> >> > > wrote: >> > > >> > > > Congratulations! Thanks to the core team for your continuous work >> and >> > the >> > > > effort you put into maintaining Tapestry. >> > > > >> > > >> > > Thanks! >> > > >> > > >> > > > I think the whole industry goes the way of trying to simplify things >> > > (just >> > > > take a look at the most recent programming languages & frameworks). >> If >> > > > we’re talking about modernizing and competing with other >> frameworks, I >> > > > would like to see Tapestry reducing the complexity that is currently >> > > > required to grasp the framework and its various concepts (which are >> > > > technically great, but sometimes hard to understand if you just >> start >> > > > working with Tapestry). I think this will only work by providing >> old & >> > > new >> > > > APIs at the same time and by making the upgrade path and >> improvements >> > > very >> > > > clear in the documentation. >> > > > >> > > >> > > Well, some stuff is indeed not simple, and I'd say the form support is >> > the >> > > part which could use some new components to make at least the simpler >> > > scenarios simpler to implement (for example, when there are no loops). >> > > Which other areas do you think could or should be simplified? >> > > >> > > >> > > > Personally I’m also getting into the vibe of smaller services that >> > > > communicate with each other, instead of this one monolithic giant >> that >> > > > tries to be everything, but is nothing in the end. We use >> > > bootique-tapestry >> > > > (and also other Bootique-compatible integrations). I would like to >> see >> > > > Tapestry to also go in this direction and
Re: [ANNOUNCEMENT] Tapestry 5.4.4
On Thu, Jan 3, 2019 at 7:51 AM Chris Poulsen wrote: > Hi > Hello! > The "fix" for GenericsUtils is attached. I think that Guava is not the > proper general solution as it is a rather huge beast to bring in, just to > get access to its TypeToken. Personally I would prefer a lighter solution. > Thank you very much! Could you please create an issue and post the fixed GenericUtils there? This way, it's clear the code was contributed and the copyright situation is clear and correct. > We have been running this code in production since medio '16 without > requiring any more fixes. I can see from my commit comment back then, that > I initially attempted to fix GenericsUtils itself, then attempted to use > the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as > it was already a dependency of our application. If the reflect stuff from > commons-lang3 could be made to work, that would not require any additional > dependencies being added and be a good solution IMO. > I was thinking of creating a separate subproject/JAR, for backward compatibility reasons, so anyone wanting to use the Guava-based one could just easily add the dependency, at least until we find a smaller solution in the future. > Revisiting our override code I also see that we have a custom > PropertyAccessImpl in place, that one fixes some cases where the Java > Introspector fails to locate some setters, but I see that the Tapestry > class has received some changes after our version was created, so I > probably need to check whether that one is still necessary. > PropertyAccessImpl does indeed cover some cases the Java introspector doesn't and it did evolve in the latest years, so I agree this may not be necessary anymore. Thanks again! > -- > Chris > > > On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen >> wrote: >> >> > Hi >> > >> > Hello! >> >> >> > We are using some pretty complex data models with deep interface >> > hierarchies and generics, and I ended up replacing the internals of >> > GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava) >> to >> > get correct behavior >> >> >> Would it be possible to share your GenericUtils implementation using Guava >> with the Tapestry project? Also, what's the ticket you posted before? We >> definitely want to fix it for the 5.5.0 release. I already got another >> report of a similar problem from another person and it would be nice to >> reuse your solution if possible. >> >> >> > (often tapestry would complain that some "setter" was >> > not found or similar because it resolved the type to something higher in >> > the interface/object hierarchy and missed the correct method override >> due >> > to typing or something else. (I spent some time on attempting to fix the >> > tapestry implementation, but ended up thinking it was a waste of time >> > trying to replicate functionality that was already coded (more >> correctly) >> > by other people, and picked guava as that was already present in our >> > dependencies). >> > >> > Perhaps it is possible to find a lightweight,/focused library with a >> > compatible license today, that tapestry could rely on, instead of >> > attempting to implement this on its own. >> > >> > This is obviously not a widespread problem, but it is one of correctness >> > and it tickles my OCD ;) >> > >> > -- >> > Chris >> > >> > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo < >> > thiag...@gmail.com> wrote: >> > >> > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski < >> > > raf...@juicycocktail.com> >> > > wrote: >> > > >> > > > Congratulations! Thanks to the core team for your continuous work >> and >> > the >> > > > effort you put into maintaining Tapestry. >> > > > >> > > >> > > Thanks! >> > > >> > > >> > > > I think the whole industry goes the way of trying to simplify things >> > > (just >> > > > take a look at the most recent programming languages & frameworks). >> If >> > > > we’re talking about modernizing and competing with other >> frameworks, I >> > > > would like to see Tapestry reducing the complexity that is currently >> > > > required to grasp the framework and its various concepts (which are >> > > > technically great, but sometimes hard to understand if you just >> start >> > > > working with Tapestry). I think this will only work by providing >> old & >> > > new >> > > > APIs at the same time and by making the upgrade path and >> improvements >> > > very >> > > > clear in the documentation. >> > > > >> > > >> > > Well, some stuff is indeed not simple, and I'd say the form support is >> > the >> > > part which could use some new components to make at least the simpler >> > > scenarios simpler to implement (for example, when there are no loops). >> > > Which other areas do you think could or should be simplified? >> > > >> > > >> > > > Personally I’m also getting into the vibe of smaller services that
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Hi The "fix" for GenericsUtils is attached. I think that Guava is not the proper general solution as it is a rather huge beast to bring in, just to get access to its TypeToken. Personally I would prefer a lighter solution. We have been running this code in production since medio '16 without requiring any more fixes. I can see from my commit comment back then, that I initially attempted to fix GenericsUtils itself, then attempted to use the commons-lang3 (reflect stuff) and finally gave up plugging in Guava as it was already a dependency of our application. If the reflect stuff from commons-lang3 could be made to work, that would not require any additional dependencies being added and be a good solution IMO. I'm not sure I did create a ticket for the GenericsUtils issue, I may just have asked on the list to see if anyone else was had experienced something similar. Revisiting our override code I also see that we have a custom PropertyAccessImpl in place, that one fixes some cases where the Java Introspector fails to locate some setters, but I see that the Tapestry class has received some changes after our version was created, so I probably need to check whether that one is still necessary. -- Chris On Thu, Jan 3, 2019 at 1:05 AM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen > wrote: > > > Hi > > > > Hello! > > > > We are using some pretty complex data models with deep interface > > hierarchies and generics, and I ended up replacing the internals of > > GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava) > to > > get correct behavior > > > Would it be possible to share your GenericUtils implementation using Guava > with the Tapestry project? Also, what's the ticket you posted before? We > definitely want to fix it for the 5.5.0 release. I already got another > report of a similar problem from another person and it would be nice to > reuse your solution if possible. > > > > (often tapestry would complain that some "setter" was > > not found or similar because it resolved the type to something higher in > > the interface/object hierarchy and missed the correct method override due > > to typing or something else. (I spent some time on attempting to fix the > > tapestry implementation, but ended up thinking it was a waste of time > > trying to replicate functionality that was already coded (more correctly) > > by other people, and picked guava as that was already present in our > > dependencies). > > > > Perhaps it is possible to find a lightweight,/focused library with a > > compatible license today, that tapestry could rely on, instead of > > attempting to implement this on its own. > > > > This is obviously not a widespread problem, but it is one of correctness > > and it tickles my OCD ;) > > > > -- > > Chris > > > > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo < > > thiag...@gmail.com> wrote: > > > > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski < > > > raf...@juicycocktail.com> > > > wrote: > > > > > > > Congratulations! Thanks to the core team for your continuous work and > > the > > > > effort you put into maintaining Tapestry. > > > > > > > > > > Thanks! > > > > > > > > > > I think the whole industry goes the way of trying to simplify things > > > (just > > > > take a look at the most recent programming languages & frameworks). > If > > > > we’re talking about modernizing and competing with other frameworks, > I > > > > would like to see Tapestry reducing the complexity that is currently > > > > required to grasp the framework and its various concepts (which are > > > > technically great, but sometimes hard to understand if you just start > > > > working with Tapestry). I think this will only work by providing old > & > > > new > > > > APIs at the same time and by making the upgrade path and improvements > > > very > > > > clear in the documentation. > > > > > > > > > > Well, some stuff is indeed not simple, and I'd say the form support is > > the > > > part which could use some new components to make at least the simpler > > > scenarios simpler to implement (for example, when there are no loops). > > > Which other areas do you think could or should be simplified? > > > > > > > > > > Personally I’m also getting into the vibe of smaller services that > > > > communicate with each other, instead of this one monolithic giant > that > > > > tries to be everything, but is nothing in the end. We use > > > bootique-tapestry > > > > (and also other Bootique-compatible integrations). I would like to > see > > > > Tapestry to also go in this direction and improve integration on > > similar > > > > deployment environments. > > > > > > > > > > We could definitely have some ideas to make microservices easier to > build > > > on the top of Tapestry-IoC. > > > > > > > > > > On the other side, I’m currently pretty happy with the state of > > Tapestry > > > > and with the framework keeping up with modern
Re: [ANNOUNCEMENT] Tapestry 5.4.4
On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen wrote: > Hi > > Hello! > We are using some pretty complex data models with deep interface > hierarchies and generics, and I ended up replacing the internals of > GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava) to > get correct behavior Would it be possible to share your GenericUtils implementation using Guava with the Tapestry project? Also, what's the ticket you posted before? We definitely want to fix it for the 5.5.0 release. I already got another report of a similar problem from another person and it would be nice to reuse your solution if possible. > (often tapestry would complain that some "setter" was > not found or similar because it resolved the type to something higher in > the interface/object hierarchy and missed the correct method override due > to typing or something else. (I spent some time on attempting to fix the > tapestry implementation, but ended up thinking it was a waste of time > trying to replicate functionality that was already coded (more correctly) > by other people, and picked guava as that was already present in our > dependencies). > > Perhaps it is possible to find a lightweight,/focused library with a > compatible license today, that tapestry could rely on, instead of > attempting to implement this on its own. > > This is obviously not a widespread problem, but it is one of correctness > and it tickles my OCD ;) > > -- > Chris > > On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski < > > raf...@juicycocktail.com> > > wrote: > > > > > Congratulations! Thanks to the core team for your continuous work and > the > > > effort you put into maintaining Tapestry. > > > > > > > Thanks! > > > > > > > I think the whole industry goes the way of trying to simplify things > > (just > > > take a look at the most recent programming languages & frameworks). If > > > we’re talking about modernizing and competing with other frameworks, I > > > would like to see Tapestry reducing the complexity that is currently > > > required to grasp the framework and its various concepts (which are > > > technically great, but sometimes hard to understand if you just start > > > working with Tapestry). I think this will only work by providing old & > > new > > > APIs at the same time and by making the upgrade path and improvements > > very > > > clear in the documentation. > > > > > > > Well, some stuff is indeed not simple, and I'd say the form support is > the > > part which could use some new components to make at least the simpler > > scenarios simpler to implement (for example, when there are no loops). > > Which other areas do you think could or should be simplified? > > > > > > > Personally I’m also getting into the vibe of smaller services that > > > communicate with each other, instead of this one monolithic giant that > > > tries to be everything, but is nothing in the end. We use > > bootique-tapestry > > > (and also other Bootique-compatible integrations). I would like to see > > > Tapestry to also go in this direction and improve integration on > similar > > > deployment environments. > > > > > > > We could definitely have some ideas to make microservices easier to build > > on the top of Tapestry-IoC. > > > > > > > On the other side, I’m currently pretty happy with the state of > Tapestry > > > and with the framework keeping up with modern Java versions. > > > > > > > Thanks! > > > > -- > > Thiago > > > -- Thiago
Re: [ANNOUNCEMENT] Tapestry 5.4.4
> On 2018-20-12, at 05:16 AM, Christopher Dodunski > wrote: > > Should simplification, then, be one of the declared objectives going forward? I would appreciate this as one goal of the future roadmap. Rafael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Hi all, "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupéry. Winsome words from a once French aviator. Perfecting Tapestry is unlikely to be a simple matter of just culling code. Still, it should be possible to do the basic things easily, and Tapestry's reputedly steep learning curve is a disincentive to newcomers. Should simplification, then, be one of the declared objectives going forward? Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
It would be great to see a fresh vision and roadmap for Tapestry going forward. Tapestry has many strengths, but has a relatively steep learning curve and does not do enough to help new developers get off the ground. We have been using Tapestry for a very long time and still find it challenging at times, especially when integrating Tapestry with newer client-side technologies. I saw your mention of bootique-tapestry and am curious how that is working out? We briefly looked at bootique-tapestry, but decided to create a module to integrate with Spring Boot instead. Spring Boot won out mostly because of the breadth of what it has to offer and the large user community. There are still a few rough spots in our Spring Boot integration, but the effort was very worthwhile. The combination of Gradle + Spring Boot + Tapestry is very powerful and greatly reduces the amount of boilerplate needed to create a production ready application. The integration with Spring Boot is surprisingly thin and the integration is nearly seamless. Anyone have a sense as to whether the community is interested in pursuing a first-class Spring Boot integration? I would be happy to share what we have done if there is real interest in making it a proper Tapestry feature. I don't think it would be a huge effort if some of the core Tapestry developers were engaged in the process. Having a supported integration with Spring Boot might bring much deserved attention and new users to Tapestry. Regards, David Congratulations! Thanks to the core team for your continuous work and the effort you put into maintaining Tapestry. I think the whole industry goes the way of trying to simplify things (just take a look at the most recent programming languages & frameworks). If we’re talking about modernizing and competing with other frameworks, I would like to see Tapestry reducing the complexity that is currently required to grasp the framework and its various concepts (which are technically great, but sometimes hard to understand if you just start working with Tapestry). I think this will only work by providing old & new APIs at the same time and by making the upgrade path and improvements very clear in the documentation. Personally I’m also getting into the vibe of smaller services that communicate with each other, instead of this one monolithic giant that tries to be everything, but is nothing in the end. We use bootique-tapestry (and also other Bootique-compatible integrations). I would like to see Tapestry to also go in this direction and improve integration on similar deployment environments. On the other side, I’m currently pretty happy with the state of Tapestry and with the framework keeping up with modern Java versions. Best, Rafael On 2018-19-12, at 11:02 AM, Christopher Dodunski wrote: Good team effort! It's encouraging to see Tapestry progressing in step with associated technologies: Java 12 is due out in March, and Hibernate currently at version 5.3.3. Tapestry 5 was a leap forward from 4. Where does the community see Tapestry 6 at on the Java web landscape? A free and frank conversation - Tapestry's strengths and weaknesses, what attracts others to JSF, Wicket and other competing frameworks, where web frameworks are generally headed, etcetera - ought to help ensure that Tapestry remains relevant beyond 2020. Regards, Chris. - 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
Re: [ANNOUNCEMENT] Tapestry 5.4.4
> On 2018-19-12, at 07:32 PM, Carlos Montero Canabal > wrote: > > I'm serving AMP pages with Tapestry ( > https://elcocinerocasero.com/amp/receta/tortilla-de-patata ). I hope to > upload an example to http://tapestry5.dev-util.com/ this weekend with the > workaround to do it... That’s great news, Carlos. Do you use a custom MarkupRenderer or did you choose another approach? > But yes, AMP and XHTML aren´t good friends... Yes, this is basically the main issue :) Best, Rafael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
> On 2018-19-12, at 07:01 PM, Thiago H. de Paula Figueiredo > wrote: > > What issue, exactly? Exact HTML output? If yes, this is something that > probably can be either fixed in Tapestry itself or customized implementing > a MarkupRenderer. Yes, this basically boils down to Tapestry not modifying templates when I don’t want to. A couple of months ago I researched the topic and found a similar answer in the archives. I tried to create a lightweight class AmpWriterFactory that implements MarkupWriterFactory, but it was such a hassle for a relatively small project that I gave up. Maybe I was on the wrong path? Rafael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Hello, I kind of agree with Rafael. I would really like to see tapestry core having no css or JS framework dependencies at all, server side only validation etc… And a pluggable architecture where you can add bootstrap compatibility os JS frameworks or form client side validation etc… The ability to start with a blank page, nothing in it added by Tapestry, and then the ability to progressively add stuff in the head or in the footer etc.. I don’t always want tapestry to render doctype or head tag etc… I know you can change everything by contributing configurations, but most of the time I need to remove/override contributions. I don’t want bootstrap, I don’t want Jquery. I want a custom doctype, head etc… Now the web development is more focused on the client, you write more JS than before, in the typical setup you would use webpack to compress js and minify scss, web components with React, Amber etc... With Tapestry you need to understand the internals to know what to remove or to add. Forms could be simplified, it’s one of the most complex Tapestry concept, because all other concepts are very straight forward and easy to grab. Form validation should always be expressed as simple data attributes per field or globally at the form tag level (that’s partially like this). Then you can contribute or mixin any type of validators or use custom js to parse your form. This would work great with loops, partial form or dynamic form rendering should be improved. Some other areas could also be simplified like links, activation context etc… Most of the people I explain tapestry to never understand why there are so many different types of links. Users want a link to a page, that eventually calls a listener with parameters and most of the time they prefer named parameters. I think there should be only one type of link with configurable options and good default values (optional page name, optional listener name, optional named parameters etc…) I would be very interested to hear Wicket users on why they prefer Wicket to Tapestry or which Wicket features they prefer. From my experience JSF is mostly used because it’s supported by big vendors, and you can start from a blank page with minimal dependencies if needed. Grails is pretty neat because it generates quite a lot of things for you, and it’s easy to use but it’s less powerful than tapestry in some aspects. Play like Grails has a command line generator that builds most of the skeleton for you, you just need to fill the “placeholders”, they all borrow concepts from rails. I think Tapestry is in between: in some aspects it includes too many features on others not enough. We should split tapestry in smaller pieces, and have a command line tool to generate all necessary parts of an application (web page, api/json endpoint, validator, type coercer, model etc..). This has already been done in the past but that could be improved. Just my two cents :) Numa > Le 19 déc. 2018 à 19:01, Thiago H. de Paula Figueiredo a > écrit : > > On Wed, Dec 19, 2018 at 2:03 PM Rafael Bugajewski > wrote: > >> The one thing that comes straight up from my head is the current >> complexity / pipeline necessary for generating output. A couple of months >> ago I wanted to generate valid AMP pages within Tapestry. After one day of >> research and a non-working proof of concept, I decided to use the Play >> framework for this small customer and it worked right away. Tapestry does >> some processing (necessary for other parts of the framework, AFAIK) that >> makes it hard to generate valid AMP pages. I would really love to use >> Tapestry here, and I don’t think it’s out of scope for the framework. >> > > What issue, exactly? Exact HTML output? If yes, this is something that > probably can be either fixed in Tapestry itself or customized implementing > a MarkupRenderer. > > >> >> Best, >> Rafael >> >> >> - >> 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
Re: [ANNOUNCEMENT] Tapestry 5.4.4
I'm serving AMP pages with Tapestry ( https://elcocinerocasero.com/amp/receta/tortilla-de-patata ). I hope to upload an example to http://tapestry5.dev-util.com/ this weekend with the workaround to do it... But yes, AMP and XHTML aren´t good friends... El mié., 19 dic. 2018 a las 17:03, Rafael Bugajewski (< raf...@juicycocktail.com>) escribió: > > On 2018-19-12, at 01:23 PM, Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > > Well, some stuff is indeed not simple, and I'd say the form support is > the > > part which could use some new components to make at least the simpler > > scenarios simpler to implement (for example, when there are no loops). > > Which other areas do you think could or should be simplified? > > The one thing that comes straight up from my head is the current > complexity / pipeline necessary for generating output. A couple of months > ago I wanted to generate valid AMP pages within Tapestry. After one day of > research and a non-working proof of concept, I decided to use the Play > framework for this small customer and it worked right away. Tapestry does > some processing (necessary for other parts of the framework, AFAIK) that > makes it hard to generate valid AMP pages. I would really love to use > Tapestry here, and I don’t think it’s out of scope for the framework. > > Best, > Rafael > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: [ANNOUNCEMENT] Tapestry 5.4.4
On Wed, Dec 19, 2018 at 2:03 PM Rafael Bugajewski wrote: > The one thing that comes straight up from my head is the current > complexity / pipeline necessary for generating output. A couple of months > ago I wanted to generate valid AMP pages within Tapestry. After one day of > research and a non-working proof of concept, I decided to use the Play > framework for this small customer and it worked right away. Tapestry does > some processing (necessary for other parts of the framework, AFAIK) that > makes it hard to generate valid AMP pages. I would really love to use > Tapestry here, and I don’t think it’s out of scope for the framework. > What issue, exactly? Exact HTML output? If yes, this is something that probably can be either fixed in Tapestry itself or customized implementing a MarkupRenderer. > > Best, > Rafael > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: [ANNOUNCEMENT] Tapestry 5.4.4
> On 2018-19-12, at 01:23 PM, Thiago H. de Paula Figueiredo > wrote: > > Well, some stuff is indeed not simple, and I'd say the form support is the > part which could use some new components to make at least the simpler > scenarios simpler to implement (for example, when there are no loops). > Which other areas do you think could or should be simplified? The one thing that comes straight up from my head is the current complexity / pipeline necessary for generating output. A couple of months ago I wanted to generate valid AMP pages within Tapestry. After one day of research and a non-working proof of concept, I decided to use the Play framework for this small customer and it worked right away. Tapestry does some processing (necessary for other parts of the framework, AFAIK) that makes it hard to generate valid AMP pages. I would really love to use Tapestry here, and I don’t think it’s out of scope for the framework. Best, Rafael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
> On 2018-19-12, at 02:26 PM, Chris Poulsen wrote: > > Perhaps it is possible to find a lightweight,/focused library with a > compatible license today, that tapestry could rely on, instead of > attempting to implement this on its own. I pretty much like this idea in practice. What I mean generally speaking: If there are bigger or more complex parts in Tapestry’s codebase that need a lot of effort to modernize or fix some smaller niggling issues, I would prefer to use a small library as a dependency if other people already implemented and solved the same problems. If we’ll find out in the future that the small dependency isn’t actually necessary, because we use even less parts from this library, we still can implement an alternative, more lightweight version. > This is obviously not a widespread problem, but it is one of correctness > and it tickles my OCD ;) I don’t think Tapestry has widespread problems at all, and the one huge problem, namely Java compatibility, is already worked on. That said, I feel you and the small OCD demon inside ;) Best, Rafael - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Hi Nice work on moving tapestry forward! It looks like the JDK updates may just land, before we can't postpone updating our stuff anymore *fingers crossed* ;) There are still something fishy in the property access / generics support implementation, I reported it some years back either on the list or in jira, but it never got much attention. I do not know if this will get more apparent as tapestry move towards newer runtimes. We are using some pretty complex data models with deep interface hierarchies and generics, and I ended up replacing the internals of GenericsUtils with calls to com.google.common.reflect.TypeToken (Guava) to get correct behavior (often tapestry would complain that some "setter" was not found or similar because it resolved the type to something higher in the interface/object hierarchy and missed the correct method override due to typing or something else. (I spent some time on attempting to fix the tapestry implementation, but ended up thinking it was a waste of time trying to replicate functionality that was already coded (more correctly) by other people, and picked guava as that was already present in our dependencies). Perhaps it is possible to find a lightweight,/focused library with a compatible license today, that tapestry could rely on, instead of attempting to implement this on its own. This is obviously not a widespread problem, but it is one of correctness and it tickles my OCD ;) -- Chris On Wed, Dec 19, 2018 at 1:23 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski < > raf...@juicycocktail.com> > wrote: > > > Congratulations! Thanks to the core team for your continuous work and the > > effort you put into maintaining Tapestry. > > > > Thanks! > > > > I think the whole industry goes the way of trying to simplify things > (just > > take a look at the most recent programming languages & frameworks). If > > we’re talking about modernizing and competing with other frameworks, I > > would like to see Tapestry reducing the complexity that is currently > > required to grasp the framework and its various concepts (which are > > technically great, but sometimes hard to understand if you just start > > working with Tapestry). I think this will only work by providing old & > new > > APIs at the same time and by making the upgrade path and improvements > very > > clear in the documentation. > > > > Well, some stuff is indeed not simple, and I'd say the form support is the > part which could use some new components to make at least the simpler > scenarios simpler to implement (for example, when there are no loops). > Which other areas do you think could or should be simplified? > > > > Personally I’m also getting into the vibe of smaller services that > > communicate with each other, instead of this one monolithic giant that > > tries to be everything, but is nothing in the end. We use > bootique-tapestry > > (and also other Bootique-compatible integrations). I would like to see > > Tapestry to also go in this direction and improve integration on similar > > deployment environments. > > > > We could definitely have some ideas to make microservices easier to build > on the top of Tapestry-IoC. > > > > On the other side, I’m currently pretty happy with the state of Tapestry > > and with the framework keeping up with modern Java versions. > > > > Thanks! > > -- > Thiago >
Re: [ANNOUNCEMENT] Tapestry 5.4.4
On Wed, Dec 19, 2018 at 8:41 AM Rafael Bugajewski wrote: > Congratulations! Thanks to the core team for your continuous work and the > effort you put into maintaining Tapestry. > Thanks! > I think the whole industry goes the way of trying to simplify things (just > take a look at the most recent programming languages & frameworks). If > we’re talking about modernizing and competing with other frameworks, I > would like to see Tapestry reducing the complexity that is currently > required to grasp the framework and its various concepts (which are > technically great, but sometimes hard to understand if you just start > working with Tapestry). I think this will only work by providing old & new > APIs at the same time and by making the upgrade path and improvements very > clear in the documentation. > Well, some stuff is indeed not simple, and I'd say the form support is the part which could use some new components to make at least the simpler scenarios simpler to implement (for example, when there are no loops). Which other areas do you think could or should be simplified? > Personally I’m also getting into the vibe of smaller services that > communicate with each other, instead of this one monolithic giant that > tries to be everything, but is nothing in the end. We use bootique-tapestry > (and also other Bootique-compatible integrations). I would like to see > Tapestry to also go in this direction and improve integration on similar > deployment environments. > We could definitely have some ideas to make microservices easier to build on the top of Tapestry-IoC. > On the other side, I’m currently pretty happy with the state of Tapestry > and with the framework keeping up with modern Java versions. > Thanks! -- Thiago
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Great news and great work Tapestry Team! El mié., 19 dic. 2018 a las 0:15, Thiago H. de Paula Figueiredo (< thiag...@gmail.com>) escribió: > You're welcome! > > Tapestry 5.5, supporting Java 11, will be released in the next couple > months at most. > > On Tue, Dec 18, 2018 at 5:54 PM Cezary Biernacki > wrote: > > > Thanks. It is good to see a new release. > > > > Best regards, > > Cezary > > > > > > On Tue, Dec 18, 2018 at 7:13 PM Thiago H. de Paula Figueiredo < > > thiag...@gmail.com> wrote: > > > > > Hello, everyone! > > > > > > Today the team released Tapestry 5.4.4, a drop-in replacement for > 5.4.x. > > > > > > This is a recommended upgrade due to including one security > improvement. > > > > > > Bugs fixed > > > [TAP5-2582] - Service creation for Hibernate Session results in > > > ClassFormatError: Duplicate method name > > > Improvements > > > [TAP5-2601] - Add configurable service to block access to classpath > > assets > > > [TAP5-2603] - Create HTML5-based date form field component > > > > > > -- > > > Thiago > > > > > > > > -- > Thiago >
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Congratulations! Thanks to the core team for your continuous work and the effort you put into maintaining Tapestry. I think the whole industry goes the way of trying to simplify things (just take a look at the most recent programming languages & frameworks). If we’re talking about modernizing and competing with other frameworks, I would like to see Tapestry reducing the complexity that is currently required to grasp the framework and its various concepts (which are technically great, but sometimes hard to understand if you just start working with Tapestry). I think this will only work by providing old & new APIs at the same time and by making the upgrade path and improvements very clear in the documentation. Personally I’m also getting into the vibe of smaller services that communicate with each other, instead of this one monolithic giant that tries to be everything, but is nothing in the end. We use bootique-tapestry (and also other Bootique-compatible integrations). I would like to see Tapestry to also go in this direction and improve integration on similar deployment environments. On the other side, I’m currently pretty happy with the state of Tapestry and with the framework keeping up with modern Java versions. Best, Rafael > On 2018-19-12, at 11:02 AM, Christopher Dodunski > wrote: > > Good team effort! It's encouraging to see Tapestry progressing in step > with associated technologies: Java 12 is due out in March, and Hibernate > currently at version 5.3.3. > > Tapestry 5 was a leap forward from 4. Where does the community see > Tapestry 6 at on the Java web landscape? A free and frank conversation - > Tapestry's strengths and weaknesses, what attracts others to JSF, Wicket > and other competing frameworks, where web frameworks are generally headed, > etcetera - ought to help ensure that Tapestry remains relevant beyond > 2020. > > Regards, > > Chris. > > > - > 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
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Good team effort! It's encouraging to see Tapestry progressing in step with associated technologies: Java 12 is due out in March, and Hibernate currently at version 5.3.3. Tapestry 5 was a leap forward from 4. Where does the community see Tapestry 6 at on the Java web landscape? A free and frank conversation - Tapestry's strengths and weaknesses, what attracts others to JSF, Wicket and other competing frameworks, where web frameworks are generally headed, etcetera - ought to help ensure that Tapestry remains relevant beyond 2020. Regards, Chris. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Marvellous news! Thank you very much to all involved. I’ll aim to bring JumpStart into line with it before the new year. Geoff > On 19 Dec 2018, at 7:15 am, Thiago H. de Paula Figueiredo > wrote: > > You're welcome! > > Tapestry 5.5, supporting Java 11, will be released in the next couple > months at most. > > On Tue, Dec 18, 2018 at 5:54 PM Cezary Biernacki > wrote: > >> Thanks. It is good to see a new release. >> >> Best regards, >> Cezary >> >> >> On Tue, Dec 18, 2018 at 7:13 PM Thiago H. de Paula Figueiredo < >> thiag...@gmail.com> wrote: >> >>> Hello, everyone! >>> >>> Today the team released Tapestry 5.4.4, a drop-in replacement for 5.4.x. >>> >>> This is a recommended upgrade due to including one security improvement. >>> >>> Bugs fixed >>> [TAP5-2582] - Service creation for Hibernate Session results in >>> ClassFormatError: Duplicate method name >>> Improvements >>> [TAP5-2601] - Add configurable service to block access to classpath >> assets >>> [TAP5-2603] - Create HTML5-based date form field component >>> >>> -- >>> Thiago >>> >> > > > -- > Thiago - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [ANNOUNCEMENT] Tapestry 5.4.4
You're welcome! Tapestry 5.5, supporting Java 11, will be released in the next couple months at most. On Tue, Dec 18, 2018 at 5:54 PM Cezary Biernacki wrote: > Thanks. It is good to see a new release. > > Best regards, > Cezary > > > On Tue, Dec 18, 2018 at 7:13 PM Thiago H. de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > Hello, everyone! > > > > Today the team released Tapestry 5.4.4, a drop-in replacement for 5.4.x. > > > > This is a recommended upgrade due to including one security improvement. > > > > Bugs fixed > > [TAP5-2582] - Service creation for Hibernate Session results in > > ClassFormatError: Duplicate method name > > Improvements > > [TAP5-2601] - Add configurable service to block access to classpath > assets > > [TAP5-2603] - Create HTML5-based date form field component > > > > -- > > Thiago > > > -- Thiago
Re: [ANNOUNCEMENT] Tapestry 5.4.4
Thanks. It is good to see a new release. Best regards, Cezary On Tue, Dec 18, 2018 at 7:13 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > Hello, everyone! > > Today the team released Tapestry 5.4.4, a drop-in replacement for 5.4.x. > > This is a recommended upgrade due to including one security improvement. > > Bugs fixed > [TAP5-2582] - Service creation for Hibernate Session results in > ClassFormatError: Duplicate method name > Improvements > [TAP5-2601] - Add configurable service to block access to classpath assets > [TAP5-2603] - Create HTML5-based date form field component > > -- > Thiago >
[ANNOUNCEMENT] Tapestry 5.4.4
Hello, everyone! Today the team released Tapestry 5.4.4, a drop-in replacement for 5.4.x. This is a recommended upgrade due to including one security improvement. Bugs fixed [TAP5-2582] - Service creation for Hibernate Session results in ClassFormatError: Duplicate method name Improvements [TAP5-2601] - Add configurable service to block access to classpath assets [TAP5-2603] - Create HTML5-based date form field component -- Thiago
