Reacties op: Een Commandline Aanpak voor JavaScript Gebaseerde Interfaces

By: Remco van 't Veer

Remco van 't Veer — Wed, 21 Nov 2007 09:43:12 +0000

Interessant aanpak maar ik heb toch het gevoel dat die extra command processing laag meer problemen op gaat leveren dan ze op zal lossen. Het parsen van deze commandline is namelijk niet zo simpel als je aangeeft. Zo is het voorbeeld dat je geeft, “Add user Rikkert Koppes”, al niet triviaal. Ik de meeste gevallen worden de voor- en achternaam in aparte kolommen opgeslagen en met een naive parser haal ze niet uit elkaar. Okee dan passen ons taaltje aan; “Add user ‘Rikkert’ ‘Koppes’” waar het eerste argument de voor- en het laatste argument de achternaam is. O nee, dat werkt natuurlijk ook niet omdat je altijd uitslovers hebt met een naam als Remco van ‘t Veer.

Als het dan gelukt is om een mooi commandline taaltje te definieren moet deze zowel aan de in de browser als op de server geparsed kunnen worden. In de meeste gevallen betekent dit dat er twee parsers onderhouden moeten worden, hoewel een enkele parser in JavaScript (gratis in Java6) natuurlijk ook een optie is. Zijn er eigenlijk parser generators voor JavaScript?

Waarom zou je geen interne DSL maken met JavaScript? Dus een JavaScript API welke je met een commandline aanbiedt. Dit geeft je het voordeel dat geen parser hoeft te maken en JavaScript is flexibel genoeg om iets gebruikersvriendelijks te produceren. En laten we nou eerlijk zijn “User.add(’Rikkert’, ‘Koppes’)” is toch niet zoveel slechter dan “Add user Rikkert Koppes”? Daarbij kan je dan naast de powerusers ook de technische gebruikers faciliteren; “User.each(function(u){u.firstname==’Rikkert’&&u.delete()})”.

By: Rikkert Koppes

Rikkert Koppes — Fri, 23 Nov 2007 09:40:12 +0000

Je denkt wat te diep na
Het belangrijkste is dat de communicatie op verschillende vlakken gelijk getrokken wordt, dat het redelijk leesbaar is en een afspiegeling is van je use cases. De exacte syntax doet niet zo terzake. Wat ik als voorbeeld heb opgeschreven is een optie, maar als dat niet toereikend is voor de applicatie, gebruik dan wat anders. Wat je bijvoorbeeld zou kunnen doen is:

Add user “Remco” “van ‘t” “Veer”
Add user Remco van_’t Veer
Add user {”firstname”:”Remco”,”infix”:”van ‘t”,”surname”:”Veer”}

Het maakt allemaal niet zoveel uit, als het maar overal hetzelfde is. Als het allemaal te ingewikkeld wordt (uitgebreide datastructuren), moet je eerder gaan nadenken over je datamodel dan over je parser. Wat ik zelf heb is een interpreter die splitst op spaties, waarbij spaties in een parameter kunnen worden meegenomen door ‘m of te vervangen door een underscore, of te omvatten met dubbele quotes. De command handler kijkt vervolgens naar het aantal meegegeven parameters en trekt daar conclusies uit.

By: Peter Maas

Peter Maas — Mon, 26 Nov 2007 10:13:23 +0000

Rikkert, als ik je laatste voorbeeld zie:

Add user {”firstname”:”Remco”,”infix”:”van ‘t”,”surname”:”Veer”}

Vraag ik me af waarom je niet gewoon JSON gebruikt….

DWR (http://getahead.org/dwr), een van de bekendere AJAX bibliotheken vertaald op die manier een set parameters naar een Pojo. Dan krijg je dus:

userService.addUser({”firstname”:”Remco”,”infix”:”van ‘t”,”surname”:”Veer”});

Net zo leesbaar toch, en je hoeft zelf geen parser te schrijven!

By: Rikkert Koppes

Rikkert Koppes — Mon, 26 Nov 2007 11:45:43 +0000

Kan ook, laatste voorbeeld was ook inderdaad bedoeld richting JSON

Punt is: maakt me niet uit, ik heb de inhoud van de doCommand method in m’n artikel niet voor niets weggelaten. Implementatie doet m.i. niet zo ter zake, het gaat me meer om de gedachte: doe de communicatie op alle niveau’s hetzelfde en zorg ervoor dat het leesbaar is en met de hand eenvoudig in te typen.