Thanks again Ted, I didn't mean to imply that my View developers were also developing their own Tags. They aren't. Instead, I develop the Model, which includes back-tier business logic to perform actions, and return a bean (or a collection of beans) as a result. High-level business method names like:
postMessage deleteMessage getMessageByID getMessagesByTopic getUserByID getUsersByGroup getLogEntriesByUser Then, my Struts actions delegate all of their "real" work to these back-tier business methods, and in many cases, put the resulting bean (or bean collection) straight into the Request scope and forward on out to a JSP page. In terms of this model-rendering discussion, however -- I also tend to implement JSP custom tags which call out to these same business methods -- usually the "getXXX" variety, and almost never any other kind (in other words, only those methods which *read* the model). In that way, the View (JSP developers) can render the beans returned by the preceeding Action, and anything else they darn well please, by way of my published JSP Tag library (which is just a mirror of all my model-tier's "getXXX" methods). Now that I've fully explained my methodology, let me say that I am with you that perhaps this is coupled tightly to the Model (although not at all to the Controller). Where I don't follow you is how there's any other way (e.g. your Layered pattern) to achieve the same results. Perhaps what you're saying between the lines, is that rather than implement custom tags, I should be implementing more "smarter JavaBeans" which can navigate the model. You're right that this reduces my dependency on JSP tags, and opens the door to other presentation engines like Velocity. I think I'd like to give that a try. Historically, virtually 100% of my JavaBeans have been simple Value Objects, composed of nothing but properties, getters, and setters. So let's assume that, for the benefit of the View, the model-reading methods I was previously wrapping into JSP tags I will now wrap into smarter JavaBeans (to be navigated by way of Struts or JSPTL tags). Moving forward, then, do you think it's a bad idea to give them model-specific JavaBeans, or should I seek to wrap up my model in generic, non-specific collections of properties, which I am guessing is similar to your ContextHelper class (or Craig's new DynaBean, which I am eager to work with)? Thanks for this great discussion, Bryan
