On 1/4/02 4:14 PM, "Humberto Hernadez Torres" <[EMAIL PROTECTED]> wrote:
> 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. Yes, they can grow in size. We have only been using pull tools in Tambora for a couple of months now and we have a rather large tool that certainly needs to be broken down. The pull provides a certain set of functions but in our particular case I don't think it conveys the model of Tambora very well. The first shot at making the pull tool was an attempt to localize some functionality that we wanted to share. > 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. Ultimately I think what would be best is a mechanism to allow designers to access the model of your application in templates in a more defined manner. So instead of accessing pull tools directly, you might make the result of a method provided by a pull tool available in the templates. Again I hold to the argument that you could get away with $scalar references, simple and #foreach in templates if there was a ModelManager or ModelAdapter that managed how references were made available in templates. I personally think that pull tools can encourage too much logic to be placed in the templates. The pattern that occurs over and over again in some of the Tambora templates is as follows: --- #set ($modelObjectOne = $pullTool.modelObjectOne) #set ($modelObjectTwo = $pullTool.modelObjectTwo) ... #foreach ($item in $modelObjectOne) ... #end This is you $modelObjectTwo --- So really what is happening really is the 'scalarizing' of model information. I think if this could be done outside of the templates I think we would move closer to an MVC model. > 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? I think pull tools can help that, but I don't think a set of pull tools provide coherent access to the model. By that I mean that some of the logic that crops up in templates due to pull tools (Look at Tambora and Scarab) can get rather scary pretty fast. Ok for a programmer to deal with but your designers would probably rather not deal with it. > -- > 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]> -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
