XML / HTML / CSS Interpretieren

Nein, sxmlc ist für xml, nicht html. XHTML wäre auf XML basierwndes 
HTML, wird aber nur noch selten verwendet. XML und HTML basierten auf 
SGML, sind aber stark verschieden.

Du suchst einen HTML Parser und einen CSS Parser.

TestX schrieb:
> Einen "virtuellen" Browser per PhantomJS starten und dann per Javascript
> im Dokument auf die Elemente zugreifen

Er wills auf nem STM32F1 laufen lassen wenn ich das richtig lese, ich 
bezweifel daß man da mal eben solche Geschütze auffahren kann.

HolgerKraehe schrieb:
> Was sind eure meinungen?

Ist das nicht mehr oder weniger 1:1 das Konzept hinter QTQuick / QML, 
was auch für Embedded eingesetzt werden kann?

=> Das Rad nicht ohne Grund neu erfinden.

Hallo zusammen

Habe heute mal ein wenige mit dem Lexer angefangen, welcher die Token 
erkennen sollte.

Grundlage ist weiterhin das Skript vom ersten post.

Bevor ich nun zu sehr mit dem Coden beginne, möchte ich mal kurz ein 
Feedback einholen.

Was meint ihr?

Danke

1

struct token

2

{

3

  int type;

4

  int pos;

5

  char string[100];

6

};

7

8

9

int selection = 0;

10

int size = 0;

11

char buffer[1000];

12

int tokenCount = 0;

13

token tokenList[1000];

14

15

enum {START, END, CLOSE, RESERVED, VALUE};

16

17

char *Identifier[] = { "<", ">", "</", "div", "class=", "style=" };

18

char IdType[] = { START, END, CLOSE, RESERVED, RESERVED, RESERVED};

19

20

21

int checkForIdentifier(int start, char *buffer)

22

{

23

  int i = 0;

24

  int state = 0;

25

  char tmp[50];

26

27

  //Gehe an aktueller Zeichenposition alle Identifier durch. 

28

  while ((i != 6) && (state != 1))

29

  {

30

    //Kopiere vom Buffer, die anzahl Zeichen des Identifiers.

31

    strncpy(tmp, &buffer[start], strlen(Identifier[i]));

32

    tmp[strlen(Identifier[i])] = 0; //tmp Buffer null terminieren

33

34

    //Vergleiche den identifier mit dem tmp string.

35

    if (strcmp(tmp, Identifier[i]) == 0)

36

    {

37

      //Wenn sie identisch sind, wurde ein token gefunden. 

38

      state = 1; //token gefunden

39

40

      tokenList[tokenCount].type = IdType[i];

41

      tokenList[tokenCount].pos = start;

42

      strcpy(tokenList[tokenCount].string, tmp);

43

      tokenCount++;

44

45

      //Wir geben die anzahl zeichen zurück, welche übersprungen werden können. 

46

      return strlen(Identifier[i]);

47

    }

48

    //Noch kein Token gefunden? gehe zum nächsten identifier

49

    i++;

50

  }

51

  //Es wurde kein token gefunden?

52

  //Dann müssten hier wohl values zu finden sein. 

53

  //Ab hier bis zum nächsten token. 

54

55

  return 0;

56

}

57

58

59

void tokenize(char *buffer)

60

{

61

  int pos = 0;

62

  int res = 0;

63

  //Gehe solange durch, wie der inputstring lang ist. 

64

  while (pos < strlen(buffer))

65

  {

66

    //Ergebnis entspricht der anzahl zu überspringenden zeichen. 

67

    res = checkForIdentifier(pos, buffer);

68

69

    if (res != 0)

70

    {

71

      pos += res;

72

    }

73

    else

74

    {   //Kein ergebnis, bzw. 0 => kein Token. beginne beim nächsten zeichen. 

75

      pos++;

76

    }

77

  }

78

}

Das ist schonmal ein guter Ansatz. Aber eventuell solltest du nicht für 
jeden möglichen Tag und jedes mögliche Attribut einen neuen Token 
einführen, aber das hängt natürlich von den Anforderungen und den 
benötigten Infos ab. Um HTML richtig parsen zu können braucht man 
eigentlich noch Informationen ob ein Tag selfclosing ist oder nicht oder 
jenachdem (z.B. <input>, welches als <input/> interpretiert werden muss, 
oder <div/></div>, dass als <div></div> gelesen werden muss, etc.)
Und dann gibt es noch optionale Endtags (<div><p>a<p>b</div> ist das 
selbe wie <div><p>a</p><p>b</p></div>), und dann gibt es noch nicht 
erlaubte Unterelemente je nach Element...

Ich würde mir ganz ganz am Anfang die Frage stellen, ob es notwendig 
ist, die Oberfläche ohne Neu-Flashen des µCs auszutauschen.

Falls nein: Mach das ganze XML-Processing, Layout, ... auf dem 
Host-System während des Compilierens.

d.H. Präprozessor der dein Layout-XML zur Compile-Time in C(++)-Code, 
ein statisches Array-of-Struct oder sonstwas übersetzt.

Also so ähnlich wie der UIC von QT.

Bin ich altmodisch oder geht es noch anderen hier so daß sie die 
Text(!)-Auszeichnugssprache HTML für die denkbar umständlichste und auch 
mit Abstand aufgeblasenste Methode überhaupt halten um sie dafür zu 
vergewaltigen eine graphische Benutzeroberfläche zu beschreiben und die 
dabei entstandene Tag- und Attribut-Suppe dann hinterher wieder in was 
handhabbares zu parsen und irgendwie darzustellen? Wo ist der 
Pragmatismus geblieben, an welcher Stelle ging er verloren?

HolgerKraehe schrieb:
> Es geht darum, eine Beschreibungssprache für embedded Guis zu haben.
>
> Es geht nicht darum, vollständige websites darzustellen. Sondern darum,
> etwas bestehendes zu verwenden.
>
> Editoren für html und css gibts wie sand am meer. Weshalb nicht damit
> guis designen?

Geht doch. Nur passender... QML oder XAML.
XAML gibt's immer noch in Form des .NET Microframeworks für 
Mikrocontroller. Seit einiger Zeit auch mit LLVM/native Code 
https://github.com/NETMF/llilum (M3/M4)

>
> Der c interpreter zeichnet dann zb bei einem div der klasse button einem
> button. Farbe etc wird im css definiert.
>
> Fast wie eine webseite aber halt sehr sehr vereinfacht aber mit der
> maximalen flexibilität.
>
> Evtl gibt es auch bessere beschreibungssprachen für sowas.
>
> Was sind eure meinungen?

Warum in einem Interpreter jedes mal den ganzen Kram parsen, validieren, 
eventuell cachen damit's nicht zu lahm wird etc.? Wenn, dann würde ich 
aus den verbreiteten Beschreibungssprachen wie QML, XAML oder HTML was 
besser für Mikrocontroller verarbeitbares generieren.
Wenn's XML sein muss: Der XML-Reader des NetMF wäre z.B.
https://github.com/NETMF/netmf-interpreter/tree/03d84fe76e0b666ebec62d17d69c55c45940bc40/CLR/Core/Xml