Toon posts:

[Discussie] Verschillende programeer / script talen

Pagina: 1
Acties:
  • 220 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Beste tweakers,

Momenteel kijk ik naar verschillende webtechnieken om dynamisch content in een browser te tonen. Ik word helemaal dol van de verschillende talen en dialecten. Ik zie door de bomen het bos niet meer. 8)7

Wat heb je zoal (zal wel wat vergeten zijn);
  • clientside scripttaal: Javascript, actionscript
  • Communicatie/protocol: SOAP, xml, rss, JSON
  • Communicatie/techniek: ajax
  • markup talen:html, xhtml, xml
  • opmaak: css, xslt
en ga zo maar door. Ik laat hier de verschillende SQL-databases en server-sided-scripting talen achterwege.


Ik begrijp niet zo goed wanneer je dynamisch ("Rich") een pagina wilt laten werken zonder de hele pagina moet updaten dat je dmv. Javascript, XML en serversided-taal te werk moet gaan. Waarom moet je van taalA naar taalB om met taalC te communiceren. Wanneer ik met een Duitser wil praten ga ik toch ook niet eerst eerst met een Engelsman praten waarna hij aan de duitser mijn verzonden bericht doorgeeft. Rechtstreeks met de Duitser commuiceren is toch het meest effecient. Men heeft zelf invloed op de Javascript en de server-sided-scripts. Waarom kan je niet zorgen dat bv. rechtstreeks met Javascript en vice versa interactie heeft. Een 'boodschapper'-taal lijkt mij ook niet gunstig voor de prestaties. 100 meter sprint doet men niet in estafette verband!

Ik begrijp dat je 2 verschillende applicaties makkelijk met xml kan laten communiceren wanneer men geen invloed op een of beide applicaties heeft. Ik heb een artikel gelezen waarbij xml veelal als ellende wordt beschouwd. Is XML wel Nuttig? Nut of Hype:

http://www.lizatec.com/LI...JvM3cyhkYgCFUZtMAodxUXK_w


Ik heb iets gevonden over PHP <---> Flash. Hier komt GEEN xml aan te pas!
AMFPHP is an open-source Flash Remoting gateway. It’s fast, reliable, 100% free and open-source. Flash Remoting is a technology built into the Flash player core that enables sending data between the server and the client seemlessly. If you've built XML-based RIAs you know how much of a pain it can be to serialize the data, debug, and integrate into your application.With Flash Remoting, you can call remote methods from the Flash client and the arguments will end up in the native remote language, and will come back to Flash correctly typed, so there's no messing with serialization at all.
http://www.amfphp.org

Heeft iemand een heldere uitleg voor de hedendaagse talen-spaghetti? Wanneer zou men het best voor de ene oplossing kunnen gaan en wanneer voor de andere?

[ Voor 4% gewijzigd door Verwijderd op 24-10-2006 12:40 . Reden: Advies gekregen om beter in te delen. ]


  • XWB
  • Registratie: Januari 2002
  • Niet online

XWB

Devver
Ik begrijp niet goed waarom je daar zo druk over maakt. Als je geen 10 technieken door elkaar wil gebruiken dan doe je dat toch niet? HTML voor documenten, CSS voor je opmaak en PHP als scripttaal en klaar ben je (om maar een voorbeeld te geven). Voor webapplicaties, zoals een site backend ofzo, zijn technieken als AJAX best handig. Het werkt gewoon prettiger dan steeds de pagina te moeten herladen en dat soort dingen. Maar wederom, je bent niet verplicht deze te gebruiken.

Overigens, of XML handig is? Vind van wel, ik werk er best vaak mee en het is erg handig om met andere applicaties (in een andere taal als bv C#) te communiceren. En eerlijk gezegd heb ik er nog nooit problemen met gehad. Ook voor AJAX laat ik de resultaten in XML formaat terug keren, dat kan je dan heel makkelijk via het DOM aanspreken.

Ik heb er trouwens geen probleem mee om een 5-tal technieken bij elkaar te gebruiken. Zolang je het maar overzichtelijk kan houden :)

March of the Eagles


  • MIster X
  • Registratie: November 2001
  • Laatst online: 01-01 23:41
De talen/technieken die je noemt zijn niet met elkaar te vergelijken of onderling uitwisselbaar. Jij zou het liefst één taal/techniek zien waarmee je alles kunt doen waar je nu meerdere talen/technieken voor nodig hebt?

Wel, er is inderdaad behoefte aan bepaalde standaarden, maar die moeten gewoon nog ontwikkelt worden. Internet is nog relatief jong en dat brengt met zich mee dat men uit ontevredenheid met bestaande talen en technieken nieuwe initiatieven neemt. Daardoor ontstaan nieuwe talen/technieken. Net als bij echte talen ontwikkelen zich nu dan dialecten, die op hun beurt weer uitgroeien tot zelfstandige entiteiten. En in de loop van de tijd zullen veel ervan weer uitsterven.

Erg IRL eigenlijk :)

  • Cyphax
  • Registratie: November 2000
  • Laatst online: 23:05

Cyphax

Moderator LNX
Verwijderd schreef op dinsdag 24 oktober 2006 @ 10:20:
Ik begrijp niet zo goed wanneer je dynamisch ("Rich") een pagina wilt laten werken zonder de hele pagina moet updaten dat je dmv. Javascript, XML en serversided-taal te werk moet gaan.
Je hebt XML niet nodig, kan ook prima zonder. Hou je over: Javascript, een algemeen geaccepteerde techniek om op een statische pagina alsnog acties uit te voeren, en een serverside taal. In principe kun je zonder die serverside taal ook uit de voeten maar je moet toch IETS ophalen, nietwaar? Dat kan ook de inhoud van een bestand zijn. Dan heb je alleen nog maar Javascript over.

De keuze is aan jou. Het is juist geweldig dat bestaande technieken zo gecombineerd kunnen worden.. stel je voor dat dit hele principe in een nieuwe standaard had geresulteerd, dan hadden we weer iets moeten verzinnen om onze javascript/PHP/XML/whatever-applicaties daaraan te linken.

Verder noem je een hele lijst aan technieken op maar die kan korter he: SOAP en RSS zijn al gewoon XML, niet meer, niet minder. Ajax is een combo van XML en Javascript. Actionscript is een taal die gebruikt wordt in Flash. Lijkt heel erg op Javascript maar heb je niets mee te maken als je geen Flash gebruikt.
XHTML is trouwens ook XML. Je kiest ervoor je document een HTML of een XHTML document te laten zijn maar dat zijn maar formaliteiten (even los van of en hoe browsers ermee omgaan).

[ Voor 20% gewijzigd door Cyphax op 24-10-2006 11:26 ]

Saved by the buoyancy of citrus


  • moozzuzz
  • Registratie: Januari 2005
  • Niet online
MIster X schreef op dinsdag 24 oktober 2006 @ 10:56:
De talen/technieken die je noemt zijn niet met elkaar te vergelijken of onderling uitwisselbaar.
Inderdaad, ik denk dat je 't een en 't ander door elkaar mixed.

Javascript bvb heeft niets te zien met HTML. Ik zou bij de jouw opgegeven termen dan ook een opsplitsing willen maken tussen:
  • clientside scripttaal
    Javascript, actionscript
  • serverside scripttaal
    asp, php, jsp (? deze laatste ken ik niet in de praktijk, weet niet of het niet eerder een techniek te noemen is. anyone?)
  • Communicatie/protocol
    SOAP, xml, rss
  • Communicatie/techniek
    ajax

  • InZane
  • Registratie: Oktober 2000
  • Laatst online: 20:03
MIster X schreef op dinsdag 24 oktober 2006 @ 10:56:
De talen/technieken die je noemt zijn niet met elkaar te vergelijken of onderling uitwisselbaar. Jij zou het liefst één taal/techniek zien waarmee je alles kunt doen waar je nu meerdere talen/technieken voor nodig hebt?
Inderdaad en sommige technieken zijn ook nog eens een combinatie van verschillende talen, dus niet een taal op zich.

AJAX is bijvoorbeeld een combinatie van (X)HTML, CSS, javascript en evt. een server-side taal.

Verwijderd

InZane schreef op dinsdag 24 oktober 2006 @ 12:21:
Inderdaad en sommige technieken zijn ook nog eens een combinatie van verschillende talen, dus niet een taal op zich.

AJAX is bijvoorbeeld een combinatie van (X)HTML, CSS, javascript en evt. een server-side taal.
Strikt genomen heeft Ajax toch niets met CSS te maken? De afkorting betekent iets in de trant van "Asynchroon JavaScript en XML". Dat het veelal gebruikt wordt in combinatie met CSS en een server side taal is waar, maar je kunt ook gewoon een statische XML-pagina ophalen en je opmaak met HTML regelen.

Verwijderd

Topicstarter
Eigenlijk vind ik de discussie niet zo interresant dat ik mijn lijst niet goed heb ingedeeld (heb ik trouwens aangepast), maar wil discussie opgang brengen wat nou het meest handig is een bepaalde situaties. Ik ben zeker geen guru op gebied van scripting talen en communicatie technieken. Het internet wordt helemaal overspoelt met tutorials, howto's en articles over hoe maar in mijn ogen vrij weinig over waarom die techniek.

Waarom zou je er voor kiezen om bijvoorbeeld dmv. php, xsl, xml en css, javascript een webapplicatie te bouwen die ook met alleen php,javascript en css is te verwezenlijken, of php en actionscript ( dmv. amfphp) wanneer er gebruik van Flash/Flex wordt gemaakt. Misschien mis ik hier weer het eea. maar het gaat om de grote lijn.

Verwijderd

Verwijderd schreef op dinsdag 24 oktober 2006 @ 12:37:
Waarom zou je er voor kiezen om bijvoorbeeld dmv. php, xsl, xml en css, javascript een webapplicatie te bouwen die ook met alleen php,javascript en css is te verwezenlijken, of php en actionscript wanneer er gebruik van Flash/Flex wordt gemaakt. Misschien mis ik hier weer het eea. maar het gaat om de grote lijn.
Ervaring speelt een grote rol bij het maken van die keuze. De meeste webdevvers zijn begonnen met HTML. Daar is in de loop van de tijd JavaScript bijgekomen (onMouseOver) en als het goed is ook CSS. Met die basis wordt gestaag verdergewerkt. Na een tijdje ontstaat de wens pagina's dynamisch te maken en wordt er geëxperimenteerd met ASP en PHP. Vier maanden later is de PHP-code amper meer te debuggen en verdiept de webdevver zich in de wereld van sjablonen. Tijdens de zoektocht naar sjabloontechnieken komen XML en XSLT naar voren, en wordt daarmee gewerkt.

Kortom, het leren van nieuwe technieken komt doorgaans voort uit de wens een probleem of ongemak op te lossen. Zodoende behoud je het overzicht: je weet precies waarom je je een bepaalde techniek hebt eigengemaakt. Kom je een dergelijk probleem nog eens tegen of voorzie je dat, dan grijp je terug naar je ervaring met andere projecten.

Mijn advies: scheidt het podium (website) van de kleedkamer (programmacode). Zoek eerst uit welke technieken je client side wilt toepassen en ga dan kijken op welke manier je dat achter de schermen organiseert. Sever side moet je altijd de balans zoeken tussen eenvoud (goedkoper, want meestal sneller te realiseren) en onderhoudbaarheid (een webproject begint pas te leven zodra de eerste versie online is). (Natuurlijk sluiten eenvoud en onderhoudbaarheid elkaar niet altijd uit.)

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10-02 15:42

Janoz

Moderator Devschuur®

!litemod

Verwijderd schreef op dinsdag 24 oktober 2006 @ 12:37:
Waarom zou je er voor kiezen om bijvoorbeeld dmv. php, xsl, xml en css, javascript een webapplicatie te bouwen die ook met alleen php,javascript en css is te verwezenlijken, of php en actionscript ( dmv. amfphp) wanneer er gebruik van Flash/Flex wordt gemaakt. Misschien mis ik hier weer het eea. maar het gaat om de grote lijn.
Ik vraag me af of je helemaal doorhebt wat elk van die termen inhoud. Bij de eerste twee vergelijkingen gooi je xml en xsl er tussen. Het is maar net of je dat nodig hebt. Zml is gewoon een afgesproken manier voor het structureren van data. Het is handig om dit te gebruiken wanneer je tussen twee entiteiten aan het communiceren bent. Het voordeel is dat er een heleboel tools en libraries geschreven zijn. Als je echter nooit communiceerd met andere onderdelen dan heb je het misschien wel helemaal niet nodig.

Xsl is vervolgens een manier om simpel het ene xml formaat om te kunnen zetten in het andere formaat. Dit gebruik je pas wanneer je dit nodig hebt. Het is dus niet "Ik wil xsl gebruiken dus even kijken wat ik er mee moet doen", maar eerder "Ik moet dit doen, volgens mij is het wel handig om hier xsl voor te gebruiken".

Je laatste opsomming (amfphp en flash/flex) is eigenlijk nauwlijks verschillent met je eerste met het verschil dat je geen html+css aan de voorkant hebt, maar een swf. Grappig detail is trouwens dat de communicatie tussen de swf en de phpamf gewoon weer in XML is ;). Omdat dit echter is afgeschermt merk je hier weinig van.

Je lijstje kun je beter zien als een gereedschapkist. Afhankelijk van de situatie combineer je de verschillende technieken. Moet het gelikt met veel animatie zijn met veel interactie met de gebruiker? Dan kun je flash overwegen. Aan de serverkant kun je vvervolgens kiezen voor de macromedia server, phpamf, maar ook voor coldfusion of java. Welke hieruit gekozen wordt is vervolgens weer afhankelijk van de aanwezige kennis, de bereidheid tot het betalen van licentiekosten, de verwachte complexiteit enz enz.

@hieronder: Verrek, je hebt gelijk. Heb ik weer net ietsje teveel aangenomen :D.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
Janoz schreef op dinsdag 24 oktober 2006 @ 13:18:
[...]
Grappig detail is trouwens dat de communicatie tussen de swf en de phpamf gewoon weer in XML is ;).
Alleen jammer dat het niet waar is. AMF is een binair formaat.

  • XangadiX
  • Registratie: Oktober 2000
  • Laatst online: 18-01 18:46

XangadiX

trepanatie is zóó kinderachtig

Ik denk dat je moeilijk doet. Als je een tafel wil timmeren is het niet nodig dat je weet hoe een moterzaag werkt, laat staan dat je weet hoe een las apparaat werkt. Het kan natuurlijk wel. Als je een grote ijzeren tafel wilt bouwen met uhm... ruw afgezaagde houten poten :? ;)

Zo is het ook met al die talen. Als je geen filmpjes, muziek of animaties gaat gebruiken kun je flash al wegstrepen. Zonder database kun je eigenlijk het halve server-side gedeelte ook wegstrepen. Je moet het gewoon andersom zien; wat ga ik maken, en wie moet ik dan wat vragen. (de duitser? de fransoos?) Vervolgens leer je alleen de vraag in de taal die je moet spreken en presto. Weer een site klaar!

Het is ondoenlijk om alles tot in de puntjes te leren, dus leer je wat je moet weten (basiskennis) en breid je die uit op het moment dat je specifieke vragen hebt.

Stoer; Marduq


Verwijderd

Verwijderd schreef op dinsdag 24 oktober 2006 @ 12:31:
Strikt genomen heeft Ajax toch niets met CSS te maken? De afkorting betekent iets in de trant van "Asynchroon JavaScript en XML". Dat het veelal gebruikt wordt in combinatie met CSS en een server side taal is waar, maar je kunt ook gewoon een statische XML-pagina ophalen en je opmaak met HTML regelen.
De term Ajax is bedacht door Jesse James Garett en die heeft de volgende criteria voor een ajax applicatie verzonnen:

* standards-based presentation using XHTML and CSS;
* dynamic display and interaction using the Document Object Model;
* data interchange and manipulation using XML and XSLT;
* asynchronous data retrieval using XMLHttpRequest;
* and JavaScript binding everything together.

http://www.adaptivepath.c...ssays/archives/000385.php

Dus ja, strikt genomen is CSS een onderdeel van ajax (al ben ik het eens me je argument).

Verwijderd

Topicstarter
Verwijderd schreef op woensdag 25 oktober 2006 @ 14:20:
De term Ajax is bedacht door Jesse James Garett en die heeft de volgende criteria voor een ajax applicatie verzonnen.
offtopic:
Jesse James Garret van ¨The elements of user experience¨? Dat boek is echt een aanrader. Hierin staat de gebruiker centraal.

  • JKVA
  • Registratie: Januari 2004
  • Niet online

JKVA

Design-by-buzzword fanatic

Je kunt ook één taal aanhouden. Bijvoorbeeld:
- Client: Java Applet -> server: J2EE
- Client: JavaScript -> server: JavaScript
- Client: Flash -> server: Ook iets Flash/Actionscript achtigs

Op deze manier hou je één methodiek aan. Je hebt dan alleen misschien niet altijd het beste gereedschap voor de klus. Zoals server-side JavaScript zwaar onderdoet voor J2EE.

Vergelijk het maar met gereedschap. Met een ijzerzaag kun je best hout zagen, maar met een houtzaag gaat het beter.

Fat Pizza's pizza, they are big and they are cheezy


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 10-02 15:42

Janoz

Moderator Devschuur®

!litemod

@JKVA: Dat zou ik juist ten sterkste afraden. Een taal is niet hetzelfde als een methodiek. De kanttekening die jij plaatst lijkt me eerder een showstopper. Javascript wil je helemaal niet aan de serverkant gebruiken en een Java Applet is iets dat je eigenlijk alleen gebruikt wanneer je daar erg gegronde redenen voor hebt.

Met een ijzerzaag kun je misschien nog wel hout zagen, maar probeer met een schroefendraaien maar eens een spijker in een plank te slaan.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


  • JKVA
  • Registratie: Januari 2004
  • Niet online

JKVA

Design-by-buzzword fanatic

Janoz schreef op donderdag 26 oktober 2006 @ 09:22:
@JKVA: Dat zou ik juist ten sterkste afraden. Een taal is niet hetzelfde als een methodiek. De kanttekening die jij plaatst lijkt me eerder een showstopper. Javascript wil je helemaal niet aan de serverkant gebruiken en een Java Applet is iets dat je eigenlijk alleen gebruikt wanneer je daar erg gegronde redenen voor hebt.

Met een ijzerzaag kun je misschien nog wel hout zagen, maar probeer met een schroefendraaien maar eens een spijker in een plank te slaan.
"Een taal is niet hetzelfde als een methodiek.". Klopt, een 'licht' verkeerde woordkeus.

Verder was dit voorbeeld vooral ironisch bedoeld, ofwel ik bedoel hetzelfde als jij.

Gebruik alleen de tools/methodieken/talen die het best geschikt zijn voor jouw specifieke situatie.

Fat Pizza's pizza, they are big and they are cheezy

Pagina: 1