Hi! On Sat, Sep 30, 2023 at 8:27 PM Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote:
> I'm sorry for the very late answer. No worries there. > It's been quite an eventful period in my life. > Hope you're doing well! > I'm afraid I'll disagree with you here. I've never been concerned on > keeping Tapestry-IoC modules simple, without much logic. As far as I > know, Tapestry itself never had that goal either (but I can be wrong, > of course). Sometimes configuration logic is inherently complex. Also, > it's possible to move this run-or-not-run logic to the command itself > making changes to ChainBuilder: create a method in your command to > return whether it should be contributed to the chain or not and have > your module code call it. > After reading your perspective, I have to agree that I went down the wrong path here. The modules are the point of IoC configuration, and moving some of the setup logic into the ChainBuilder itself would hide how the container will end up after Registry startup. In that case, I prefer the command to not be contributed, so it's > never run if it's not supposed to run. You get a smaller stack trace > and a little number of CPU cycles saved, a smaller chain and simpler > chain logic. > That was my origin of thought, too, as I like to save some CPU cycles, and anything to have shallower Java stack traces is welcome. But I should do it like you said, with a method on the service itself if I'm hell-bent on having the simplest modules possible. It's very rare when you propose something and I'm not immediately > convinced, Ben, but I'm afraid this is the exception that proves the > rule. :) > Filtering out the bad ideas before I get started working on them will give me more time for the better ones ;-) Cheers!
