> > >>> How does depending on Avalon Framework limit reusability? You'll have a >>> really tough time convincing me here... >> > <big snip explaining why not - ending with> Anyway, hopefully that > somewhat explains the obstacles in the of using me Avalon and why I > turn to Commons stuff regularly.
By discussing both Avalon the what, and Avalon the how, this discussion itself has become a big ball of mud. Even Peter Donald explains why 50% of the time he doesn't use Avalon the how. And Avalon the what is discussed to infinite detail. But this misses the point in at least one sense, which I think is the essence of what Avalon can offer. When it works like Legos, Avalon is fulfilling it's promise. When it doesn't for any reason, be it documentation or interfaces that are changing too often to solidify into a Lego bolt up, Avalon is just another PITA with lots of promise. Big balls of mud come in many forms, not just at the class and method call levels. The ultimate conumdrum is that the last people that need it are the ones who are developing it. Talent such Lorin and the rest hardly needs a Lego boltup. The opposite end of the same coin is just as true. Idiots like me who are more interested in building WITH the blocks than building the Lego blocks themselves, are hardly good candidates for an additional layer of difficulty. The best situation is a mature set of Legos that requires no documentation because it works so well together that it just falls into place. I personally believe that this is much closer to doable than others who are actually doing it (of course). But the sad part is that the one thing that would make this possible is maturirty and stability, which make it hardly a fun proposition for the true contributors. In conclusion, the idea is not to "Change" other apache projects by making them adhere to a set of rules, as in, we win, they lose. Apache projects work wonderfully in singles, but in groups of four or more, they are a guaranteed ball of mud. The opportunity is in providing "bolt ups" for existing projects where you could use A, D, F, and N, and maybe later also L and W and even K, without designing all custom wireups. This is only possible through Avalon or something like it. The focus is on the boltup, not the code itself. I re-affirm my initial assertion, you guys don't know how cool it is what you got. But it is only your somewhat advanced skillset, understanding and amazing energy that keep this from happening. If you were dumber and less informed, and lazier, like me, it would become more obvious. Meanwhile, do I really have to refactor Struts to use it in Avalon? I would rather leave it as much as I can like it is, so that when they keep changing it I can follow them, not lead. Again, I was more interested in the boltup than in the re-engineering part. Same with JSTL. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
