On Sun, 06 Feb 2005 20:19:01 -0600, Joe Germuska wrote: > I have just committed the suite of changes I was emailing about a > few weeks ago. Please be aware that nightly builds are probably > now the least stable that they've been in some time. I have spent > some time this weekend working on a simple site using the new code > (including struts-taglib and struts-tiles jars build from SVN head) > and things aren't horribly broken, but there may be some quirks. > Odds are good that most of them have to do with the > ServletActionContext class not always putting things in request > scope that JSPs or utility classes are accustomed to retrieving > from the request scope. I find it kind of odd to store things in > both places, but it seems like a necessity for a while for > backwards compatibility.
Yes, we're paying penance for past sins now :) Exposing the framework to the page through a coherent API object in the request is probably the biggest "coulda-shoulda" to date :) But, I'm very sure the evolutionary pain will be well worth it in the end ;) I've been working on a C# implementation of Commons Chain for use in my own project. It's going quite well, but I'm waiting to get through the current iteration before posting the code. > I hope to continue using this code as I begin prototype work on a > new project, but of course, the more people who can get their hands > on this code, the better. +1 -- the very best way to write framework code is the context of an actual project. > This also installs the "split" between the "process-action" and > "process-view" sub-chains, although I haven't yet changed the > SelectInput command to return "false" to eliminate the need for > later commands to check to see if the form was valid. > > I think the big outstanding question in my mind now is what kind of > context we want to pass into the "process-view" subchain. In some > earlier discussions, there was talk about a "ViewContext" -- I > haven't touched that at all, but I'm whether it's worth > distinguishing that from the ActionContext. The idea behind the ViewContext is that it is a specialized facade designed to tell the tags (or other tools) what they need to know, the way they want to know it. It would also be some thing that would be easy to mock, for testing tag and tool code in isolation. I'll start working up an API based on what teams like the Velocity Tools crew designed. If we do need one, it would probably use the ActionContext via composition. > As it is now, I have > my own command which sometimes gets used in the view chain and > sometimes in the action chain; as it is now, I have to test whether > the context is an ActionContext or a ServletWebContext -- I need to > get to the request parameters and scope/map, and by not using the > ActionContext in the view, it seems more awkward than it should be. > > It would be pretty easy just to change the chain-config.xml file to > use the new WrappingLookupCommand so that the same ActionContext > gets sent into both "halves," but I didn't want to do that just > yet. I'd like to hear if anyone has justifications for a different > kind of context for a "ViewContext" (noting that I have one real > use case where the same command is used in both sides, so a > ViewContext would be just as awkward as what I have now.) I was > also wondering whether we ought to routinely put the context into > the request scope so that that object is available to view > technologies like JSPs and Velocity templates. It seems like it > would be handy. The last sentence is the use-case for a ViewContext. The use-case is not within the RequestProcessor but without. The ViewContext is the specific API we want to expose to the presentation layer, as opposed to the control layer. So, the ViewContext has no semanticas in regard to navigation and may have additional semantics in regard to rendering. Following the well-worn Velocity philosophy, we want the ViewContext to be read-only, free of HTTP and navigational semantics, and easy to mock for testing view tools (and only view tools). What you see is what you want :) > So, for the brave, please dive in and start trying to apply the SVN > head to some applications and help to flush out anything that's not > quite right... Thanks for staying on this Joe. You're the man! > > Joe --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
