# Overview This documentation is for version 0.9 *Cull Front* is a simple generator for creating powerful HTML frontends *with* the capability to handle HTMX and AlpineJS\* Or you can call it a "site builder". This is NOT an editor but a data processor. It gives a very simple way to describe HTML elements declaratively *and tersely*, and separates areas of concerns that you have. You will have to prepare the files it uses using conventional text editor. I prefer *"VS Codium".* **IMPORTANT**\ This tool is meant for those who clearly know how HTML works; and also how HTMX and AlpineJS\* works — at least conceptually. *If you are a total beginner to such technology, then this tool may not be for you.* ### What made me write this? I am an architect (of the building variety) and I look at software development quite the same way as that of designing buildings. When designing the built-environment, I shift repeatedly from *top-down* and *bottom-up* view of a design. By *top-down*, I mean I need to get the overall, holistic idea of what is being designed. But I don't stay permanently in the *top-down* mode — looking down on the design like a bird flying high up there. No — that would be just one way of looking at the design development. And if that is the only way I look the design process, I would surely get a poorly detailed design. So I also need to shift to a *bottom-up* mode — What I mean by this is that I want to look at the evolving design by concentrating on specific parts of it. Such as, trying to figure out how someone may *open a door* and what would be that experience for different kinds of users. Again, I don't get stuck purely in the *bottom-up* mode — it will get me too entangled in the details.\ \ By shifting continually between *top-down* and *bottom-up* I force my mind to think of the evolving design from all angles. The holistic is thought of and respected. Not just that. Even the details that the design need to contain need to be well respected and handled. This is an agile, iterative process. *BTW, some may not know this: The "spiral development" is well discussed in the architecture (of the built-environment) community — I daresay, even before it got adopted in the software field. Read John Zeisel's book "**Inquiry By Design**".* ### What is wrong with frontend development tools? a) I tried many: I got entangled with the looks of the front end along with the functioning of the design. Especially in case of WYSIWYG tools such as *Bootstrap Studio* or *Pinegrow*, etc. I would rather handle the looks quite separately as a task by itself — not along with the functionality. I need to separate the *areas of concerns —* such separation would also help me later delegate work to others and monitor their ongoing work. b) As explained earlier; when I design, I want to move between "*top-down*" and "*bottom-up*" iteratively. Kind of a "push" and "pull" or "kneading the dough" kind of process. \ \ When in "*top-down*" mode, I need to quickly get an overall picture of the design being evolved. \ \ When in "*bottom-up*" mode, I need to be sharply focused on some fine detail (e.g. the way a door would open) and during that period I don't want my mind to get other inputs. I should be then like a sniper, aiming solely at my target. \ \ This type of iteration is one major reason I often dislike conventional method of developing HTML. I am presented with the whole thingamajig of the HTML elements all at once. It distracts me, and poses a heavy cognitive load. c) As the design evolves, I need to quickly get to the part I need to work on really fast. Just the way an index at the end of a book helps me directly jump into the meat of the book and locate what I want; I wanted a designing system that allows me that kind of usage, rapidly. Conventional systems unfortunately keeps becoming heavier and heavier with more and more cognitive load as I proceed. d) I want the system to be terse; without me writing verbose stuff such as tag starting/endings of HTML elements, and doing indentation to make things readable. In many cases, the entire HTML with all its various angle brackets, and tree structure etc. are thrown right at me. And the "looks" of the ongoing front-end also ends up as a distraction. Even GUI development tools such as Figma, etc. did not attract me: I find that to be even one more additional step when designing a front end rapidly. I often tell my juniors (in my architects office) to *not to keep looking at* the evolving building — because the moment we visualize something, we tend to fall in love with it and get extremely biased visually.\ \ Visual examination of the evolving design is of course important — but it must be done with deliberate care. The mind must be told not to fall in love easily. e) Though I do like the tree-structure of HTML, I find that the visual nesting of elements is often confusing to me. I often cannot locate the exact area I want to work on. I do nesting of HTML elements because it is logically suitable to achieve some functionality ...and at that point in time, I should not be drawn into indentation, match the start and end-tags and such details. f) Technology such as HTMX and AlpineJS\* are great -- the only draw back is that they both enforce a different kind of discipline: The various functionality happens by squirrelling away logic into attributes of different HTML elements at different locations. So the overall behavioral functionality of the holistic is cut up and distributed as attributes in various parts of the HTML. I would like to look at all the logic of the evolving HTMX/AlpineJS\* together. Of course, some of you readers may argue that their existing tool does not have the above deficiencies. I respectfully suspect that they may have kind of arm-twisted their minds to make that tool work in a suitable manner. Many of us do use tools in unexpected ways — ways that we are comfortable with and not really due to the capability of the tool in question. ### The name: "Cull Front" The name I chose for this tool "Cull Front" reflects this: This tool culls information from different files, and then puts them all together to generate the eventual HTML. It keeps different areas of concerns into different files. There is a "tree" file which declares the tree structure of the HTML in the front end — *without* presenting a tree shape to you. The tree is really described linearly. It gives you a lot of freedom.\ \ Then there is another file, where you declare each of the elements you happened to use in that tree (along with its attributes) Again, there are no angular brackets, etc. to distract you. Then there two more files (optional) that describes the HTMX and the AlpineJS\* that you would be using in your frontend. By separating these files, each file becomes rather pithy and easy to understand. I can easily go thru multiple iterations, as I flesh out the front end for my SaaS — *(And of course, I can use this even for plain static HTML too)* *\*It does not just support AlpineJS but also any other JS framework that take a similar approach to AlpineJS of using special attributes inside elements.* # Quick Start ***Cull Front*** is a simple 32bit Windows console program, with no dependencies. ### Installation There is no installation process. Just download and unzip the [Cull Front zip file here](https://cullfront.com/cullfront.zip) into a new folder. Set a system PATH to the executable; cullfront.exe so that you can use it from any location on your computer. \ \ *Cull Front* is NOT a GUI program. So double-clicking on the executable in Windows explorer will confuse you — you may even think it is not working as it will start and close quite fast. You need to go old-school: You have to start the program from the command-line of a Windows CMD console window. ### Summary *Cull Front* loads a "build" file to do its work. Think of it like a csv file, with each row defining the build of one HTML file. Each row contains 5 values — each representing a file name. It can be a fully qualified or partly qualified path. If no path is given, the current working folder is searched. *The five values MUST be within "quotation marks".* By default, if you do not specify the filename as an argument on the command line, it tries to load the file *build.cull.txt* from the current working folder. Note that it is strongly recommended to end the filename in ***.cull.txt*** As the extension is after all *".txt"*, it is easily loadable into text editors. ### The first value in a build is the filename of the HTML to be generated The rest of the of the values are filenames needed for four types of files need for that build. These are explained below. ### The four files specified for a build Four files have to be always specified on each line of the build file (One line represents one build)after the filename of the HTML file to be built. These filenames are comma-delimited and they *must* be enclosed in quotation marks. The last two files are actually optional; so if you do not have use for those, specify them as empty strings i.e. ***"".*** If you are creating a multi-page SaaS application or a multipage HTML website, you would have multiple lines in that build file; each line representing each of the pages of your SaaS application.\ \ Each of these files are pseudo-CSV files where the first value on the line represents the element ID. ***Cull Front depends on the fact that every HTML element that is needed for the functionality has to have a unique ID.*** *You can have elements without IDs if they do not contribute to the functionality, by using the templating feature of this system.* 1. **First File** \ There is a "tree" file which defines the tree structure, without pulling me into the actual tree shape. Instead each line of the file represents one fragment of the tree. It starts with the element ID of the "root" of that fragment and has an array of the IDs of the main children of that starting root element. If any child has its own children, then that would be seen in some other row of that file. (The order does not matter) \ \ Here is an example: \ \ NOTE: The special character "!" represents the \ element and "\~" represents the \ element. These two are not given any ID. The children of an element are placed within square brackets (as an array) Those two fragments are necessary for *Cull Front* to produce any data; because it will first process the \ fragment, and then the \ fragment, and stitch them up together to form the final HTML. ``` "!",["t1","schtmx","scalpine","sc1","sty1"] "~",["txa","input_3","txa","hr_1","form1","txc"] "form1",["input_1","input_2","div_1"] "div_1",["txa","span_1","pr1"] ``` 2. **Second File** \ This is an "*elem*" file which defines what tag is used for a particular element id, and what would be the list of attributes for that element. \ \ An example is shown below:\ \ The first value of each line contains the element id. The second is for the tag name that element stands for. The third is for the list of attributes. \ \ As seen below , the attributes are given inside a \[...] array(or list) There are 3 types of elements in that list: It is usually nv(STRING,STRING) which represents NAME=VALUE as seen in most HTML attributes. Or it is just n(STRING) which represent element attributes that do not have values. E.g. "readonly" etc. \ \ It also can be v(STRING) which is a special invention of mine. It represents the innerHTML used as a special child in the HTML element\ \ Note that I have used a special HTML element I invented (not seen in regular HTML syntax) called "t" This is for a special case where only the first v(...) attribute is used either directly as a string OR -- if that string starts with the '@'char, it is picked up from a template file, and the contents of that template file is inserted as the string. This feature makes it very powerful as explained later. ``` "schtmx","t",[v("@htmx_script.txt")] "scalpine","t",[v("@alpine_script.txt")] "txa","t",[v("Hello Mary Lou")] "form1","form",[nv("method","POST"),nv("action","/gohere")] "t1","title",[v("Sabu's First")] "sc1","script",[nv("src","https://aa.com")] "~","body",[nv("onload","dothis()"),v("So long easy rider...")] "pr1","pre",[v("Hello there")] "sty1","style",[v("@main.css")] "txb","t",[v("@hello.txt")] ``` 3. **Third File** \ The third element of the build line, is an "HTMX" file which is specifically to handle special HTMX attributes. If this file is not to be processed, give an empty string ***"".***\ \ This is also a pseudo CSV file. Each row starts with an element ID, and an example is shown below.\ \ In this example the first value contains the element ID. The 2nd one is the "hx-trigger", third is the type of HTTP request that needs to be done, fourth is the action of that request, the fifth is the target on which the output is to be deposited, the sixth is what is the swapping type to be done. The last is an array (in square brackets) containing special attributes that are quite similar to regular HTML attributes, that is sometimes used. ``` "div_1","keyup changed delay:500ms, search","hx-post","/search","#search-results","",[nv("hx-indicator",".htmx-indicator")] ``` 4. **Fourth File**\ The fourth element of the build line is for the "AlpineJS\*" file which is to insert special AlpineJS\* attributes. If this file is not to be processed, give an empty string ***"".***\ \ This is also a pseudo-CSV file. Here is an example below. Again, the first value is for the element ID. The 2nd is a list of attributes that is used by AlpineJS\*. ``` "div_1",[nv("x-data","{aa:true}"),n("x-cloak"),nv(":click","dothat()")] ``` ### More details You can keep the four files in different folders if you so want. (For e.g. if you want other people to work on those files, then you may want to keep the respective file with the folder of the respective person who maybe working on it) In such a case, make sure that the filename given in the build file contains that path. This is the reason why it is critical that all the four filenames specified on each line of the build file must be within quotation marks. In the above elements file (the 2nd file) you may have seen data such as nv("name","value"), v("@hello.txt") and n("readonly") These are for HTML attributes. Let me explain more details of such attributes. ``` nv("class","myclass") will turn up as <... class="myclass" ...> in the HTML n("readonly") will turn up as attributes without values...In this case: v("this is a text") will be used as an innerHTML string. If that string starts with '@' it is considered as a template file, and the content is read from that file. Explained later. ``` The attributes can be specified in any order. In fact, all the lines of all the files can be written in any order. It is agnostic to the order. This is very useful as the designer is not forced to think of the order in which to write. *But please note that the array of children elements specified for each element should be in the correct order. That is the only place where the ordering matters.* Note that all such lists in all the above files can even be empty -- in which case you need to write it as a pair of empty square brackets: ``` [ ] ``` **Readability** \ Also note that for readability and more terseness, you need not put quotation marks around the element id on each line *(i.e. the first value of the row)* This flexibility is ONLY for the first value. For the rest of the line, quotation marks, commas, parenthesis and square-brackets *must* be all as shown in the above examples. As the element ID is always at the beginning of the line in *all the four files,* you can rapidly reach the element you want in all the files. Just train your eye to look at the beginning of the lines. ### Templates Once the above files are ready, you may also need one more type of file: Those are text files for pieces of text aka "templates". The templates that you regularly keep using for all your projects would be kept in the "templates" folder present in the same location as that of the executable. But there would usually be some custom templates also; specifically to the page you are building. \ \ These templates can contain HTML elements and I can see people copy-pasting from various sources on the Internet. As this project evolves, I would be making some templates that everyone can use in their projects. I am hopeful others would also make them.\ \ One powerful feature of *Cull Front* is that it can; in do what I call "magic insertions" into the template just-in-time. For e.g. You may have a standard template for the top navigation bar. Now you would not know in advance what would be the links placed in that particular navigation bar. There is a special "magic insertion" feature documented in the appendix which can dynamically insert a smaller fragment at the correct place just before the HTML is written out. *How does Cull Front recognize such templates?* \ Whenever the value of an attribute is given as in this example: *v("@hello.txt") ; Cull Front* will try to read the file specified after the '@' sign. (Hello.txt in this example) If a path is not given for the filename, it will attempt to load the contents first from the "templates" folder present in the same folder as the cullfront.exe executable. If that is missing, *Cull Front* will load the contents from the file present in the current folder. ### Settings Apart from the above files, *Cull Front* also would want to load 2 other files — those are for handling the settings used internally during the build process. One file is called ***cullfront.settings.txt*** and the other is called ***singletons.dat.txt*** Read the appendix for more details. Reasonable defaults are available in the standard zip file that you download. These two files must be in the same folder as that of *cullfront.exe* ### How does it carry out the build? The way *Cull Front* works is that it first figures out the complete HTML by culling together info from the tree file and the elems file. Once that string is processed an almost complete HTML is produced, it then proceeds to insert the HTMX as needed by searching for the correct id="" in the string. Once that is done, on similar lines, the AlpineJS\* attributes are also inserted. The reason why the first 2 files are processed before the last two, is because one can write HTMX or AlpineJS\* into attributes that may be presented in the strings inside template files (using the special "t" tag I invented) This is a very powerful feature. *Cull Front* can make use of system templates (kept in the "templates" folder of the executable) and that is where it will first search. If a file by that name is missing, it searches for the template file in the current folder. The string inside these template file can contain HTML -- thus it can contain fragments of the eventual HTML DOM tree. Hence, there may be more elements in the final output than what may be specified in the tree file of the build -- as some extra elements may come from the fragments picked up from inside the template string. So the author of the build, can actually insert HTMX as well as AlpineJS\* even inside those templated fragments too. ***\*Though I used the term "AlpineJS" it is not necessary that you are tied to AlpineJS — you can use other JS libraries that use the same strategy as AlpineJS i.e. using specially invented attributes for HTML elements.*** # An example ### Separation of Concerns demo In the following screenshots, you can see the way one build works. Each build is generated from one line (with 5 comma-delimited lines) inside *build.cull.txt* \ \ The HTML filename given as the first value of that comma-delimited line. For the generation, *Cull Front* culls together the four filenames specified on that line, after the first HTML filename. \ \ In short, these five filenames are present in one line of the *build.cull.txt* file and in this example, there are no other lines (thus no other builds). Let us go thru the contents of each of those four files: #### First File

The contents of the "Tree" file (1st file in any build operation) This defines the various fragments of the tree. The list on each line are the element IDs of the direct children of the element ID specified at the beginning of the line. The character "!" (exclamation mark) represents the <head> element and that line explains what other elements are the direct children of <head>. The character "~" (tilde) represents the <body> element and that line explains the direct children elements of <body>

Note that in this example, fragments for "input_1" and "input_2" were given. But that is really not needed because there is no fragment underneath those two elements. Moreover, Cull Front can deduce the tags automatically from the string "input_1" and "input_2", if so required. This is explained in the Appendix.

#### Second File

This file contains the elements definitions. There are 3 elements in each row. First is the element ID, second is the HTML tag which is to be used and third is the list of attributes of that element (specified in the Cull Front syntax) Here you would see that the element whose id is "schtmx" is actually picked up from a template file named "htmx_script.txt" Similarly, element with ID "scalpine" is picked up from a template file named "alpine_script.txt". Note that the 2 inputs have been defined here as they have attributes for type and name. But in case you had not defined them here, Cull Front would have auto-deduced the elements. This is explained in the appendix.

#### Third File

This is the third file — it is used for HTMX functionality. One line defined the values used by HTMX for one element. In this simple example only one element has HTMX attributes. In a realistic example, there would be many. And your mind can go over all of them in this one file itself; instead of they being scattered all over the place in the HTML.

#### Fourth File

This is the fourth file for the build. It is for AlpineJS attributes. Again, in a realistic frontend, there will be several elements that has AlpineJS attributes. You would be able to see ALL of them together in this file — instead of being scattered about in the HTML.

#### Output

Finally, this is what Cull Front would generate for this build. The filename for this output would be the first value written on the line for the build, before the other four filenames. Please note that there are three occurrences of "Hello Mary Lou" — because in this example, we reused the same virtual element "txa" three times. And that happened to pick up the string "Hello Mary Lou" which was given as the value of "txa"

Though two other elements "sc1" and "sty1" were defined in the "Tree", they were not further explained in the "Elements" file. And you would notice the absence of those two elements in the generated HTML. This is a demo of the fact that Cull Front will silently remove all undefined elements.

### How does this help you? The first file ("Tree") explains the tree structure. When you are working with this file, your focus is not distracted by any tree shaped HTML (or indentation as seen in Pug/HAML, etc) The tree is logically formed by *Cull Front* because you specified what are the direct children of the elements you have given. If you want to experiment with other tree shapes of the HTML, it is as easy as moving the element ID from one element's child list to another one.\ \ A similar situation can be seen in the 2nd file ("Elements"). That file explains the regular HTML attributes of each element, again using the element ID. Note: Your eventual HTML may have elements without IDs — for e.g. if you had written some HTML fragment in a template file, and included that as a virtual "t" element. The HTMX and Alpine files lets you concentrate purely on the HTMX and the AlpineJS respectively.\ \ Finally, also take note of the fact that there is no specific "order" in which you give your data in any of the files. The only place where the ordering would be important, is when you specify the direct children of an element in the first file ("Tree") This frees you up in trying to figure out how the HTML would turn out. Of course you would need to occasionally look at the built HTML in a browser but you almost would never have to really look inside the HTML DOM tree at all. *Cull Front* would be doing all that for you quite religiously. # Pros and Cons and Comparisons ### The advantages of *Cull Front* * The **separation of structure (tree), elements (elem), and behavior (HTMX/Alpine)** into distinct files is very clever and useful. It's similar to the classic separation of HTML/CSS/JS, but at a higher level of abstraction. * The template system with **the special 't' tag** and file inclusion via '@' is powerful - it allows for composition without sacrificing readability. * The approach to **HTMX/Alpine attributes is particularly valuable**. Having all HTMX logic in one place rather than scattered throughout HTML makes it easier to reason about the application's behavior holistically. * The **terse syntax** and CSV-like format makes it quick to write and modify, while still maintaining structure. * Some cursory tests using the system shows that it can be even **40% to 60% smaller** than conventional systems. * There is **no Nodejs NPM mess**. The program is stand-alone with no dependencies. It is a 32 bit binary executable which processes your files natively. So, extremely fast. * It is **agnostic to the SaaS system/static-site system** you may be developing. It is not necessary that you have to use HTMX and/or AlpineJS. You can easily use other ways of developing front ends too — however if you do use HTMX and/or AlpineJS (or systems similar to AlpineJS) you would find *Cull Front* extremely convenient. * The **templating system** is amenable for becoming a "cottage-industry" by itself. Once Cull Front picks up, I am sure there will be lot of template developers for it. * It is superbly aligned to "**kaizen**" — you can incrementally and iteratively improve your work. You can leave comments into the files it uses *(Start the line with double-slashes for it to become a comment)* * It allows **partially dynamic templates**. That means, you can specify a template file for it to pickup some part of the HTML from; and at the same time, it can dynamically do "magic insertions" into the template string, just-in-time as per your current needs. Explained in the appendix. * **Improved Collaboration:** The abstract representation of the tree could facilitate better communication and collaboration among designers and developers. * **Faster Prototyping:** The ability to quickly experiment with different tree structures could accelerate the prototyping process. * **Agnostic to HTML version:** *Cull Front* only has a conceptual understanding of HTML. It does not; for example, know which elements are "singletons" (those without ending tags) — It learns that on the fly by loading *singletons.dat.txt* file on startup. That means it can use whatever new elements that new versions of HTML may bring in. (This is also a disadvantage. See next) * *Cull Front* can be used to generate **BOTH front end files as well as backend server-side templates**. This feature has been implemented from version 0.82 onward. Explained further in the appendix. ### The disadvantages of *Cull Front* * Every element (other than \ and \) needs to have an ID. And all IDs must be unique. I am talking of those IDs that are needed for your code to work. You can easily insert elements without IDs (as they may not be participating in the functionality) using the templating feature. hmmm... so, *is this really a disadvantage?* * It does a reasonable check for "circular references" in the tree structure. However, full debugging has not yet been done for this. Let me know your experience. * As *Cull Front* does not know the actual HTML elements and the way it works, it cannot do a grammar check on HTML. I hope to have address this at some point (or may not, as I think it is a minor disadvantage — *Cull Front* is *not* for beginners in HTML) * Some amount of learning is needed. You need to know the concepts of HTML, HTMX and AlpineJS (and similar tech) ... again, *is this really a disadvantage?* This tool is NOT for beginners. In fact, it can be used by beginners too if they take some effort to learn all those concepts, in parallel. * I can't think of another disadvantage — maybe that itself is a subtle disadvantage: *The author is biased! :-) But more seriously: I am open to suggestions. Email me at * ### Comparisons Some people thought of other comparable systems such as Pug, HAML, etc. Here is an apt comparison. | Feature | Cull Front | Pug/HAML | | ------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Tree Definition | Separate file, logical representation | Indentation-based, visual representation | | Flexibility in Tree Order | High, allows for reordering without affecting logic | Limited, changes in indentation can significantly impact structure | | Iterative Development | Easier to experiment with different arrangements | Can be more challenging to modify the tree structure iteratively | | Abstraction | Higher level of abstraction, focuses on relationships rather than visual structure | Lower level of abstraction, requires more explicit consideration of the visual tree | # Magic Insertions I had briefly mentioned earlier in this docs about this feature of the *templates* functionality of *Cull Front.* Let me explain this in detail. \ \ Often, you don't want to pick up the template files verbatim and use exactly the same content in your HTML build. You may want to modify some part of it before it goes into the eventual HTML. \ \ Here is an example of a navigation bar from Bulma CSS. Refer this link: \ \ Notice in that Bulma CSS, they have used a div whose ID is "*navbarBasicExample*" which actually describes the links which the nav bar handles. These are for "Home", "Documentation" and "More" ... and then the "More" link further opens up a sub-menu with these links "About", "Jobs", "Contact", "Report an issue" \ \ ***Now; of course, that would not be the case in your specific HTML build!*** \ \ So instead of hard-coding all those links into the template, you can insert this magic string: **!=!\** This is to be done just before the "navbarBasicExample" div; and you should remove that div from the template. I have shown this Bulma example below. Instead of removing the original div for "navbarBasicExample" here I have just commented it out. And above that I wrote this: ``` !=!MyNavigation ``` So what Cull Front will now do is to look for the fragment definition for an element whose id is "MyNavigation" in the Tree file (the 1st of the four specified for a build) and then *just-in-time,* it will construct the HTML fragment which would get inserted in place of that magic string.\ \ Now; in your build, there may not be actually an element whose ID is "MyNavigation" defined in the "Elements" file (the 2nd file needed for the build) In that case, *Cull Front* will develop the fragment for the list of children specified in the tree file. But if you do define such an element make sure it is a container element such as \
etc.\ \ **In short, your job would now reduce to only the specific differences in the HTML which needs to be inserted just-in-time.**\ \ Note that Magic Insertions happen after the first two files are loaded, but *before* the HTMX and AlpineJS files are processed. So you can *even* insert HTMX and AlpineJS even into elements written in the template (or ones inserted magically) ```html
``` # Auto-deduced Elements Often there would be elements you want to insert into the tree which do not really contribute to the functionality. Such elements would not have any definition in the Elements file (the 2nd file of the build) Nor would they have any definition for HTMX and AlpineJS (the 3rd and 4th file of the build) For example, you just want to insert a \
or an \
element. In such a case, here is an example of a fragment you write in the tree file (the 1st file of the build): ``` ~,["txa","hr_1","txb"] ``` In the above fragment, the \ element has 3 direct children, whose IDs are "txa", "hr\_1" and "txb". Let us assume that "txa" and "txb" are defined further in one of the other 3 files. i.e. either in the 2nd file where elements with their attributes are defined or in the HTMX file or in the AlpineJS. And let's assume that "hr\_1" was never further explained anywhere else — after all it is just a simple horizontal rule, and it really does not contribute to the functionality as such. \ \ In the above example, you have created a special element ID called "hr\_1" where you took care to construct the id as the tagname (in this case "hr") followed by an underscore and some unique random val. So in such a case *Cull Front* will "auto-deduce" an ID as "hr\_1" and attempt use it. The usage of such autodeduced elements can be done in two ways.\ \ This id would get inserted into the HTML if the autoid setting was given as *autoid(1)* in the *cullfront.settings.txt* file. If you wrote *autoid(0)* in the cullfront.settings.txt then the ID does not get written for such an element.\ \ So you would see something like this in the output if you used *autoid(1)* in the *cullfront.settings.txt* file: ```
something here
something else here
``` Or if *autoid(0)* was given in the *cullfront.settings.txt* then you would see the output something like this: ```
something here
something else here
``` As you can see in the 2nd case the \
does not get an element ID in the final HTML. # Syntax This documentation explains the syntax of the files for the build file, tree and elements using a syntax which depends on the use of quotation marks. But there was a feedback, that too many quotation marks were seen and that seemed unnecessary. So from version 0.7 onwards, I have coded two types of syntaxes for the 3 files mentioned below. Note that the syntax for the files for HTMX and AlpineJS, is same as before. So irrespective of whatever you specify as the syntax type, the files for HTMX and AlpineJS must be written in the same manner as explained in this documentation. If *cullfront.settings.txt* contains this setting: *syntax(0)* then the older form of the syntax is used (i.e. where quotation marks are used to delineate strings) However if you gave syntax(1) then you can omit putting quotation marks in these 3 files: *For the build, for the tree and for the elements.* This feature is not fully tested. But I think it is quite stable. In fact syntax(1) also allows you to put quotation marks too, if you so want — for some of the data — hence that syntax type is the default now in *cullfront.settings.txt* # Inclusions From version 0.8 onwards of *Cull Front* you can *include* other files of the same type for all the files used for a build. This can be quite useful in many situations. For e.g. you may want to have the same kind of fragment in the \ \ for multiple files in your project. So instead of writing it again and again, you can just ask *Cull Front* to include that file. The way that is done is to write the name of the included file in a line by itself, starting with the @ character. (i.e. the first character of that line must be '@') Obviously you need to take care that the included file is of the same type as the one where it has been asked to be included. An included file itself can further include other files — ad infinitum.\ \ *Sufficient care has been taken to ensure that the this kind of inclusion do not result in an infinite loop. But let me know your experience.* NOTE: This is not downward compatible. Only available from version 0.8 onward. # Fragment Files By default, *Cull Front* will produce a complete HTML when it goes thru each line in the build file. The first value of the comma-delimited line will be used as the output filename. \ \ If you give a semicolon after that filename and specify the element ID of a fragment, *after that filename* then *Cull Front* will produce ONLY that fragment. This can be used by your server to send over HTML snippets into the browser for HTMX behaviors in your application. Here is an example: You have a complete front end file say "index.html", which has 2 HTMX behaviors. One behavior makes a POST request to the server and it sends back an HTML fragment (let's say "frag1") into a target element. The other one makes a GET request and sends back another HTML fragment ("frag2") When designing index.html you describe fragments with element-ID "frag1" and "frag2" in the tree file. However these fragments are never part of the DOM tree for index.html. One can say they are orphaned. So the *build.cull.txt* file, you write the following lines: ``` "index.html","tree.txt","elems.txt","htmx.txt","alpine.txt" "frag1.html;frag1","tree.txt","elems.txt","htmx.txt","alpine.txt" "frag2.html;frag2","tree.txt","elems.txt","htmx.txt","alpine.txt" ``` When *Cull Front* does its work on that build file; it would first produce the complete HTML and write that into index.html ... because that was specified first in that build file. As *frag1* and *frag2* are "orphaned fragments" they would not be seen in the output. Then *Cull Front* will write a file called "frag1.html" which contains only the fragment which starts with the element "frag1" and lastly; a file named "frag2.html" containing only the fragment starting with "frag2" You would use frag1.html and frag2.html at your server. Thus you now have all the required files for your application to work. In real world usage; frag1.html and frag2.html would usually not be a static piece of HTML. Instead it would usually contain some server implemented conventions so that the server can use those fragment files as server side templates (e.g. "go" templates) The server uses those server-side templates to dynamically flesh out the actual HTML; which is then returned to the client whenever those aforementioned HTMX behaviors happen.\ \ In short; ***Cull Front***** can be used to generate BOTH front end files as well as backend server-side templates.** *This feature is available only from version 0.82*