From: "David Wynter" <[EMAIL PROTECTED]> > Having watched the mailing list closely it was evident that screen classes > were going the way of the Dodo. So in preparation for T3 we used Actions and > Pull tools. We put all pull tools in one class after some discussion about > whether the OR classes should carry out this function. It was decided that > there were quite a lot of joins being made that was not appropriate for the > OR classes, they provide a support role. The downside is that this Pull tool > class has become fairly large and unwieldy.
My pull tool is bigger than yours!!! ;-) Seriously though, I too had/have a lot of functionality concentrated in a single pull tool. I did actually move a bunch of the code back into the torque classes and this simplified things quite a bit. Before my template may have included a couple method invocations to my pull tool, but more often this is now one method invocation on the pull tool and another on the result. This has worked really well and I am much happier with the size and complexity of my pull tool (I can't help it, I have to laugh when I write this). My application splits functionality between four groups of users and I have recently given consideration to splitting the pull tool into two or even four separate pull tools that support these different groups of users. In one case this will simplify things greatly as there is a particular group of users whose functionality is limited in in a certain way that might be more consistently enforced using an isolated tool. > To add to what has been said below, our Action classes are required to build > quite a bit of the context due to the omission of the Screen class. The Pull > tool needs to have the primary keys of all the entities it needs to flesh > out for the screen so these have to come from the Action class. So our > Action classes are split into 2 sections, process the form and do the > database operation/s, then in the 2nd section dependent on the result, build > the appropriate context, including error messages if required. Other ways to get the primary keys are to pass them as query data or to retain a limited set in User.Temp. I find these methods work very well - the only time I use an action is when a form is involved. HTH Scott -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
