Narrowcasting cms
Hoi allemaal,
Ik ben op dit moment bezig met het ontwikkelen en bedenken van een maatwerk CMS voor 8 narrowcasting schermen voor een cafetaria. Ik wil zowel een backend als een frontend omgeving gaan bouwen. Voordat ik begin wil ik wel goed nadenken over de database opzet en hoe informatie gebruikt wordt binnen de schermen. Uitgangspunt voor dit project is dat het volledig online is en dus ook platform onafhankelijk (dus geen lokale viewer op de pc). Dit brengt echter wel wat vraagstukken met zich mee. In de huidige situatie gebruikt men een divx filmpje waarop dynamisch de prijzen en afbeeldingen verschijnen. Die animaties zou ik ook binnen het CMS willen opnemen (het liefst dat men per element kan bepalen welke animatie er op losgelaten wordt).
Eerste stap die ik nu wil zetten is het inventariseren van welke programmeertalen er nodig zijn om dit te realiseren.
Wie kan in dit verhaal met mij meedenken?
Met vriendelijke groet,
Frits Schapendonk
Ik ben op dit moment bezig met het ontwikkelen en bedenken van een maatwerk CMS voor 8 narrowcasting schermen voor een cafetaria. Ik wil zowel een backend als een frontend omgeving gaan bouwen. Voordat ik begin wil ik wel goed nadenken over de database opzet en hoe informatie gebruikt wordt binnen de schermen. Uitgangspunt voor dit project is dat het volledig online is en dus ook platform onafhankelijk (dus geen lokale viewer op de pc). Dit brengt echter wel wat vraagstukken met zich mee. In de huidige situatie gebruikt men een divx filmpje waarop dynamisch de prijzen en afbeeldingen verschijnen. Die animaties zou ik ook binnen het CMS willen opnemen (het liefst dat men per element kan bepalen welke animatie er op losgelaten wordt).
Eerste stap die ik nu wil zetten is het inventariseren van welke programmeertalen er nodig zijn om dit te realiseren.
Wie kan in dit verhaal met mij meedenken?
Met vriendelijke groet,
Frits Schapendonk
Als je zegt platform onafhankelijk denk ik zelf aan Java. maar in principe zou het ook met php/javascript kunnen.. de vraag is eerder welke programmeer taal ken jij?
Animaties, dan kijk je snel naar Actionscript (flash) of JavaScript (canvas). Dat is dan de frontend.
Qua backend is in principe elke webtaal mogelijk. Bijv. PHP of Asp.NET of Ruby. Stel het is een enorm groot project dan loont het om naar scala te kijken.
Toevoeging op 09/05/2013 23:41:20:
Animaties, dan kijk je snel naar Actionscript (flash) of JavaScript (canvas). Dat is dan de frontend.
Qua backend is in principe elke webtaal mogelijk. Bijv. PHP of Asp.NET of Ruby. Stel het is een enorm groot project dan loont het om naar scala te kijken.
Qua backend is in principe elke webtaal mogelijk. Bijv. PHP of Asp.NET of Ruby. Stel het is een enorm groot project dan loont het om naar scala te kijken.
Toevoeging op 09/05/2013 23:41:20:
Animaties, dan kijk je snel naar Actionscript (flash) of JavaScript (canvas). Dat is dan de frontend.
Qua backend is in principe elke webtaal mogelijk. Bijv. PHP of Asp.NET of Ruby. Stel het is een enorm groot project dan loont het om naar scala te kijken.
De meeste kennis en ervaring zit in PHP. Verder ben ik mij aan het orienteren op HTML5 icm CSS3. Het gebruik van Flash is ook een optie. Echter denk ik dat gelet op de toekomst HTML5 meer mogelijkheden hierin bied. Nou vraag ik mij af wat de beste methode is om de informatie zo dynamisch mogelijk steeds uit te lezen uit de database.
Heeft iemand hier ervaring mee?
Heeft iemand hier ervaring mee?
JavaScript icm AJAX. En aangezien het niet afhankelijk moet zijn van platform of browser zou ik een library gebruiken als jQuery of MooToola. Waarbij de voorkeur dan weer uit gaat naar mootools, aangezien jQuery support voor IE 8 heeft laten vallen
Wouter J op 10/05/2013 10:32:37:
aangezien jQuery support voor IE 8 heeft laten vallen
Daar ben ik het niet mee eens. JQuery zal de oudere IE browsers gaan laten vallen en 2.0 werkt er niet meer op. Maar uit hun eigen aankondiging:
Quote:
jQuery 2.0 is intended for the modern web; we’ve got jQuery 1.x to handle older browsers and fully expect to support it for several more years. If you want, you can serve 2.0 to newer browsers and 1.9 to older ones using our conditional comment trick, but that is not required. The simplest way to support older browsers is to use jQuery 1.x on your site, since it works for all browsers.
JQuery 1.9 kan je dus nog prima gebruiken voor de komende jaren en die ondersteunt de oudere browsers wel.
Gewijzigd op 10/05/2013 11:01:07 door Erwin H
Oke, dus zowel Jquery als Mootools zouden voor de frontend gebruikt kunnen worden. Echter ik wil informatie dynamisch inladen. Bijvoorbeeld prijslijst A middels een slidein zichtbaar laten worden en vervolgens verdwijnen waarna prijslijst B middels een slidein zichtbaar wordt zonder dat de webpage refreshed. Ik heb zitten zoeken op JSON maar vraag mij af of ik het ook op een andere manier kan oplossen.
Erwin, maar 1.9 zal alleen nog maar bugs fixen, geen nieuwe features. Je kan naar mijn mening dus gewoon zeggen dat jQ IE8- heeft laten vallen en 1.9 nog houdt vanwege BC.
Frits, ik zou mijn frontend workflow zoiets doen:
Met een JS library haal je met AJAX data op vanuit een bestand. Dat bestand bevat server side code (bijv. php) en die produceert een JSON string. Deze wordt terug gestuurd naar de eerste pagina. Die toont de slide. Bij de volgende slide geld weer hetzelfde en zo gaat het door.
Frits, ik zou mijn frontend workflow zoiets doen:
Met een JS library haal je met AJAX data op vanuit een bestand. Dat bestand bevat server side code (bijv. php) en die produceert een JSON string. Deze wordt terug gestuurd naar de eerste pagina. Die toont de slide. Bij de volgende slide geld weer hetzelfde en zo gaat het door.
Hoe lang duurt het voor er weer nieuwe features bijkomen en hoe snel verdwijnt IE8 uit de markt? Op dit moment is het marktaandeel al vrij laag en gezien het feit dat de hier genoemde applicatie maar op zeer specifieke clients moet gaan draaien (en dus niet op elke huis, tuin en keuken machine) kan je naar mening dus gewoon zeggen dat het IE8 probleem een 'non-issue' is.
Ik zou de return code overigens niet in JSON doen, dat betekent namelijk dat je client side de JSON weer uit elkaar moet gaan halen en weer moet gaan bewerken tot een pagina inhoud. Via ajax calls kan je ook gewoon complete HTML terugsturen. In dit geval lijkt me dat een betere oplossing omdat je op die manier alleen de aanroep hoeft te doen en bij return direct de hele returnwaarde direct in de pagina plaatst. Zo is je client side code minimaal en is het hele IE8 probleem nog kleiner geworden.....
Ik zou de return code overigens niet in JSON doen, dat betekent namelijk dat je client side de JSON weer uit elkaar moet gaan halen en weer moet gaan bewerken tot een pagina inhoud. Via ajax calls kan je ook gewoon complete HTML terugsturen. In dit geval lijkt me dat een betere oplossing omdat je op die manier alleen de aanroep hoeft te doen en bij return direct de hele returnwaarde direct in de pagina plaatst. Zo is je client side code minimaal en is het hele IE8 probleem nog kleiner geworden.....




