Iconoclast
Home » Categories » Arkitektur  

Vad handlar Smart Content Dependency Management™ om?

[VITBOK] Senast uppdaterad av Joe Schaefer på Sat, 25 Apr 2026    källa

 

träd

Sammandrag

Beroendehantering för smart innehåll™ handlar om cirkeln av idéer relaterade till att ge stöd och underlättande för *inkrementella byggen *, samtidigt som man håller sig till **Content Normalization Principle **— det där permalänkar bör vara den enda sanningskällan, oavsett hur deras innehåll kurateras i hela källträdet och resulterande byggartefakter.

Denna artikel presenterar https://sunstarsys.com/ webbplats som en fallstudie för demonstration av bästa praxis och analys av tillhörande graftopologier.

förbehåll

Detta betyder bara när du behöver väga kostnaden för att utföra hela webbplatsbyggen varje gång du behöver justera innehållet på en webbsida. Om din webbplats har mindre än 1K källfiler i den, avslappna, och läs följande med ett öga mot dina framtida behov. Du valde att använda vår plattform, som är utformad för att skala med dig, inte mot dig. För de flesta sidor handlar det här materialet nedan om glesa diagram över innehållsberoende för webbplatser med fler än 1K-sidor.

Till exempel Apache https://www.OpenOffice.Org webbplatsen kunde bygga sina filer på 40K+ med den ursprungliga Apache-versionen av detta byggsystem, med fullt integrerat stöd för inkrementella byggen — utan några konfigurerade beroenden — Genom att göra smart användning av traditionell SSI-teknik ensam.

Som standard bygger vårt byggsystem endast de filer du har ändrat, utan problem för de interna filberoendena (om du inte anger dem i %path::beroenden — Mer om detta nedan). Om filen du ändrade finns i mallar/ eller lib/ En fullständig webbplatsversion utlöses istället.

Vävning av webbplatsens beroendediagram tillsammans

Matematiskt, en topologi τ\tau är en fullständig specifikation av de öppna delmängderna av ett utrymme XX, vars syfte är att indikera närhetsrelationerna mellan punkter xx från rymden XX. När XX är ett diagram, en topologi τ\tau för XX belopp för att ange kanterna som kopplar ihop diagrammets brytpunkter (här visas brytpunkterna* för XX, och de anslutande kanterna bestämmer grannskapen för dessa punkter som basöppningsuppsättningar för topologin). En *riktad graf topologi *är i huvudsak samma sak, men innehåller en hänvisning till en topologisk inbäddning av (X,τ)(X,\tau) i ett större topologiskt rum (Y,σ)(Y,\sigma) , där inbäddningens kantanslutningar representeras av riktade, icke-skärande (Jordanien) kurvor.

Det senare konceptet är vad vi kommer att använda när vi diskuterar *beroendegrafens *topologi τ\tau associerad med arbetsytan XX av källfiler under webbplatsens innehåll/ underkatalog (här) (Y,σ)(Y,\sigma) är Rn\mathbb{R}^n med sin metriska topologi för n∈{2,3}n \in \{2,3\}och kanterna på XX är icke-korsande, riktade jordanska kurvor som ansluter en fil x∈Xx \in X till sin uppsättning filer som xx beror på: { x′∈X∣x→x′ }\set{x^\prime \in X | x \rightarrow x^\prime}).

Att en tydlig förståelse för din webbplats *beroende diagram *kommer att se till att du kan maximera prestandan hos vår byggteknik i stor skala. Vi tar den information du lämnar till %path::beroenden under byggets belastning av din webbplats lib/path.pm fil, konstruera en omvänd karta över beroende filer och använd den omvända kartan för att fastställa den fullständiga korpus av filer som ska byggas för en given sv-bekräftelse Du gör till vårt system.

Det är viktigt att notera att beroenderelationerna mellan källfiler kan och bör helt fångas av %path::beroenden hash under byggsystemets startladdning av lib/path.pm från ditt källträd, vilket är hur de inbyggda vyerna i våra SunStarSys::Visa Perl-paketet är tänkt att fungera. Den walk_content_tree, arkiveradoch seed_file_deps verktygsfunktioner som kan importeras från SunStarSys::Tillfälle är användbara hjälpmedel för att konstruera %path::beroenden hash, med inbyggt stöd för att hantera ett beroendecacheminne för att påskynda inkrementella byggen i stor skala.

Här är den delen av vårt liv lib/path.pm:

our (%dependencies, @acl);

# entries computed below at build-time, or drawn from the .deps cache file

walk_content_tree {

  $File::Find::prune = 1, return if m#^/(images|css|js)\b#;

  return if -d "content/$_";

  seed_file_deps, seed_file_acl if /\.(?:md|ya?ml)\b[^\/]*$/;

  my $path = $_;
  utf8::is_utf8 $path or utf8::decode $path;
  state $count = 0;
  for my $lang (qw/en es de fr ru sv he zh-TW ar ko ja pt-BR/) {
    delete $dependencies{"/sitemap.html.$lang"} if ++$count <= 12;
    next if m!\.page/!;
    if (/\.md\.$lang$/ or m!/index\.html\.$lang$!) {
      push @{$dependencies{"/sitemap.html.$lang"}}, $path if !archived;
    }

    if (/^(.*)\.tex\.$lang$/ and -f "content$1.bib.lang") {
      push @{$dependencies{$path}}, "$1.bib.$lang";
    }

    if ($path =~ s!/index\.html\.$lang$!!) {
      $dependencies{"$path/index.html.$lang"} = [
        grep {utf8::decode $_; s/^content//}
        glob("'content$path'/*.md.$lang"),
        glob("'content$path'/*/index.html.$lang")
      ];
    }
  }
}
  and do {
    while  (my ($k, $v) = each %{$facts->{dependencies}}) {
      $dependencies{$k} = [grep $k ne $_, grep s/^content// && !archived, map glob("'content'$_"), ref $v ? @$v : split /[;,]?\s+/, $v];
    }

    open my $fh, "<:raw", "lib/acl.yml" or die "Can't open acl.yml: $!";
    unshift @acl, @{Load join "", <$fh>};
    my %cache;
    @acl = grep !$cache{$_->{path}}++, @acl;
    for (glob("content/*/index.md.*")) {
        next if /archives|categories/;
        s!/index\.md\.[^/]+$!!;
        push @acl, { path => $_, rules => {
             '@bloggers'  => 'rw',
             '@svnadmin' => 'rw',
             '*' => 'r',
        }} unless $cache{$_}++;
    }
  };

Vänligen gör mull den koden över för idéer om hur du vill din webbplats att fungera. Ja, det finns en viss rimlig komplexitet (med både Perls reguljära uttryck och Perls UNIX C-skal) glob gränssnitt, på ett mycket exakt sätt) kring hur %path::beroenden är konstruerad i den filen, men istället för att bara titta på detta som optimeringsarbete, titta istället på det som att tillhandahålla de grundläggande ingredienserna som behövs för att konstruera viktiga aspekter av *link topologi *på ett automatiserat, dynamiskt genererat sätt.

Var går in i %path::beroenden Ursprung? Om de inte är födda av en åkallan av walk_content_tree { seed_file_deps ... }, (som i princip dyker in i dina markdown-källfilers huvuden och innehåll), då är de bara hårdkodade i lib/facts.yml vid lastningstid.

Cykliska beroendediagram är normen

Vår webbplats består för närvarande av 240 källfiler om innehåll/. Här är en 85 hörn x 465 kanter, rullningsbar, tvådimensionell dirigerad diagramrepresentation av en aktuell ögonblicksbild av sidberoenden på engelska på vår webbplats (använda GraphViz prick):

Beroenden för engelska språk

Ganska komplicerat, även för en liten webbplats som denna! Många kantskärningar när du tar n=2n=2 (undvikbar i dimension n=3n=3). Särskilt viktigt är kärnuppsättningen av täta, cykliska beroenden i de icke-arkiverade filerna på vår webbplats /essays/ katalog, mot den nedre mitten-höger av grafen, vilket är vad en bra blogg webbplats beroende diagram bör se ut. Dessa beroenden dras in i röda kurvor i bilden.

Notera också den interna, väsentligen isolerade sammankopplingen av elementen i /kategorier/*/* och /archives/2022/11/*. De enda externa beroendena involverar icke-arkiverat innehåll i /essays/*. Detta är genom design — De arkiverade uppsatserna bör endast ändras adiabatiskt kanske enbart för justeringar av deras Kategori rubriker. Ingen av dessa ändringar påverkar väsentligt det befintliga innehållet, så vi spårar det inte i %path::beroenden.

Självklart vår Wiki för Orion Enterprise Har aldrig haft problem med att hantera cykliska beroenden.

Handlar det inte bara om hyperlänkar?

Nej! Faktum är att länkens topologi på din webbplats är en helt separat fråga från källträdets beroendediagram. En sökmotor kommer naturligtvis att illera *link topologi *, men har ingen inblick i *beroende diagram *.

Här är en 240+ hörn x 3859 kanter, aktuellt diagram med fågelperspektiv i det engelska link topology-diagrammet för vår plats (använda GraphViz tvåhörning):

Kan du upptäcka röda kanter som anges i beroendekurvan? Diagrammet link topology är kvalitativt och kvantitativt mycket annorlunda från (dramatiskt mindre och mindre sammanlänkat) beroendegraf som visas ovan.

Hur SSI-teknik kan hjälpa

Traditionell Server-sidan inkluderar (SSI)

Mall-API:er

ssi-tagg

Syntax:

{% ssi `/content_rooted/path/to/source_file` %}

ssi-filter

Syntax:

{{ innehåll|ssi }}

Varför inte SymLinks?

Verktyg för Permalänkar

Dokumentkuratering

Orions byggsystem har integrerat stöd för vad vi kallar Document Curation, vilket är processen att rekontextualisera och omorganisera ditt innehåll baserat på hur du ställer in Kategorier och Status huvuden i källfilerna för Markdown. Dessa funktioner är avaktiverade som standard, men kan aktiveras genom att en category_root (för kategoristöd) eller en archive_root (för arkiveringsstöd) i det associerade hashref-argumentet till önskat @path::mönster inträde.

Kategorier
Arkiverade sidor

På vår webbplats arkiverar vi aggressivt inaktuella essäer för att hålla byggtiderna för nya essäer låga, samtidigt som vi inte förstör permalänkar till arkiverade dokument. beroendegrafen i förhållande till /arkiv/ katalogen (för vår webbplats) är rimligt fristående enligt följande regler:

Lede

HTML-kommentarer inbäddade i gränserna för Markdown-prosa-formuläret för lede-innehållet. Vi använder {Antal ledarnr} för detta ändamål.

Bearbetningsledningar görs med ledde Mallfilter. Det är nyttigt att kombinera detta med ssi filter för indexering av en kategorifil med fler än en kategorisida i den.

Slutsatser

Det finns intressanta datastrukturer och relationer som ännu ska avslöjas när man hanterar en webbplats *beroende diagram *från ett byggprestandaperspektiv, vilket är ett mycket nyare intresseområde än forskningslitteraturen som fördjupar sig i datastrukturer och tillhörande problem kring *länk topologi *1,2.

Konventionella inkrementella byggen för rena programvaruutvecklingsprojekt är fortfarande ett hett ämne. Den forskning som omfattas av 3,4 publicerades i oktober 2022, ungefär en månad innan denna uppsats förväntas vara klar. Den pluto5 bygga system har funktioner som liknar vår (byggandet själv kan dynamiskt regenerera och bygga om beroenden).

Den goda nyheten är att vi har täckt dig som kund. Vi kommer att hålla dig underrättad om de bästa metoderna och den senaste tekniken inom detta område, så att du kommer att dra nytta av våra lärdomar under det senaste decenniet och in i morgon.

fotnoter

  1. Identifiering av kluster i webbdiagrammet baserat på länktopologi Sjunde internationella symposiet för databasteknik och tillämpningar, 2003. Förfaranden

  2. Härleda webbforum från länktopologi Den nionde ACM-konferensen om hypertext och hypermedia fortsätter: länkar, objekt, tid och rum — struktur i hypermediasystem: länkar, objekt, tid och utrymme — struktur i hypermediasystem. 1998.

  3. Om fördelarna och gränserna för inkrementella programvarukonfigurationer för bygge: en undersökande studie ICSE ‘22: Förfaranden vid den 44:e internationella konferensen om programvaruteknik, maj 2022

  4. Mot inkrementell uppbyggnad av programvarukonfigurationer ICSE-NIER ‘22: Förfaranden vid ACM/IEEE 44th International Conference on Software Engineering: Nya idéer och framväxande resultat, maj 2022

  5. Ett ljud och optimalt inkrementellt byggsystem med dynamiska beroenden OOPSLA 2015: Förfaranden vid ACM SIGPLANs internationella konferens om objektorienterad programmering, system, språk och tillämpningar oktober 2015