On Wed, Dec 19, 2018 at 11:26 AM Chris Poulsen <mailingl...@nesluop.dk> 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
