HTML och CGI eller?

[sodjan]

> I min html kod använder jag % som esc-char, följd av en 6-siffrig kod,...

OK, och var finns denna "html kod" ?
Skapas inte HTML koden "on the fly" ?
Har du någon slags "mallar" lagrade för de olika sidorna ?

Kommer inte "%nnnnnn" variablern från *browsern*, d.v.s att det är
browsern (eventuellt hjälpt av "användaren") som anger på något sätt
vilken data som ska visas ?

Eller finns det *massor* av olika färdiga HTML sidor för alla tänkbara
presentationsfall ?

Sen måste den ju inte bli en enda jättestor switch sats.

oJsan's exempel blir tydligare. Sedan är den en annan sak att
t.ex get_frekvensomvandlarparamter() *i sig* kanske har en
switch sats för de olika parametrarna, men det ligger i en annan
del av koden (kanske en helt annan C-fil) och det blir renare och
enklare at underhålla om man inte blandar in det som en sub-switch
sats som du har gjort i ditt exempel.

> En del data är en textsträng, en del int en del double en del word osv.

Hm, men för *PIC'en* (så längde den inte behöver "räkna" med värderna)
så är allt samma sak, en sträng med bytes. Sen kanske en del data
behöver konverteras innan presentation/inkludering på HTML sidan,
men det är en annan sak. Men, det är lite svårt att uttala sig om utan
att ha dokumentationen för kommunikationen till hands...

> Vet inte så mycket om SSI, men jag gissar att den bara gör include på
> redan existerande data (såsom filer).

Beror lite på den aktuella implementeringen.
En del SSI (insåg inte tidigare att det var server side includes det handlade
om) kan även hantera speciella "markers" som t.ex sätter in aktuellt datum
i samband med "includen". Det låter lite som om det är något i den stilen
som TomasL har i tankarna !?

[sodjan]

> Switchar i flera nivåer är nog ändå det enklaste du kan göra i detta fall.

Jo, rent tekniskt spelar det kanske inte så stor roll.

Personligen föredrar jag dock att ha korta samanhängande kodelar.
Lite i stil med att alltid kunna se början och slutet på en switch, for,
while (eller likande) på samma gång på skärmen...

Blir en switch/for/while längre än så, så får man bryta ut någon del
till en sub/func/proc (eller vad det aktuella språket kallar det).

Det blir också lite enklare att underhålla då koden blir mer strukturerad
och modulär.

[oJsan]

I min senaste exempelkod behöver inte varje switch innehålla mer än ca 10 case vardera eftersom flera likadana grupperas ihop.

sodjan är inne på fundering som mig. Var genereras förfrågningarna? Det känns väldigt rörigt just nu, ungefär som att du själv inte vet hur förfrågningar och presentation ska se ut. Skriv ner en spec på hur du VILL att det ska fungera och bryt sedan ner det till mindre block och realisera.
En grundfråga: Ska html-sidorna vara statiska och begränsade till antalet eller ska användaren kunna efterfråga valfri parameter?

[sodjan]

> I min senaste exempelkod behöver inte varje switch innehålla mer än ca 10 case...

Jag tänkte på fallet där man har switch'ar inne i case'arna, om man säger så.
Det kan lätt bli lite rörigt och man blandar lätt ihop case satser från olika "nivåer"...
Personligen tycker jag då att det blir tydligare om sub-switchen läggs i en egen
funktion/procedur.

I ditt senaste exempel ser det dock inte ut så, men jag funderade lite mer generellt...

[TomasL]

Ibland blir man hemmablind, naturligtvis får jag dela upp det så att jag anropar separat procedurer för varje enskilld del.
Typ:

Kod: Markera allt

switch (index)
{
   case VLT
         vltfunctions(address, command);
         /*code*/
         break;
   case ("nästa")
       nästafuntion(address, command);
       /*osv..........................*/

Då slipper jag problemet med för långa relativa anrop, och får en "snyggare" kod.

Sodjan, så här ser det ut:

Har en webserver skapad i en 18F8622, denna pratar med nätverket via traditionell tp/ip (också i samma uP).
Via I2C pratar den med några andra picar, som i sin tur pratar med div externa enheter.
På I2C-bussen ligger också en FATonCHIP som i sin tur hanterar en hårddisk, där alla html-sidor ligger.
Så webservern får ett "GET" från browsern, talar via I2C med FAT-processorn som hämtar filen i fråga från disken, och skickar den till servern.
Servern i sin tur skickar html-sidan till browsern.
Om det då finns inbäddade SSI-variabler i sidan, hämtar webservern dessa från resp perifer enhet via I2C.
Om "GET" har ett argument, förutom en url, så är det ett cgi-kommando, som avkodas av servern och exekveras, det kan till exempel vara att man skall stänga av en VLT.

[sodjan]

OK, ja det var ju betydligt tydligare...

Så browsern begär olika sidor (vilket motsvarar olika filer
på hårdisken) beroende på vilken VLT som ska visas ?
Jag hade nog gjort det dynamiskt med *en* lagrad sida
och aktuell VLT är ett argument till GET.
Du har ju, vad var det, ca 30 VLT'er ? Eller så missförstog
jag den delen. Spelar kanske inte så stor roll...

Det hela blev hur som helst *mycket* klarare
när man har hela bilden med all kringutrustning.

Sen om man ska vara petig, så är det väl inte riktig
SSI det handlar om. Din server hämtar ju hela sidor,
och i dessa ligger det "placeholders" för variabler.
SSI handlar så vitt jag förstår om att inkludera
en HTML fil i en annan HTML fil (*och* att hantera SSI variabler).
Men det kanske är det du gör.

Sen, eftersom du har skrivit din server själv, så spelar det
kanske inte så stor roll vad man kallar det, du kan ju få
det att fungera procis som du vill i alla fall...

Skit samma, det var ju switch-strukturen det hela skulle
handle om.

[staffolainen]

Skapa XML-filer istället "on-the-fly", sen skapar du en html-sida med javascript(ajax kallas tekniken) som hämtar data från den. Det blir snällare mot din PIC som inte behöver processa mängder med data, utan klienten får ta smällen.
Sen skapar du enkelt layouten med css(cascading style sheets) istället för att hålla på och krångla med SSI:er(väldigt 90-tal).
Det ger flexibilitet och möjlighet att byta layout ifall man surfar in med mobil eller PDA.

/Staffolainen

[TomasL]

Låter intressant, har du några exempel/länkar då detta är helt nytt för mig.

[staffolainen]

Nu måste jag villigt erkänna att jag är ganska ringrostig på de nya teknikerna som gäller i "webb 2.0", men misströsta ej, idg webbstudio har svaret.

AJAX(Asynchron Javascript And Xml)
http://iwtjanster.idg.se/webbstudio/pub ... .asp?id=59

CSS
http://iwtjanster.idg.se/webbstudio/pub ... .asp?id=27

Lycka till!

/Staffolainen