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
