I can see developers being tempted to build their whole app around pull tools. When this happens you start working at the level of something like Cold Fusion . Not that Cold Fusion is bad, because I've done quite a bit of work with it and it is a good product. The issue is that. IMOHO, Cold Fusion doesn't easily provide you with MVC separation and in the end you lock up business logic within the template itself.
I think this tends to happens in most template based application environments, including ASP and I think PHP(can't really say since I haven't used it). In my experience with Turbine (which approaching the 6 month mark :-) I have tried to create my pull tools in such away that they provide very specific functionality and are relatively small in size. Here are a few examples of what I have done. This is just my approach and it works for me. Others in the group may disagree with what I have done , but like I said, I'm happy with it. Utility: HtmlTagAttribute: formats value pairs into xhtml tag attributes. MessageParserTool: returns a message list from "\n" terminated strings in $data.Message. Rendered with macros. VelocityTemplatePageAttributes: extends TemplatePageAttributes so that $page works correctly for those using VelocityOnly layout. Model Access: StoreTool: peer/OM |--> Store Service (Abstracts access to Torque om) |--> StoreTool CustomerTool: peer/OM |--> Customer Service (Abstracts access to Torque om) |--> CustomerTool (Note: the pull tools NEVER allow the web designer to alter perm storage, i.e. no update/insert/delete) Navigation: optiontool: interfaces with my Option Service which groups hierarchical navigation options that are stored in an XML doc. However, rendering is done via macros to allow web designers to create the look of the menu/navigation. Security: Guardian: interfaces with my Guardian Service which checks a users ACL against security requirements for that template. Security located in an XML doc. Scott -----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 11:05 PM To: Turbine Users List Subject: Re: When to use screens vs. actions 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
