Gå til innhold

Web-programmeringsspråk


Anbefalte innlegg

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.

Det er Classic-ASP/PHP-restriksjon. Bruker du f.eks ASP.Net vil hele DOM dokumentet være en objektgraf som kan herjes med så mye man vil (eller, de kontrollene som er deklarert "runat=server", kan forsåvidt være hele dokumentet) frem til PreRender eventen på siden, etter det rendres det som html i en "go". JSP var ikke like elegant sist jeg kodet det dog, det er en stund siden.

 

PHP er steinalder, og ikke representativt for hvordan moderne plattformer håndterer sånt.

Lenke til kommentar
Videoannonse
Annonse

 

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

 

Det er ikke enkelt. Det er tungvindt og har mange dårlige løsninger.

At det kjører på de fleste systemer er ikke en grunn for at php er mye brukt, det er en konsekvens.

Samarbeider bra med html er strengt tatt ett dårlig argument, da man håndterer dette selv, gjerne med print/echo.

Lenke til kommentar

Du kan forsåvidt kode C# inline der om man vil, det er ikke obligatorisk med codebehind-fil. Frem til VS2005/.Net 2.0 var det ikke default oppførsel heller. Da fikk man bare en aspx-fil så var det meningen å ordne alt der med <% %>-kode. Codebehind måtte man mekke til selv.

 

Er bare en fornuftig måte å holde html og programkode adskilt på, selv om MS-miljøene med VB.Net i spissen har syndet mye mot både før og etter.

Endret av MailMan13
Lenke til kommentar

Problemer jeg skulle likt at ett nytt språk løste (behind the scenes, så jeg slipper å bruke tid på det selv);

Holder ett objekt per instans i minne på serveren, slik at det blir trivielt å behandle data, gjøre bakgrunnsprosessering, ha AJAX (og POST) events på en helt annen måte enn i dag.

 

Automatisk kommunikasjon mellom nettleser og serverside.

Ett eksempel.

 

html
{
btnTest(Text = "Klikk her" : button
{
  this.onClick
  {
    this.Enabled = false;
  }
}
}

 

Via AJAX vil systemet da sørge for at når brukeren trykker knappen deaktiveres den via AJAX, eller gjennom en reload av websiden dersom netlleseren ikke støtter javascript.

 

Så klart holder systemet styr på statusen til alle objektene, slik at brukeren ikke minster tekst vedkommende editerer e.l.

 

Dette lar seg så klart gjøre i andre språk gjennom egne klasser, etc, etc, men jeg skulle likt å se ett språk konstruert med tanke på dette, da det kan bli utrolig elegant, og spare mye tid og gjøre det svært enkelt å lage sømløse websider.

 

En annen ting jeg skulle likt å se i ett nytt språk er muligheten til en modifisert form for ternary operator.

 

Skulle elske å kunnet gjøre dette;

(expression ? {Code; Code; Code; return Var,} : alternativ);

Samt sløyfe alternativet.

 

Dette gir mening, da man slipper å kalkulere ut en variabel man ikke skal bruke. Dette kan så klart gjøres før man eventuellt tar i bruk variablen, men da oppretter man fortsatt en (tom) variabel man ikke bruker. Unødvendig, og klumsete.

 

Så må operatoren også ha muligheten til å droppe alternativet (altså : og det som følger), ettersom alternativet ofte er null.

 

 

Kommer garantert på mer, så ikke umulig jeg redigerer inn mer. Tenkte jeg kunne ta det i denne tråden som likevel handlet om ett fantasispråk :p

 

EDIT1:

En ting til jeg kom på; Accsessors!

public int Test
{
get
{
  return this.value;
}
set
{
 this.value = input;
}
}

 

Med det mener jeg at Test har ett internt protected felt (value), som accessors kan(ikke må) referere til, slik slipper man å opprette en ekstra variabel til å gjøre dette, dersom dette ikke er ønskelig/nødvendig.

Endret av ze5400
Lenke til kommentar

Er enig i at PHP er forferdelig rotete (og lett å lage sikkerhetsfeil i), og av mange grunner så er det IMO en av de minst egnede språkene for web programmering.

 

I dag bruker jeg Python / Django, Det bruker en slags MVC, og gjør etter min mening en ganske god jobb. Du kan forsåvidt ta en titt på design filosofien bak den :http://docs.djangoproject.com/en/1.1/misc/design-philosophies/

 

Når det gjelder din ide, så høres den bra ut i utgangspunktet, men jeg tror implentasjon vil bli rotete. Du blander flere logiske ting, og tror det vil ha en tendens til å stå i veien for det man tenker å lage. Merker det allerede i django at den av og til gjør ting vanskeligere enn det burde vært, og det framework'et er ganske praktisk anlagt IMO.

 

En større abstraktifisering av webside utvikling vil bare forstørre det problemet, og man må trolig enten lage et ganske komplisert system for å la utvikleren endre ting slik han trenger det, eller utvikler må bruke lang tid på å gå rundt språket for å oppnå det han vil/trenger.

Lenke til kommentar

Riktig at implementasjonen kan bli komplisert, men jeg tror det kan være en fordel om utviklere kan ta fokus vekk fra HTML, Javascript og AJAX, og heller konsentrere seg om å skrive en applikasjon. Dersom en legger det tilrette slik somze54000 nevner, og serverside/clientside er like sømløst som alt annet bør være, så sitter en ikke bare med masse spart tid, men sannsynligvis med løsninger som hvor AJAX er langt mer vanlig enn det er i dag.

 

Hvis du kan for eksempel skrive:

 

doc_content : div
{
 div.onclick()
 {
   lib : library();
   div.children.add(lib.getdocument("some_document"));
 }
}

Og det blir opp til implementasjonen å oversette hva dette blir. Vi ser at det i det minste må bli en clientside del med AJAX, og en serverside del som leverer data etter hvordan det er definert i library klassen. Hva løsningen eksakt må bli er opp til implementasjonen, ikke opp til utvikleren.

Dette vil i mine øyne føre til at flere vil være istand til å bruke AJAX korrekt.

Lenke til kommentar

Om ein synes webutvikling er tungt, grisete og rotete så bør ein kikke på meir moderne webrammeverk som Ruby on Rails eller Groovy for Grails.

 

Eg har nettopp utvikla eit CRM system i Groovy for Grails, der utviklingstida har tatt ca 600 timer. Skulle det ha blitt gjort i PHP så hadde utviklingstida vore nærmare 3000 timer. Fordelen med dei rammeverka er MVC, veldig plugin/modulbasert, skikkeleg template språk og hibernate/activerecord.

 

I Groovy for Grails så blir html'en skreve med bruk av taglibs.

Eksempel:

       <g:if test="${flash.message}">
         <div class="message">${flash.message}</div>
       </g:if>
       <g:else>
         <g:hasErrors bean="${projectInstance}">
           <div class="errors">
             <g:renderErrors bean="${projectInstance}" as="list" />
           </div>
         </g:hasErrors>
       </g:else>

       <g:form controller="project" action="update" method="post" >
         <g:hiddenField name="id" value="${projectInstance?.id}"/>
         <g:hiddenField name="version" value="${projectInstance?.version}" />

         <div id="response_project_project_view">

           <g:render template="/project/form/project/tile_content_field"/>

           <shiro:hasPermission permission="issue:admin">
             <g:render template="/project/form/project/tile_project_content"/>
           </shiro:hasPermission>

           <g:link controller="issue"
                   class="response_button2"
                   action="edit"
                   params="[project:projectInstance.id]">

           <g:message code="Response.Project.AddNewIssue"/>


         </div>

       </g:form>

 

Det ser kanskje gresk ut med det første, men taglibs gjer det mogleg å halde god html struktur, med enkel tilpasning til vanleg applikasjonskode. Det er også lett å halde orden på i18n strenger, kva som skal kunne vises basert på rettigheiter osv...

 

Det som også er bra med det er at ein kan lære seg taglibs litt etter litt, ein har moglegheita til å skrive vanleg html frå starten av.

 

Det finnes plugins til Grails som har heftig bruk av taglibs, der du bygger skjemaer på sekunder istadenfor timer.

 

Groovy har det nevner med å bygge HMTL, men det er rotete for meir komplekse løysninger

 

import groovy.xml.*

def writer = new StringWriter()
def html = new MarkupBuilder(writer)
html.html {
   head {
       title 'Simple document'
   }
   body(id: 'main') {
       h1 'Building HTML the Groovy Way'
       p {
          mkp.yield 'Mixing text with '
          strong 'bold'
          mkp.yield ' elements.'
       }
       a href: 'more.html', 'Read more...'
   }
}

 

Output:

<html>
 <head>
   <title>Simple document</title>
 </head>
 <body id='main'>
   <h1>Building HTML the Groovy Way</h1>
   <p>Mixing text with
     <b>bold</b> elements.
   </p>
   <a href="more.html">Read more..</a>
 </body>
</html>

Endret av siDDIs
Lenke til kommentar

Det velger du sjølv, I Groovy for Grails så kan du bruke taglibs og eller plugins for sånne ting. Eg foretrekker å gjere det manuelt sidan eg hater rammeverk som Prototype som forsøpler standardfunksjonalitet i Javascript.

 

Taglib eksempel i Grails

<div id="message"></div>
<g:remoteLink action="delete" id="1" update="message">Delete Book</g:remoteLink>

 

Controller har då ein action delete som gjer følgende

def delete = {
     def b = Book.get( params.id )
     b.delete()
     render "Book ${b.id} was deleted"
}

Endret av siDDIs
Lenke til kommentar

Når det gjelder din ide, så høres den bra ut i utgangspunktet, men jeg tror implentasjon vil bli rotete. Du blander flere logiske ting, og tror det vil ha en tendens til å stå i veien for det man tenker å lage.

 

Implementasjonen vil ikke nødvendigvis bli rotete dersom man bruker tid på å planlegge skikkelig først, samt skrive test-cases slik at man får en feeling av hva som virker, og ikke virker, før man enes om hvordan språket burde være.

 

Det å blande flere logiske ting er ikke nødvendigvis en uting, og ett system som beskrevet over de siste sidene vil fortsatt tillate å adskille presentasjon og business-logikk, selv om det vil være 'orndtlig' kode involvert i presentasjonslaget.

 

En større abstraktifisering av webside utvikling vil bare forstørre det problemet, og man må trolig enten lage et ganske komplisert system for å la utvikleren endre ting slik han trenger det, eller utvikler må bruke lang tid på å gå rundt språket for å oppnå det han vil/trenger.

 

Det er ingenting i veien for å ordne så utvikleren kan outpute raw html og javascript. Og dersom noen av kontrollene ikke passer til funksjonen er det flere måter problemet kan løses på.

Utvikleren kan extende klassen som passer best, og override de tingene i denne som ikke passer til bruken.

Han kan outpute raw html, som sagt. Dette kan til og med inkluderes greit med språkets mekanismer for å sende data frem og tilbake mellom server og nettleser.

 

 

Slik jeg ser det vil man løse mange problemer med å fjerne utvikler fra html og javascript. Det vil bli enklere å lage dynamiske sider, det vil bli enklere å skrive sider som alltid er XHTML strict kompatible, det vil ta mye mindre tid å skrive websider som er ganske kompliserte, og det kan gjøres med mindre kode.

 

 

Det er klart, noen nye problemer vil alltid oppstå, men jeg mener det er ett stort vei frem fra dagens ordninger.

Lenke til kommentar
  • 2 uker senere...

Hvis man ser bort ifra javascript biten så er vel HAML og SASS noe som nærmer seg det du er ute etter litt?

 

http://haml-lang.com/

http://sass-lang.com/

 

#profile
 .left.column
   #date= print_date
   #address= current_user.address
 .right.column
   #email= current_user.email
   #bio= current_user.bio

 

// Sass

!blue = #3bbfce
!margin = 16px

.content_navigation
 border-color = !blue
 color = !blue - #111

.border
 padding = !margin / 2
 margin = !margin / 2
 border-color = !blue

 

-C-

Lenke til kommentar
  • 4 uker senere...

MVC er ikke noe problem i PHP. Flere rammeverk for PHP bruker MVC. Selv i små prosjekter uten MVC skiller man på presentasjon og php med f.eks. Smarty. PHP får noen ganger litt ufortjent kritikk, men det er vel litt avsporing fra temaet i denne tråden å kommentere enkeltspråk noe videre. :)

Lenke til kommentar

Det er ingenting i veien for å ordne så utvikleren kan outpute raw html og javascript. Og dersom noen av kontrollene ikke passer til funksjonen er det flere måter problemet kan løses på.

Utvikleren kan extende klassen som passer best, og override de tingene i denne som ikke passer til bruken.

Han kan outpute raw html, som sagt. Dette kan til og med inkluderes greit med språkets mekanismer for å sende data frem og tilbake mellom server og nettleser.

 

Det høres ut som om du beskriver Weblocks widgets...

Lenke til kommentar

Vel, idéen er å gjøre HTML, CSS og JavaScript til ett eneste sømløst backend språk.

Har du titta på >Vaadin? Da slipper du å forholde deg til alt det web-rælet. Glimrende, medmindre man har noen webdesignere som også må sysselsettes...

Lenke til kommentar

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

 

html {

 

}

 

Er jo veldig likt

 

<html>

 

</html>

... for ikke å nevne

 

write("</div>");

 

...

 

Syns ikke det er abstrahert vekk så veldig mye når begreper som div og body etc. henger igjen ...

Endret av quantum
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...