On 5/20/02 11:14 AM, "Jeff Duska" <[EMAIL PROTECTED]> wrote:
> I'm lost at the issues here. Can someone please summarize the issues or > point out some stuff in the archives? I'm very confused. I don't see how > ToolLoader mixes up the model and controller into the view. It doesn't mix model and controller necessarily. Tool loading like this can be dangerous depending on what can be specified for the load. If it's is a preconfigured set of classes, it's no different fundamentally than a controller-fed context, where the tools are placed into the context by the controller for the view to use. The only difference between a loader and the controller doing is is that the template has the freedom to call the tool what it wants, for whatever that is worth. If it is not a preconfigured set of classes, then it can be very dangerous if you are allowed to specify the classname you want. Bill's tool came from (in part) my mention of a facility I put in another scipty language I did for a workflow engine. Even then, I limit the classes that the template author can ask for. There is a difference - in my workflow system, the script is really a controller. That said, I don't trust the controller author either, so I limit the tools available :) And in special cases, where the tool involves heavy lifting of sorts (for example, there is a tool that maintains continuous connections to a server), that is pushed into the context by the underlying framework when needed - it isn't made available in the tool creation facility... > > I'm only looking at this for the point of using the VelocityViewServlet, > which I like a lot. This means I don't have to create a class for every > template file I create. This seems like a big advantage, but Jon seems > to be implying that part of the VelocityViewServlet -- ToolLoader is > flawed because it mixes the model and the controller. Plus, it has > already been done better in Turbine. Third, he also seems to be the > implying that this is not a Pull method, which I thought it was. I hope > I've actually summarized Jon's issues. If not, please please feel free > to correct me. First, you generally don't have to make 1 class per template. I am horribly lazy, and generally have one controller servlet for my apps, and then 'action methods' are invoked within that servlet and they return the template to be rendered (after filling the context with appropos data). So the 1 class == 1 template can be easily avoided. VVS and Turbine aren't comparable. VVS isn't an application framework (although you could build one around it). VVS was originally meant to be a rendering servlet a la JSPServlet, so we could have a view system that could be added to JSP-centric frameworks like Struts. Turbine is an application framework, with all the support one might expect. It is a competitor to Struts. > > My questions are: > . What if I don't want to use Turbine? I may want to use Struts or an > Oracle framework, but I don't want to give up using Pull method with > Velocity. That's the point of VVS + the Struts tools - so you can use Vel with Struts. > . Can some explain why ToolLoader is bad? What is good? > . Isn't this a Pull method? > . If Turbine has indeed done this already, can we refactor functionally > out so it doesn't depend on Turbine? > > > Thanks, > > Jeff > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Geir Magnusson Jr. Research & Development, Adeptra Inc. [EMAIL PROTECTED] +1-203-247-1713 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
