Exactly, this is why I have been shy about using pull tools. It seems hard to modularize the pull tools and you may end up with a very big one. In addition to that, you may have several pull tools depending on the scope (global, session, request). It seems to me that pull tools should group similar functions rather than similar scope.
As an interesting note, one of my coworkers pointed out that pull tools seem to follow the "Facade" design pattern. From Erich's Gamma book here is the description of the Facade Pattern: "Intent .- Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. Motivation .- Structuring a system into subsystems helps reduce complexity. A common desing goal is to minimize the communication and dependencies between subsystems. One way to achieve this goal is to introduce a facade object that provides a single, simplified interface to the more general facilities of a subsystem." Thus the pull tool (the facade) makes easier for the designer to use a simplified interface rather than having to understand the whole object model of the application. Right? -- Humberto -----Original Message----- From: Scott Eade [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 4:42 AM To: Turbine Users List Subject: Re: When to use screens vs. actions 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
