Hugo站点构建三步曲之第一步站点已经准备就绪，所有的依赖都已经各就各位。 从 事件风暴的主流程来看，接下来是时候进行最
站点已经准备就绪，所有的依赖都已经各就各位。 从 事件风暴的主流程来看，接下来是时候进行最终构建了：
跬步千里 - Build源码实现 #
在事件风暴中我们已经看到了构建的详细流程：
接下来，让我们从源码实现的角度来进一步分析。
了然于胸 - Build时序图 #
很清晰的三步：
- process：将文件系统的文件，有序地添加到内容图谱中。
- assemble：将内容图谱转换成页面图谱，为每一个内容图谱中的结点创建页面，包括首页、章节等结构页面。
- render：根据模板以及页面信息，进行最终站点渲染。
今天我们重点来看第一步 - process。
Process时序图 #
从中间可以看到，在开始处理之前，Site进行了初始化，以做好处理的准备。 开始处理内容时，先创建了资源规范NewSourceSpec，正是后续组件所要处理的内容。 紧接着创建页面处理器PagesProcessor和PagesCollector。 然后由收集器，从目录开始收集。
在 基础架构中，有对处理流程进行介绍。 通过明确的分工，高效的协作，最终将所有文件分门别类，规整地放在中心货架上。
现在我们来看看具体地实现思路和细节。
先来举个例子：
比如我们有两组数据要进行处理，一组是整型，一组是字符型。 我们需要一个来统筹管理的，分发任务。 还需要具体来处理信息的，一个整型处理器，一个字符型处理器。 为了让处理器之前紧密配合，就需要对处理流程进行统一。 可以看到总共分为三步，分别是开始、处理和等待。 这样在不同的阶段，负责协调的PagesProcessor就可以让其它的处理器各就各位，等待明确的信息就行。 其中在开始阶段，整型处理器和字符型处理器就已经准备好。 等待协调处理器发送具体处理对象了，这里用到了golang的频道作为信息传输通道。
页面是处理完成了，那我们的货架又长什么样，处理好的内容需要如何摆在这些货架上呢？
Hugo给这个货架取的名字是contentMap。 包含了好几颗树：pages tree, sections tree, resources tree。 没错，contentMap就是这些树的集合：
type contentMap struct {
// View of regular pages, sections, and taxonomies.
pageTrees contentTrees
// View of pages, sections, taxonomies, and resources.
bundleTrees contentTrees
// Stores page bundles keyed by its path's directory or the base filename,
// e.g. "blog/post.md" => "/blog/post", "blog/post/index.md" => "/blog/post"
// These are the "regular pages" and all of them are bundles.
pages *contentTree
// Section nodes.
sections *contentTree
// Resources stored per bundle below a common prefix, e.g. "/blog/post__hb_".
resources *contentTree
}
其中pageTrees和bundleTrees又是树的集合：
func newContentMap() *contentMap {
m := &contentMap{
pages: &contentTree{Name: "pages", Tree: radix.New()},
sections: &contentTree{Name: "sections", Tree: radix.New()},
resources: &contentTree{Name: "resources", Tree: radix.New()},
}
m.pageTrees = []*contentTree{
m.pages, m.sections,
}
m.bundleTrees = []*contentTree{
m.pages, m.sections,
}
return m
}
是为了方便后续的统一操作。
结合这些信息，再回过头来看上面的样例。
我们的目的是用contentMap组织好文件系统里的文件。 在示例中，contentMap可以将页面和资源有效的组织在一起，像header和resources。 其中"blog/a/index.md"是一个页面，“blog/a/b/data.json"和"blog/a/logo.png"都是资源文件，一个是数据类型，一个是图片类型。 最终都会以contentNode的形式，添加到对应的树中。 其中section tree也新增了一个结点，虽然没有相应的文件信息(fi: nil)，但path信息是”/blog/"。
树的数据结构是基数树，如何将识别到的信息放入相应的位置，则属于Hugo的领域知识。
比如Section的定义: sections。 第一级目录就是section，这是为什么"/blog/“会出现在章节树的结点中。 还有一种情况也属于章节，那主是任何包含了”_index.后缀"格式文件的目录，也属于章节。 同时Hugo管这种结构叫 Branch Bundles。 直译就是分支。 那为什么要这样组织？ 实际上是由Web 站点结构定义的。 Web站点的页面结构就是树状的。 有主页，了就是home page，还有不同的章节，如关于页面about page，它们都是从树根主页拓展开来的。
从站点结构就可以看出，站点页面有像主页，章节这样的索引页面，也有像某一篇博客这样的内容页面。 Hugo管前者叫 List Page，后者则是普通页面。 在站点主题的模板中，都有对应的模板，像layouts/_default/list.html，layouts/posts/single.html。
Hugo正是根据站点的这些规律，按自己的理解，抽象出了List Page, Branch Bundle等等这些概念，将信息组织在了一起，并放入ContentMap中。
再结合我们一直所使用的实例来检验一下：
动手实践 - Show Me the Code of Build process #
package main
import (
"context"
"fmt"
"golang.org/x/sync/errgroup"
"strconv"
"time"
)
func main() {
s := &set{elements: []string{}}
p := newPagesProcessor(s)
p.Start(context.Background())
defer func() {
err := p.Wait()
if err != nil {
fmt.Println(err)
}
}()
data := []any{1, "hello", 2, 3, 4, 5, 6, "world", "happy"}
for _, d := range data {
err := p.Process(d)
time.Sleep(1 * time.Millisecond)
if err != nil {
fmt.Println(err)
return
}
}
fmt.Println(s)
}
type set struct {
elements []string
}
func (s *set) Add(element string) {
s.elements = append(s.elements, element)
}
type pageProcessor interface {
Process(item any) error
Start(ctx context.Context) context.Context
Wait() error
}
func newPagesProcessor(s *set) *pagesProcessor {
ps := make(map[string]pageProcessor)
ps["i"] = &intProcessor{processor{
s: s,
itemChan: make(chan interface{}, 2),
}}
ps["s"] = &stringProcessor{processor{
s: s,
itemChan: make(chan interface{}, 2),
}}
return &pagesProcessor{processors: ps}
}
type pagesProcessor struct {
processors map[string]pageProcessor
}
func (p *pagesProcessor) Process(item any) error {
switch v := item.(type) {
// Page bundles mapped to their language.
case int:
err := p.processors["i"].Process(v)
if err != nil {
return err
}
case string:
err := p.processors["s"].Process(v)
if err != nil {
return err
}
default:
panic(fmt.Sprintf(
"unrecognized item type in Process: %T", item))
}
return nil
}
func (p *pagesProcessor) Start(
ctx context.Context) context.Context {
for _, proc := range p.processors {
ctx = proc.Start(ctx)
}
return ctx
}
func (p *pagesProcessor) Wait() error {
var err error
for _, proc := range p.processors {
if e := proc.Wait(); e != nil {
err = e
}
}
return err
}
type processor struct {
s *set
ctx context.Context
itemChan chan any
itemGroup *errgroup.Group
}
func (p *processor) Process(item any) error {
select {
case <-p.ctx.Done():
return nil
default:
p.itemChan <- item
}
return nil
}
func (p *processor) Start(ctx context.Context) context.Context {
p.itemGroup, ctx = errgroup.WithContext(ctx)
p.ctx = ctx
return ctx
}
func (p *processor) Wait() error {
close(p.itemChan)
return p.itemGroup.Wait()
}
type intProcessor struct {
processor
}
func (i *intProcessor) Start(
ctx context.Context) context.Context {
ctx = i.processor.Start(ctx)
i.processor.itemGroup.Go(func() error {
for item := range i.processor.itemChan {
if err := i.doProcess(item); err != nil {
return err
}
}
return nil
})
return ctx
}
func (i *intProcessor) doProcess(item any) error {
switch v := item.(type) {
case int:
i.processor.s.Add(strconv.Itoa(v))
default:
panic(fmt.Sprintf(
"unrecognized item type in intProcess: %T", item))
}
return nil
}
type stringProcessor struct {
processor
}
func (i *stringProcessor) Start(
ctx context.Context) context.Context {
ctx = i.processor.Start(ctx)
i.processor.itemGroup.Go(func() error {
for item := range i.processor.itemChan {
if err := i.doProcess(item); err != nil {
return err
}
}
return nil
})
return ctx
}
func (i *stringProcessor) doProcess(item any) error {
switch v := item.(type) {
case string:
i.processor.s.Add(v)
default:
panic(fmt.Sprintf(
"unrecognized item type in stringProcessor: %T",
item))
}
return nil
}
输出样例：
&{[1 hello 2 3 4 5 6 world happy]}
Program exited.
转载自:https://juejin.cn/post/7202537103933833274