Leider kriegt man das Image auch nicht mehr so einfach ausgepackt um sich die Dateinamen anzusehen.
Da sind Dir einige Beiträge dazu "durchgerutscht" ... inzwischen kannst Du mit einem aktuellen Freetz-Trunk ein AVM-Image durchaus entpacken und Dich darin umsehen. Wenn man dafür unbedingt 7Zip verwenden will, dann guckt man allerdings tatsächlich in die Röhre.
Ansonsten ist das immer noch Lua-Code, mit einigen Bibliotheken und ein paar Abstraktionen mehr ... unter der Haube hat sich da fast weniger geändert als beim Kernel-Update, nur das "Portal" läuft vollkommen anders.
Als ich das erste Mal (ich habe bisher nur einen flüchtigen Blick in den Lua-Code geworfen und die neue Version immer noch nicht "live" gesehen
) dort etwas von "oAuth" gelesen habe, dachte ich schon, AVM würde da jetzt tatsächlich etwas mit SSO implementieren wollen und kriegte schon fast wieder die Krise (das ist m.E. für einen Router zu gefährlich) ... aber das ist wohl nur ein Name und die einzige Stelle, wo es wirklich in die Richtung geht, ist die Google-Connectivity.
Wenn ich das (eben nur flüchtig bisher) richtig sehe, wird in content.lua ein Framework aufgebaut, das dann über data.lua "befüllt" wird. Der gesamte Teil der Anpassung an den Client dürfte (Vermutung, deshalb Konjunktiv) über Javascript auch auf dem Client laufen.
Ansonsten hat sich doch überraschend wenig geändert an den "worker pages" ... die "Roundtrips" zum Server laufen eben noch häufiger als asynchrone Requests ab und der Aufbau/Austausch von Seiteninhalten erfolgt jetzt eher über das DOM als über das Neuladen einer kompletten Seite (das war ja beim alten Interface auch schon die "Portalseite" und der Rest dann in Frames, wenn man keine Deep-Links benutzte).
Auch am Stil ist entweder zu merken, daß das noch einiges an iterativen Änderungen erfahren wird oder daß da mehrere Leute an derselben Stelle wirken. Da mischt sich dann eben der objektorientierte Ansatz zur Ausgabe von HTML-Code aus so einer "Seite" fröhlich mit direkt eingestreuten HTML-Tags ... eine einheitliche Linie kann man da (zumindest ich) eher noch nicht erkennen.
Kleiner Ausschnitt aus der services.lua:
Code:
<?lua if crashreport.show then
html.hr().write()
html.h4(nil, [[{?41:362?}]]).write()
html.p(nil,
[[{?41:897?}]]
).write()
html.p(nil,
[[{?41:62?}]]
).write()
[COLOR="#FF0000"]html.div({class="formular"},[/COLOR]
html.input({
type="radio", name="crashreport_mode", id="uiCrashreportOn",
value="to_support_only", checked=crashreport.checked("to_support_only")
}),
html.label({['for']="uiCrashreportOn"}, [[{?41:40?}]]),
html.br(),
html.input({
type="radio", name="crashreport_mode", id="uiCrashreportOff",
value="disabled_by_user", checked=crashreport.checked("disabled_by_user")
}),
html.label({['for']="uiCrashreportOff"}, [[{?41:74?}]]),
html.br(),
html.label({['for']="uiCrashreport_name"}, [[{?41:213?}:]]),
html.input({
type="text", name="crashreport_name", id="uiCrashreport_name", value=crashreport.get_name(),
size="50", maxlength="128", class=val.get_error_class(g_val, "uiCrashreport_name")
}),
html.br(),
html.div(nil, html.raw(val.get_html_msg(g_val, "uiCrashreport_name")))
).write()
-- Ende crashreport.show
end ?>
<input type="hidden" name="sid" value="<?lua box.html(box.glob.sid) ?>">
<input type="hidden" name="back_to_page" value="<?lua box.html(g_back_to_page)?>">
[COLOR="#FF0000"]<div id="btn_form_foot">[/COLOR]
<button type="submit" name="apply" id="uiApply">{?txtOK?}</button>
<button type="submit" name="cancel">{?txtCancel?}</button>
</div>
</form>
um nur mal ein Beispiel herauszuheben.
Auch solche Konstruktionen erstaunen mich unter dem Aspekt der Effektivität etwas, ich kenne aber die Arbeitsweise des Lua-Interpreters nicht gut genug, um das fundiert einschätzen zu können, ob da tatsächlich Geschwindigkeit "verschenkt" wird.
Code:
<form id="uiMainform" name="mainform" method="POST" action="<?lua box.html(box.glob.script) ?>">
<?lua href.default_submit('apply') ?>
<?lua write_saveerror() ?>
<?lua if allow_comm.show then
Auf der Basis von anderen Sprachen würde ich erwarten, daß für jeden Code-Block zwischen "<?lua" und "?>" eine neue Interpreter-Instanz benötigt wird, denn das sollten (nach meinem Verständnis) jeweils in sich abgeschlossene Codefragmente sein (im gemeinsamen Namespace). Da würde ich dann wieder erwarten, daß etwas wie
Code:
<?lua href.default_submit('apply')
write_saveerror()
if allow_comm.show then
zwei komplette Kontextwechsel weniger erfordert. Kann mir da mal ein Lua-Experte Erleuchtung verschaffen?
Ansonsten frage ich mich nach wie vor, ob die AVM-Programmierer wirklich an demselben Lua-Code rumwerkeln, wie er am Ende in den Images landet. Vielleicht findet man sich ja als Autor dort problemlos zurecht, ich habe mir dafür allerdings unter Verwendung von Beautifier und Colorization (lua2html) etwas bauen müssen, denn das "Abzählen" der Lua-Blöcke in vollkommen unstrukturiertem Code ist schon sehr ermüdend. Wenn das die Ausgabe irgendeiner anderen "Hochsprache" wie MoonScript wäre, würde ich das auch noch verstehen, aber für meine Begriffe hat das keinerlei Ähnlichkeit damit. Sollte also jemand noch eine Idee haben, ob der AVM-Lua-Code das Ergebnis eines Code-Generators ist und wenn ja, welcher dort verwendet wird, dann immer her damit.
