> I understand your point of view while not sure this is the correct > interpretion to see a page as a "transaction". If there are forms, maybe > you can see it that way but a page is usually a way to present information/ > data. > > I had some time to work with RoR lately and the way it evolved in the last > years and also solved many problems with clever convention over > configuration let me rethink some of my previous ways. > Also backend frameworks like e.g. micronaut have baked in things like > retryable or CircuitBreaker because they just *expect* it that something > will fail anytime anyhow. > > In our prod app we got a 500 because of a dumb null pointer that happend > because of a rare race condition depending on the backend... something that > was clearly a fault initially but only with the current way to fail the > whole page made it a problem. > > The idea is just to not fail a whole page but only the part of the page > that fails - while logging in the backend so that the usage of the page is > not 0 but maybe still 80% >
If you are ok with a 80% failing page, I cannot help you, because in that case you can simply come up with another fallback which works 80%. You know this leads/creeps to exponential growth of failures and work, yes? The right way to handle it is to inform the user that something has failed, suggest the user to retry (or you can retry once programmatically if you think the problem is rare). And receive alerts from such problems in production and find the root cause and fix it, for example by fixing a race condition issue by adding blocking queues or whatever best suits your use case. And from my experience I never expect my code to not have bugs in it, so it > will fail at some point. I mean, why do we have so many regular wicket > releases if its bug free? ;) > Is not about being bug free, but how to respond to bugs and how to curb bugs and how to curb the impact of bugs. > PS: can you elaborate how to globally alter the sub panel phases? > You can make your own panel which you reuse/extend everywhere and add custom logic to it. You can also fork wicket if it is not to your liking. You an remove the rendering exception from your copy of wicket alltogether. ** Martin
