Daniel Fagerstrom said: > Naming > ====== > > The goal is that the new template framework should replace JXTG and XSP > as the "recomended" template system for Cocoon users. It is a community > effort rather than a one man show. It is based on our previous experince > of templating solutions. > > This should IMO be reflected in the naming. The name should reflect the > intended purpose rather than being a "brand" name. "JX" in > JXTemplateGenerator comes from JXPath and as we are going to provide > support for other expression languages as well, JXTG 2.0 would not be a > logical name for the framework IMHO. > I would propose that we (analogous with CForms) refer to it as > "template" in block name, package name, name spaces and so on. When it > actually delivers what is promised, we can refer to it as Cocoon > Template or CTemplate.
I like template. It is simple and to the point. > > To show that we care about our users previous investments in Cocoon > technology, we can say that JXTG has been re-implemented as a Cocoon > Template tag lib. > > Of course other and better naming sugestions are most welcome. > > > Tag "Interface" > =============== > > What data should be available for the taglib writer and how should it be > made accessible? What about thread safety? Why wouldn't it be thread safe? I would think this would need to be a requirement. > > Expressions > ----------- > > This is somewhat OT in the current context but IMO expressions, (the > stuff inside ${}), should only have access to FOM and preferably just > read access. IMHO expressions should not have side effects. There should be a way to register objects for use by the template so that flow is not a requirement. Of course, the template should also be able to access the request and response. > > What Data in Tags? > ------------------ > > A tag need access to: > > * FOM > * The current XMLConsumer for output > * The content of its attributes > * The content of its body (the possibility of executing the body and > geting the result) > > The following data is also useful for some tag libs: > > * A variable stack for handling local variables in tags or macros > * The tag repository > * The source resolver > * The component manager (e.g. for geting a DB connection) > * Its parent tag > * The content of its body (the possiblity to get the body unevaluated) > > IMHO tags should behave as if they are side effect free. Side efects > should be performed in flowscripts. From this we can infer that we only > should have read access to the above data. But in practice it might be > hard to enforce and furthermore even if the tag behave as it is side > effect free, it might be better (or the only possiblity) to implement it > in terms of side effects. > > Implementation details are discussed in the section "Adding Executable > Tags" in > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110132582421156&w=2. > > Have I forgotten something or should we remove something? > > How to Make Data Accessible in Tags > ----------------------------------- > > There are two main type of events in the life cycle of a tag: setup and > execution. For a thread safe tag, the setup phase can be divided in: > script compile time setup and execution time setup. > > The relation between the tag and the framework has many parallels with > the relation between a component and a component manager, so similar > solutions are possible. > > We can have reflection based solution with setter injection of > attributes and possibly the rest of data also. We can have interface > driven injection, (Avalon framework style), where the tag implements > various interfaces for geting the various input data types. > > We can also have more "static" solutions where the tag has to implement > a certain interface and get all the data with methods in the interface > or in one large context object. > > Reflection based methods are more flexible, but should probably only be > performed during script compile time setup, due to keep good performance. > > See the above reference for examples and more details. > > Thread Safe or Not? > ------------------- > > Thread safe tags can have better performance as more work can be done > during script compile time, but they might be harder to write. What > should we chose or should we support both types? Thread-safe. If need be, the there can be a setup method that returns an object that is passed back to all other methods. Since the framework "owns" the returned object it can decide when to drop the reference. Ralph