Misschien bestaat het, misschien niet. Maar ik ben op zoek naar een HTML editor (geen WYSIWYG) waar een CMS functie bij zit, zodat de opdrachtgever zelf teksten aan kan passen naderhand. En dan ook nog het liefst met responsive webdesign in de editor.
Ik wil graag vasthouden aan mijn HTML en CSS kennis, dus wil niet overstappen naar bv Wordpress.
Mirabyte Web Architect Professional komt in de buurt, maar ik kan niet terugvinden of deze ook responsive heeft. Iemand suggesties?
5 antwoorden
Gesponsorde links
Thomas - 09/11/2014 14:40 (laatste wijziging 09/11/2014 14:46)
Moderator
Dit klinkt een beetje als "ik wil een huis bij mijn badkamer". Een CMS voert meestal meer functies uit dan enkel (versie)beheer van content (dit laatste is waarschijnlijk wat je bedoelde?).
Het weinige wat ik weet van responsive webdesign is dat als een website responsive is, deze zich aanpast aan en meeschaalt met de beschikbare breedte van het apparaat waar de site op bekeken wordt. Dit wordt (correct me if I'm wrong) in eerste instantie / voornamelijk bereikt door media queries. Media queries zijn onderdeel van CSS3. Ik weet niet of tools het responsive maken van je site echt kunnen automatiseren, dit hangt - voor zover ik heb begrepen - sterk af van je content.
Omdat responsiveness een sterke visuele aangelegenheid is, klinkt het een beetje paradoxaal om te zeggen dat je hiervoor geen WYSIWYG editor wilt gebruiken. Het vaststellen van je layout "breekpunten" moet visueel gebeuren vanwege de afhankelijkheid van je content (en opmaak, uiteraard).
Dan iets anders: er zijn tegenwoordig een heleboel websites "nieuwe stijl" met veel grafische elementen en weinig tekst, maar als ik mij een voorstelling moet maken van een wat traditionelere webpagina dan valt deze als volgt uiteen:
- de algemene layout van een pagina (je "maintemplate")
- navigatiemenu's in header en footer
- wat extra rijen/kolommen met blokjes informatie
- de "hoofd content" van je pagina, die een directe link heeft met de metadata van die webpagina
Ik ga er vanuit dat als je "zodat de opdrachtgever zelf teksten aan kan passen naderhand" zegt, je het aanpassen van deze "hoofd content" bedoelt, en niet het aanpassen van de hele webpagina (die opgedeeld is in eerdergenoemde onderdelen)? En ik hoop voor jou dat die opdrachtgever zelf ook bekwaam is in HTML/CSS?
Het punt is dus een beetje: meestal zijn websites van tegenwoordig dynamisch van aard - dit zijn geen statische HTML-pagina's meer maar een diversiteit aan blokjes content die doorgaans via een serverside scriptingtaal aan elkaar gelijmd worden tot een complete webpagina. Ik begrijp de toepassing die je probeert na te streven niet helemaal eerlijk gezegd.
Toen ik zeer kort geleden begon met het zoeken naar informatie over wat responsive webdesign nu precies betekent, kwam ik het volgende artikel tegen (bekijk ook zeker het filmpje!).
Citaat:
Ik wil graag vasthouden aan mijn HTML en CSS kennis, dus wil niet overstappen naar bv Wordpress.
Het een sluit het ander niet uit, maar het maken van responsive templates in WordPress heeft waarschijnlijk wel een leercurve (heb je hier al op geGoogled)?
Het (aanleren en) gebruiken van systemen zoals WordPress heeft zowel voor- als nadelen. Dit zal altijd zo zijn, welke oplossing je ook kiest, tenzij je zelf een custom tailored ding maakt...
Tijd om je kennis te verruimen? Je hoeft ook niet direct te trouwen met een pakket, maar probeer te bedenken wat je wilt bereiken (enkel versiebeheer van HTML-documenten? of meer?), zoek een aantal alternatieven uit, en probeer ze eens uit.
Bedankt voor je reactie. Mijn bedoeling is inderdaad een HTML/CSS website te maken. En dat de opdrachtgever zelf bijvoorbeeld de prijslijst aan kan passen als de prijzen wijzigen. Dus enkel de tekst/content aanpassen en zeker niet de rest!
Het artikel over responsive is interessant, bedankt voor het doorgeven!
En dat de opdrachtgever zelf bijvoorbeeld de prijslijst aan kan passen als de prijzen wijzigen. Dus enkel de tekst/content aanpassen en zeker niet de rest!
Hmm, in sommige gevallen kan dat misschien uitkomst bieden, maar het lijkt mij persoonlijk veel fout-ongevoeliger om dit via een soort van backend te doen waar je inderdaad alleen maar product-informatie kunt aanpassen (en niet de opmaak ervan).
Hier komt dan wel een scriptingtaal aan te pas want je moet een aantal lagen toevoegen om e.e.a. in goede banen te leiden (denk aan authenticatie, producten-database en een aantal pagina's met formulieren / een formuliersysteem die je data valideert alvorens deze wordt opgeslagen; en dan natuurlijk een aantal lappen code of een templatelaag om alles vervolgens weer te geven).
Het "probleem" van alles via HTML doen is dat je product-data daarin geen "betekenis" heeft (en ook niet af kunt dwingen), tenzij je misschien XML + XSLT gebruikt (ik vind dat zelf niet fantastisch leesbaar)?
Je zou voor een prijs ook "aap" kunnen invullen. Als je dit via XML doet, wordt dit natuurlijk meteen een stuk ondubbelzinniger omdat je je data veel strakker vormgeeft. Zo ook als je je gegevens opslaat in een databasetabel met behulp van een formulier (en een scriptingtaal). Het ligt dan redelijk vast welke vorm je data moet hebben (bijvoorbeeld een getal), en bij de verwerking van je formulier kun je op deze vorm controleren.
Dat kan natuurlijk ook. Beide CMSen gebruiken op zijn beurt wel PHP .
Bij CushyCMS moet je die (web)applicatie FTP-toegang geven tot je webserver haha. Dat demo filmpje laat ook een interessante tekortkoming zien: in dat filmpje wordt een aantal keren een HTML-bestand geupload die dient als homepage (index.html) waarbij classes en id's worden toegevoegd om bepaalde delen editbaar te maken. Maar nadat je je content hebt aangepast kun je dit niet meer doen! Je index.html op je webserver wijkt nu af van je (lokale) origineel. Wat nu als je een layout wijziging wilt doorvoeren? Of als je pagina op een of andere manier "gebroken" is? Layout en content lopen hier (hopeloos) door elkaar.
Dan nog iets anders, wat als je op "maintemplate" niveau iets in je layout wilt wijzigen, elk HTML-bestand is een compleet HTML document (waarschijnlijk?). Al je pagina's updaten is al een hels karwei, maar je moet daarnaast ook nog rekening houden met je "live content" in deze documenten. Als je site geregeld van content / layout wijzigt, lijkt mij dit een regelrechte onderhouds-nachtmerrie .
Tenzij de data in deze "placeholders" apart wordt opgeslagen? Dan zou het nog kunnen misschien, maar wat als je dan een extra placeholder toevoegt in een document? Hoe weet CushyCMS in welke placeholder content geplakt moet worden als de bestaande placeholder en de nieuwe placeholder precies hetzelfde zijn (<div class="cushycms">...</div>)?
Naarmate je sites dynamischer (denk hierbij ook aan resposive websites!) / complexer worden heb je denk ik al heel gauw de behoefte aan een (verdere) ontkoppeling / opdeling van content en layout. Pas als je flink tegen eerdergenoemde obstakels aanloopt zal waarschijnlijk de realisatie komen dat het echt zo fijn is als je "code" (layout, code etc, het "statische" deel van je site) en "content" (database, geuploade documenten etc, het "dynamische" deel van je site) apart kunt behandelen.
Ter vergelijking: met een minimale hoeveelheid PHP-code zou je je maintemplate en het gedeelte waarin content zit al kunnen scheiden. Als CushyCMS ook de mogelijkheid ondersteunt om delen van HTML-documenten te editen, dan heb je met een simpele ingreep dus al effectief (of voor een groot deel) je content en je layout gescheiden. Hiermee introduceer je wel weer andere problemen maar goed .
Bij bovenstaande pakketten wordt een tradeoff gemaakt tussen gebruikersgemak en "blootstelling aan PHP" om het zo maar te noemen. Je betaalt hier wel een (naar mijn mening te) hoge prijs voor... (en bij CushyCMS een maandelijks bedrag, als je besluit voor de Pro variant te gaan)
Ah well, to each his/her own.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
.
Actiefste leden van de maand
