On Thu, 10 Oct 2024 23:26:27 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
> You say a "bunch of event handlers" is less optimal; then optimize that. It's > already there. In fact, a simple utility makes it a one-liner... Let me know if I understood you correctly: Let's consider an example where the application has a complex form and the product people asked for a keyboard navigation sequence that depend on let's say the form content. Maybe they have a grid of input fields and they want TAB key to either go down if the row is filled, or go right if the row is blank - it does not matter, these requirements are not a subject of discussion as they came from the high up. So you propose to add an event handler to each input field where each event handler contains the necessary logic (dozens of those)? Am I right to assume that in this case the logic is all scattered across many event handlers creating testability issues and wasting oh so much memory on the event handlers (we have gigabytes, so who cares)? Now we have a new requirement after a while where some fields get removed, some added, the logic changes, and now we need to modify that. So, following your suggestion, we just modify each handler with the new logic, carefully making sure that our changes are ok, right? Or maybe you want to add these handlers, but delegate the logic to a single class, at least one which can me easier to maintain? Still, a bunch of individual EHs but now we have a centralized facility that decides where to go depending on the form content? Are these scenarios describe your event handler suggestion? (We are going to skip for the moment the case when skins change as a result of the user changing something in the UI preferences and all our EH fail due to https://bugs.openjdk.org/browse/JDK-8231245 ) I just want to make sure I understand your suggestion. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2407785308
