Cull Front Documentation
  • Overview
  • Quick Start
  • An example
  • Pros and Cons and Comparisons
  • Appendix
    • Magic Insertions
    • Auto-deduced Elements
    • Syntax
    • Inclusions
    • Fragment Files
Powered by GitBook
On this page
  • Separation of Concerns demo
  • How does this help you?

An example

PreviousQuick StartNextPros and Cons and Comparisons

Last updated 5 months ago

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

Second File

Third File

Fourth File

Output

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.

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.
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.
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.
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.
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.