on 5/19/02 7:37 AM, "Bill Boland" <[EMAIL PROTECTED]> wrote:
> Jon, > > To me, this is just a higher abstraction of the Pull vs. Push MVC Model > that was authored by you in Turbine > (http://jakarta.apache.org/turbine/turbine-2/pullmodel.html). It gives > the Java developer control to say which tools are safe for template > designers to use (pull) into any pages that the tool loader tool is > available in the context. If you don't want them to pull any tools, > don't put the tool loader tool into the context. If you want three tools > to be pulled (format, math, myCustomTool), place those into the map, > include the tool loader tool in the context and allow the template > designers to pull out the tools they need for the templates they work > design. Please read the article again. You are mistaking my intentions around the Pull Model. It isn't about 'Pulling Tools into the Context'. It is about having the tools made available in the context and 'pulling data from the tools'. As I already said, pulling tools by instantiating objects and defining their scope in the template is wrong. At that point, you are essentially putting WAY to much logic into the hands of the web designer. This is the SAME problem with taglibs. You define the scope of the taglib in the page. That isn't MVC. I even discuss this issue of scope in the template: <http://jakarta.apache.org/velocity/ymtd/ymtd-javabeans.html> Think in terms of someone who is editing the template who has no idea of what a tool even is. All they know is that if they put '$ticker.getSymbol("RHAT")' into the template that they will get a number as a result. > I just didn't feel that the "approved" tools (if any) should be > constructed until they are really used for a specific template and the > template designer should know them by a "common" name, not a class name. > "Lazy" construction of the tools just allows for improved performance > for templates that don't use any/all of them. There is no reason to do that since those type of tools are essentially 'global' tools and are just sitting in the context not doing anything so they aren't hurting anything performance wise. Experience also says that the global tools will eventually be instantiated anyway so you might as well do it up front as part of the startup cost. There is no real benefit to have lazy instantiation of tools. > Of course, there could be further evolution of this to allow Java > developers to declare "global" tools and template-specific tools. I > think this is what the Views sub-project in velocity-tools is trying to > do (still learning here so I may be wrong). I'm just looking for higher > abstractions to "declare" the tool availability vs. coding. Eventually, > it would be nice to have the ability to declare something like the > following that the central template engine would use to prepare the > context prior to merging them: > > *.vm: formatTool, myCustomTool > orderForm.vm: mathTool > home.vm: newsTool No. You really don't need that level of control and even if you did, that would be done in the framework, not by coding the instantiation of tools in the actual templates. Here is why: Say you have a designer who knows only a little bit about programming. They want to do something cool and put the stock ticker into their random page. Now, why should they have to come back to you to edit a configuration file or define something new (ie: your example above) that allows them to access the tool? Instead, they should just have an API that you provide that tells them what tools and methods they have access to. Done. Less headache for everyone. You can also do things like have the tool control its own security so that it can tell (by the webapp framework) what template it is in and decide whether or not to render itself. We do something like this in Scarab with the LinkTool and it works quite well. > There so much out here, that this may exist already and I just haven't > come upon it yet. Having tools (and tools for tools) be flexible for the > many various projects that exist in the world is a great challenge. > Every one doesn't wear the same size or style of shoe and some go > barefoot! You really need to spend more time with Turbine3. Cause we have already solved quite a few of these problems and are developing Scarab as a sort of test case to show that this stuff really is the right way to go. > I'm learning, listening and contributing. Spend time with Turbine before you start doing anything more. Look at how we do things and then comment on that. You may also wish to read the archives of this list and the turbine-dev list. There is *years* worth of discussion about this stuff. -jon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
