Web-programmeringsspråk

[GeirGrusom]

Én ting som har plaget meg en stund nå, er hvordan web-språk ikke er laget for web egentlig. Problemet er at det underliggende HTML systemet kan enkelt abstraheres vekk, og føre til at standarder opprettholdes av utviklingsverktøyet, og ikke utvikleren.

 

Men likevel så er alle programmeringsspråk for web akkurat som alle andre...

 

Jeg har hatt noen idéer hvordan dette kan endres, men vil høre hva dere mener om saken.

Er det en idé som ville vært nyttig å ytterligere underholde?

[ze5400]

Interessert i å høre litt mer spesifikt hva dine idéer går ut på

 

Problemet er at det underliggende HTML systemet kan enkelt abstraheres vekk, og føre til at standarder opprettholdes av utviklingsverktøyet, og ikke utvikleren.

Om utvikleren virkelig vil, så kan han jo håndtere slike trivialiteter selv, men det vil han jo ikke...

 

Hva er din løsning på dette?

 

 

EDIT: Måtte fikse quoten. IPB3 ser ikke ut til å like

...

Endret 22. februar 2010 av ze5400

[GeirGrusom]

Vel, idéen er å gjøre HTML, CSS og JavaScript til ett eneste sømløst backend språk. Hele DOM hierarkiet er objektorientert fra første stund, og ren HTML blir mer som en "inline assembly" mulighet der det er nødvendig.

 

Dersom en eksempelvis har noe slikt:

 

my_database : mysql.connection("username=anon;data source=localhost");
html
{
 script(source="Helloworld.js");

 body(bgcolor=color.red)
 {
   body.onclick()
   {
     alert("Hello World!");
   }
   my_link : link(href="http://www.helloworld.com");
   my_table = from "studenter" in my_database select "navn", "karakter";
   my_table.fill();
   foreach(entry in my_table)
   {
     div
     {
       entry.navn + br + entry.karakter.tostring();
       div.onclick()
       {
         my_link.content = entry.navn;
       }
     }
   }
 }
}

 

Noe mockup av hva jeg tenker på.

[Runar]

Interessant idé, og eksempelet ditt ser slettes ikke dumt ut, men jeg må innrømme jeg foretrekker dagens metoder. Selv har jeg midlertidig forlatt PHP til fordel for Ruby on Rails, og så langt kan jeg bare si at jeg elsker det. Med et veldig kraftig rammeverk i bakgrunnen kan jeg virkelig fokusere på selve kodingen, og slippe å tenke på hvordan jeg skal koble til databasen, eller hvordan templatemotoren fungerer.

[GeirGrusom]

Jeg tenkte også det kunne vært en god idé å abstraktere vekk selve databasespørringene også, som kan eliminere alle query hijacks en gang for alle.

[Jann - Ove]

ActiveRecord gjør vel akkurat det?

 

Ragex til Ruby gjør noe lignende som du foreslår; ren programstruktur blir til xhtml. http://ragex.metaclassofnil.com/

 

Perls cgi-modul har også html-generering ala "alternative style"-ragex-eksemplet.http://codesnipers.com/?q=perl-html-generation

Endret 22. februar 2010 av Jann - Ove

[GeirGrusom]

Vel, nå er det fullstendig irrelevant for diskusjonen hva av biblioteker som finnes til Ruby...

Idéen er at språket er fullstendig sømløst over hele dokumentet.

[Jann - Ove]

Men se på eksemplet da.

 

http://ragex.metaclassofnil.com/ragex_hp.txt

 

Et lite biblotek kan forandre selve språket i Ruby. Det holder med et par linjer mer enn et standard cgi-script, og man er igang med det du foreslår.

[ze5400]

Må jo si at det du beskriver hadde vært herlig, GG.

Har faktisk hatt våte drømmer om det ett par ganger, men rister det raskt av meg igjen da jeg syns det er best å ikke dvele for mye med "tenk om".

 

@Jann - Ove

Hvor mye endrer det libet ting? Kan man gjøre noe lignende GG gjør med onclick i eksemplet sitt?

 

 

@GG

Må bare spørre for å få det avklart;

Tanken er å autogenerere javascriptet som er nødvendig i forbindelse med events (onclick, onload, etc) o.l?

Endret 23. februar 2010 av ze5400

[MailMan13]

Vet ikke helt. Problemet med PHP (som lett er veldig sølete) er ikke at html er rotete, eller php-kode er spesielt rotete i seg selv (jeg synes det, men det er personlig preferanse). Heller at tradisjonelle CRUD-applikasjoner i PHP lider litt av det samme som classic ASP ved at programkoden og gui-definisjonen ofte er "røret sammen". Gjerne sql mot database på en linje og "<table class='.. " neste. Da blir det to språk i samme kode, som blir rørete.

 

Slik jeg tolker dette går forslaget ut på å "slå sammen" presentasjon og program til ett språk? Det fundameltalt problematiske med tradisjonellt kodet php og classic asp (og forsåvidt jsp uten en fornuftig front controller bak) er ikke at "det ser grisete ut" i seg selv. Det er riktig nok en veldig tydelig code-smell, men ikke sykdommen. Ett dataformat (som f.eks SGML-variantene) er informasjon, ikke instruksjoner og ett programmeringspråk er motsatt, uansett hvordan man vrir og vender på det. Slår man de to sammen vil den ene funksjonen legge føringer for den andre. Enten vil formatet på dataene bestemme over flytkontrollen i programmet, eller motsatt. Å definere grensesnitt gjøres best i ett markuplanguage som [x]html. Programmering gjøres best i ett objektorientert programmeringspråk, som Java/C#/Pyhton/whatever. I inline php/asp er programkoden på en måte "slaven" til html-koden, den injiseres ofte bare der det passer. Det er det jeg mener man bør bort fra, og ikke pynte på.

 

De beste webapplikasjonene er ikke dem som klarer å integrere disse sømløst, men heller dem som klarer å holde vantett skille mellom program og presentasjon. Løsningen på det pr. i dag heter MVC. Godt implementert blir da 99% av programkoden ren og pen C#/Java/Python/Ruby uten referanser til html/css, presentasjon er 99% format med asp/jsp+jstl (xml-formater) css og javascript, uten inline programkode.

 

Ett eget språk for begge deler kan kanskje se estetisk penere ut og dempe en code-smell litt. Men det løser ikke det grunnleggende problemet i den typen applikasjoner, det forsøker fremdeles både å være både et dataformat og et programmeringspråk på en gang.

 

Jeg tenkte også det kunne vært en god idé å abstraktere vekk selve databasespørringene også, som kan eliminere alle query hijacks en gang for alle.

De grunnleggende kodepatterns som ligger til grunn for hvordan vi gjør i det i dag var godt kjent og pensum på høyskoler/universiteter fra rundt '94-95. Det finnes tre grunner til at man fremdeles ser slikt: Mangel på kunnskap om grunnleggende designprinsipper, hastverk-arbeid (Det skal virke NÅ, ikke om de 15 min det tar å etabelere ett datalag), eller små script-snutter som bare skal gjøre noe èn gang.

Endret 23. februar 2010 av MailMan13

[GeirGrusom]

Men se på eksemplet da.

 

http://ragex.metaclassofnil.com/ragex_hp.txt

 

Et lite biblotek kan forandre selve språket i Ruby. Det holder med et par linjer mer enn et standard cgi-script, og man er igang med det du foreslår.

Ah, ja det var et langt bedre eksempel enn det første jeg kom over.

Dette er mye det jeg er ute etter ja ^^

 

Mailman13:

Jeg vil si at et godt programmeringsspråk er et som gjør jobben skikkelig. Dessuten er skilningen mellom markuspråk rent kunstig sett ifra et objektorientert perspektiv. Jeg ville sagt at et web-språk ville egnet seg best som et funksjonellt språk, og ikke et imerativt (som er langt mer vanlig), ettersom en web-side er for kortlevet til å trenge noen skifting av stadier og lignende.

Problemet i dag med HTML er at det først og fremst var laget for å vise statisk tekst, og ikke noe mer. Dette er blitt forsøkt endret med javascript og server-side scripting.

Hvis en blander HTML, CSS og JavaScript med et server side script i tillegg, og setter det opp til compileren å skille alt dette ifra hverandre, vil det gjøre ting som vedlikehold enklere, koden blir mer oversiktelig, og en setter langt mer press på compileren til å gjøre en god jobb.

 

Hvorfor skille mellom markup og programmering? Det er helt unødvendig sett fra min side. Et dokument er et hierarki av objekter, hvorfor ikke behandle det som det?

Endret 23. februar 2010 av GeirGrusom

[nomore]

Hva med CodeIngiter?

 

Det er mulig eg har misforstått poenget med diskusjonen, men med CodeIngiter så kan man(nesten) kun bruke CI's biblioteker og klasser, for så å få CI selv til å generere HTML-koden.

[GeirGrusom]

En ting jeg også savner, er en mulighet til å lage egne løkker, som helt klart kunne vært fordelaktig for web, ettersom en ofte setter opp tabeller eller lignende.

 

my_table_view : construct(header : node, footer : node, en : enumerator)
{
 init
 {
   header;
 }
 begin
 {
   if(en.end())
     break;
   write("<div>");
 }
 end
 {
   write("</div>");
   en.next();
 }
 finally
 {
   footer;
 }
}

my_database : mysql.connection("blablablabla");

html
{
 body
 {
   my_table_view(div { "Header" }, div { "Footer" }, from "studenter" in my_database select "navn", "karakter" where "karakter" >= 3;)
   {
     en.item.tostring();
   }
 }
}

[nomore]

Hva er vitsen med å "kutte ut" HTML når syntaksen i koden til ligner?

 

html {

 

}

 

Er jo veldig likt

 

<html>

 

</html>

[GeirGrusom]

Hva er vitsen med å "kutte ut" HTML når syntaksen i koden til ligner?

 

html {

 

}

 

Er jo veldig likt

 

<html>

 

</html>

Veldig likt ja, men html danner et objekt i et hierarki som du kan senere endre så mye du vil i codebehind, som til slutt blir til et HTML dokument.

 

hvis du skriver print("<html>") så er det akkurat det du får, hvis du derimot setter opp

my_html : html 
{

}

Så kan du referere til denne senere i koden for å enten dytte inn nye medlemmer, endre egenskaper som style e.l. eller slette den fullstendig (dog sistnevnte ville vært temmelig tåpelig)

 

Idéen er å strømlinjeforme alle aspekter ved webprogrammering. Hvorfor sitte med 4 forskjellige språk, når du i virkeligheten trenger ett?

[MailMan13]

Hvorfor skille mellom markup og programmering? Det er helt unødvendig sett fra min side. Et dokument er et hierarki av objekter, hvorfor ikke behandle det som det?

 

Jeg vet ikke hva din side er, men jeg har en følelse av at skalaen ikke er så stor.

 

Hvis man ikke bryr seg om at presentasjonen er bundet sterkt til databasen din, at koden ikke er testbar (kan ikke lage unit-testing for inline kode), man ikke reafaktorere datamodellen sin uten å gjøre det samme for deler av gui, eller ikke bryr seg om man kaller samme data flere steder så er det helt kurrant å kjøre alt inline. For enkle CRUD applikasjoner som i dag skrives i inline PHP el.l kan sikkert gjøres penere, men det er ikke en strategi jeg ville valgt for noe av noe som helst kompleksitet.

 

Hvrovidt man vil pynte opp view-delen i en MVC-modell med et penere språk er forsåvidt kurrant å gjøre. Om du vil kode brukergrensesnittet prosyderelt eller deklarativt med markup er forsåvidt uinteressant i den forbindelse. Om det språlet også vil egne seg for de andre lagene i applikasjonen er mer tvilsomt. Problemet, og det som bidrar mest til å gjøre systemene uhåndterlige, er når for mye oppførsel er kodet inn i GUI, som du ser ut til å ville tilrettelegge mer for.

Endret 23. februar 2010 av MailMan13

[GeirGrusom]

Hvrovidt man vil pynte opp view-delen i en MVC-modell med et penere språk er forsåvidt kurrant å gjøre. Om du vil kode brukergrensesnittet prosyderelt eller deklarativt med markup er forsåvidt uinteressant i den forbindelse. Om det språlet også vil egne seg for de andre lagene i applikasjonen er mer tvilsomt. Problemet, og det som bidrar mest til å gjøre systemene uhåndterlige, er når for mye oppførsel er kodet inn i GUI, som du ser ut til å ville tilrettelegge mer for.

Hvorfor kode oppførsel inn i GUI? Dette var bare et eksempel. I et virkelig program ville en selvsagt skrevet slik oppførsel i objektorienterte biblioteker som ligger ved siden av, men fortsatt med samme språk. Dersom en vil lage enkle websider uten noen sidefiler, er det også en mulighet.

 

my_namespace : namespace
{
 myclass : class
 {
   function SomeFunction() : integer
   {
     return 100;
   }
   function SomeEnumerator() : enumerator
   {
     return {100, 200, 300, 400}.enum();
   }
   function SomeElement() : node
   {
     return div { "Hello World!" };
   }
   static function PowerElement() : node
   {
     return div { "PowerElement2010!" };
   }
 }
}
-- document starts
html
{
 body
 {
   obj : my_namespace.my_class;
   obj.SomeElement();
   my_namespace.my_class.PowerElement();
 }
}

 

Én fordel er også at dokumentet kan endres fra start til slutt med en gang, og ikke progressivt som ville vært nødvendig med en rent prosedural fremgangsmåte.

[MailMan13]

Her referer du direkte til et fasadeobjekt fra presentasjonskoden din, altså, da får man sterk binding mellom "my_namespace.my_class" og viewet som presenterer dataene dine. Det er også presentasjonsspesifikk kode i en klasse som ser ut som skal være ett business lag. Men dette blir bare flisespikking, da jeg går utifra du ikke ville plassert det sammen. (da bryter man både med S og I i SOLID om man skal være nazi)

 

Man er forsåvidt i godt selskap med den fremgangsmåten. Classic ASP og COM+ ble brukt sammen slik, og det er mange som bruker samme mønster i dag.

 

Hovedpoenget med Controller-patternet er å bli kvitt den avhengigheten, slik dataene lastes uavhengig av viewet som skal vise dem. Det er ting som C#/Java gjør glimrende fra før, og ett nytt språk som i tillegg skal kunne definere GUI vil ikke gjøre den jobben bedre. Det det "nye" språket da står igjen med av oppgaver er å vise innholdet kontrolleren har lastet som [x]html, eller "whatever". Da er griseriet allerede nesten borte. Det kan være smartere måter å gjøre dette på enn i dag, men gevinsten av det er mer diskutabel. Viewet skal bare rendre en samling objekter, ikke noe annet, og er i så måte uten oppførsel i denne modellen.

 

Poenget mitt var at en korrekt implementert MVC faktisk eliminerer det som gjør dagens inline-språk som php grisete ved isolasjon og seperasjon, og at det fungerer bedre enn å forsøke å gjøre sømmene usynlige. Inline-kode bær være noe herk å kode, slik at folk ikke bruker det

Endret 23. februar 2010 av MailMan13

[GeirGrusom]

Her referer du direkte til et fasadeobjekt fra presentasjonskoden din, altså, da får man sterk binding mellom "my_namespace.my_class" og viewet som presenterer dataene dine. Det er også presentasjonsspesifikk kode i en klasse som ser ut som skal være ett business lag. Men dette blir bare flisespikking, da jeg går utifra du ikke ville plassert det sammen. (da bryter man både med S og I i SOLID om man skal være nazi)

 

Hovedpoenget med Controller-patternet er å bli kvitt den avhengigheten, slik dataene lastes uavhengig av viewet som skal vise dem. Det er ting som C#/Java gjør glimrende fra før, og ett nytt språk som i tillegg skal kunne definere GUI vil ikke gjøre den jobben bedre. Det det "nye" språket da står igjen med av oppgaver er å vise innholdet kontrolleren har lastet som [x]html, eller "whatever". Da er griseriet allerede nesten borte. Det kan være smartere måter å gjøre dette på enn i dag, men gevinsten av det er mer diskutabel. Viewet skal bare rendre en samling objekter og ikke noe annet.

 

Poenget mitt var at en korrekt implementert MVC faktisk eliminerer det som gjør dagens inline-språk som php grisete ved isolasjon og seperasjon, og at det fungerer bedre enn å forsøke å gjøre sømmene usynlige. Inline-kode bær være noe herk å kode, slik at folk ikke bruker det

Du har jo forsåvidt rett, men det er først og fremst grensesnittet som er poenget her. At du kan gjemme bort businesslogic er for meg inneforstått, ettersom det er et krav til ethvert web applikasjon. Eksempelet er bare et eksempel på det som var tanken min.

En kunne fint hatt noe "import somefile" eller lignende

 

Som sagt: det vil vøre mulig å endre alle deler av dokumentet ettersom dokumentet ikke blir generert proseduralt. Du kan endre starten av dokumentet selv om koden befinner seg på slutten, eller omvendt. Det er aldri for sent eller for tidlig å gjøre endringer i dokumentet, hvor som helst, hva som helst.

 

At folk bruker en annen fremgangsmåte i dag, betyr bare at folk bruker en annen fremgangsmåte i dag. Hvorfor PHP er så populært er for meg et mysterium.

[Runar]

Hvorfor PHP er så populært er for meg et mysterium.

Det er enkelt; det kjører på de aller fleste systemer; det samarbeider godt med HTML og det er tilgjengelig så å si over alt.