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 >
