[Cocoon Wiki] Updated: TemplateEngineDesign

[do...@cocoon.apache.org]

   Date: 2005-02-14T06:46:01
   Editor: DanielLaLiberte
   Wiki: Cocoon Wiki
   Page: TemplateEngineDesign
   URL: http://wiki.apache.org/cocoon/TemplateEngineDesign

   spelling fixes

Change Log:

------------------------------------------------------------------------------
@@ -1,6 +1,6 @@
 = Template Engine Design =
 
-For the original post, see [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110132582421156&w=2]. The idea is to keep this design document updated to reflect the implementation, this far it is just a slightly editet version of the post. 
+For the original post, see [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110132582421156&w=2]. The idea is to keep this design document updated to reflect the implementation, this far it is just a slightly edited version of the post. 
 
 Here are some ideas about how to implement JXTG 2.0.
 
@@ -11,7 +11,7 @@
 to trying to implement JXTG2 on top of them. It is certainly a good idea 
 to reuse ideas and code from JXTG. One could possibly start from JXTG 
 and go to JXTG2 through a sequence of refactoring steps, but the 
-monsterous size of the implementation of JXTG makes that less atractive, 
+monsterous size of the implementation of JXTG makes that less attractive, 
 at least for me. I would probably start from Jonas taglib as it contains 
 some things that we are going to need any way and is a good starting 
 point. Anyway it is IMHO a good idea to take a look at it, and see that 
@@ -30,12 +30,12 @@
 == A Trivial Pre-Compiled "Template Generator" ==
 
 This step is not that useful in it self, the result will just be an 
-unnesecarilly complicated implementation of the file generator. This is 
+unnecessarily complicated implementation of the file generator. This is 
 for introducing some ideas.
 
 The pre-compiling TG works in two steps: First it compiles the content 
 of the input source to a script, and store the script in its cache 
-together with an approriate cache key. Then the cached script will be 
+together with an appropriate cache key. Then the cached script will be 
 used as long as the cache key is valid. It is important that the script 
 is thread safe otherwise it will be unsafe to reuse. As store, Cocoon's 
 transient store could be used.
@@ -45,7 +45,7 @@
 === The Trivial Script ===
 
 The task of the trivial "template generator" is to output its input 
-template document as is :) For this task there allready is a feature 
+template document as is :) For this task there already is a feature 
 complete script implementation in Cocoon; {{{o.a.c.xml.SAXBuffer}}}.
 
 The {{{SAXBuffer}}} contains a list of {{{SAXBits}}} where each {{{SAXBit}}} is an 
@@ -71,7 +71,7 @@
 the XML attributes and text. These expression are replaced with the 
 result of evaluating the expressions in some context. To add this to our 
 TG we need to define the context, get a expression evaluator and handle 
-the expression embeding in the script.
+the expression embedding in the script.
 
 === Expression Language ===
 
@@ -79,10 +79,10 @@
 ;) But as that not is going to happen we need to support several 
 expression languages (EL). This is not just a need in JXTG but also in 
 CForms, input modules and many other places. So we have a need for 
-plugable EL in Cocoon.
+pluggable EL in Cocoon.
 
 Dmitri Plotnikov, the main author of JXPath have written a common API 
-for EL [http://www.plotnix.com/jex/index.html], and commited the code to 
+for EL [http://www.plotnix.com/jex/index.html], and committed the code to 
 Jakarta Commons Sandbox 
 [http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/jex/]. AFAICS 
 the project never took off so we shouldn't use it. But we could probably 
@@ -94,17 +94,17 @@
 compiled expression is thread safe), we can get better performance by 
 storing compiled expressions in the script.
 
-Besides plugable EL we also want to be able to plug in a locale 
-sensitive and configurable convertor
+Besides pluggable EL we also want to be able to plug in a locale 
+sensitive and configurable converter
 component for handling the results from the EL.
 
 Now, we don't have to implement everything at once. We can start with 
-suporting one EL and refactor to using the plugable EL, when/if someone 
+supporting one EL and refactor to using the pluggable EL, when/if someone 
 implements it.
 
 === Expression Context ===
 
-The expresion must be evaluated in some context. JXTG have a lot of code 
+The expression must be evaluated in some context. JXTG have a lot of code 
 that package the different objects in the Cocoon object model so that it 
 looks the same way as in flowscripts, but from JXPath or JEXL. Carsten 
 have factored out the code from JXTG to 
@@ -113,7 +113,7 @@
 we should base JXTG2 on that (and possibly improve it) rather than 
 having still another implementation of the script object model.
 
-=== Embeding Expressions in the Template Language ===
+=== Embedding Expressions in the Template Language ===
 
 In the TL we are using expressions like this:
 
@@ -141,7 +141,7 @@
 expressions like I described above. During script compilation time they 
 need a EL factory. During script execution time they need a expression 
 context, so their interface must be extended with something like 
-{{{send(ContentHandler, ExpressionContext)}}} and simillary the script 
+{{{send(ContentHandler, ExpressionContext)}}} and similarly the script 
 (extended {{{SAXBuffer}}}) need a method {{{toSAX(ContentHandler, 
 ExpressionContext)}}}.
 
@@ -156,7 +156,7 @@
 and compare them with the corresponding tags in e.g. taglib and decide 
 for yourself what you prefer.
 
-For concretenes lets say that we have a for-tag in our TL (example from 
+For concreteness lets say that we have a for-tag in our TL (example from 
 Jonas):
 
 {{{
@@ -166,7 +166,7 @@
 }}}
 
 We have a {{{TagRepository}}} where URI and tag name is mapped to a tag 
-object. Tags that are registred in the {{{TagRepository}}} (executable tags) 
+object. Tags that are registered in the {{{TagRepository}}} (executable tags) 
 gets special treatment. All others are handled as described in the 
 previous sections.
 
@@ -187,11 +187,11 @@
 binding, (see Jonas code e.g. for details). This is needed for creating 
 local variables in template "macros" and for handling context info in 
 recursive templates. Recursive templates are needed as soon as you have 
-recurively defined data structures like the class stuff in CForms.
+recursively defined data structures like the class stuff in CForms.
 
 The execution context gives access to the tag repository so that it is 
 possible to add tags and use tags in user defined tags. It might also 
-contain access to Cocoon components, and the source resover.
+contain access to Cocoon components, and the source resolver.
 
 === The Executable Tag ===
 
@@ -201,16 +201,16 @@
 compile time. But OTH they will be harder to write as one cannot use 
 member variables for state info.
 
-For the moment I think not requireing thread safety would be enough and 
+For the moment I think not requiring thread safety would be enough and 
 that we can see more efficient treatment of thread safe tags as a future 
 optimization. In Jelly, tags can implement {{{CompilableTag}}}, which give 
-them the possiblity to do some work at compile time, I've no idea about 
+them the possibility to do some work at compile time, I've no idea about 
 how it work though.
 
 Anyway the tag will be created at execute time and need access to the 
 different data specified above.
 
-Jelly uses the following inteface for tags:
+Jelly uses the following interface for tags:
 
 {{{
 public interface Tag {
@@ -252,7 +252,7 @@
 }}}
 
 (I'm using Jelly interfaces, so the example isn't completely consistent 
-with other discussion about intefaces in the mail).
+with other discussion about interfaces in the mail).
 
 I have no strong opinions about if we should user setter injection, 
 getAttribute methods in doTag, etc.