[cms - interface] wat is gebruikersvriendelijk ?

[Eijkb]

Wat moet je ermee. Zonder een goede backend en veel beschikbare tijd kun je er niets mee.

Nou, DDC zou ze eens kunnen oploaden bv en hier tonen. Zijn wij niet afhankelijk meer van jouw verlengstuk (!?) Overigens heb ik ook wel eens ooit een poging gedaan tot een CMS, nu ik jullie screens zie is het blijkbaar niet meer dan een poging,....maar screens zijn niet voorradig. Overigens, moet een CMS alles kunnen om een CMS genoemd te worden of zijn een paar formpjes om nieuws toe te voegen, te editten en te deleten ook al een CMS?

offtopic:
Ik edit me eigen een ongeluk doordat mensen sneller reageren als ik mijn stukjes tiep. En nee, het gaat niet om minuten maar om seconden.

[ Voor 24% gewijzigd door Eijkb op 23-05-2003 12:39 ]

[drm]

Eijkb:
Nou, DDC zou ze eens kunnen oploaden bv en hier tonen. Zijn wij niet afhankelijk meer van jouw verlengstuk (!?) Overigens heb ik ook wel eens ooit een poging gedaan tot een CMS, nu ik jullie screens zie is het blijkbaar niet meer dan een poging,....maar screens zijn niet voorradig. Overigens, moet een CMS alles kunnen om een CMS genoemd te worden of zijn een paar formpjes om nieuws toe te voegen, te editten en te deleten ook al een CMS?

Nieuws is content (inhoud) van je site, en managen betekent beheren. Ik zou dus niet weten waarom je dat niet al een CMS zou mogen noemen

[Verwijderd]

Het "concept" wat ik heb uitgewerkt tot een CMS moet wel over een degelijke backend en opzet beschikken wil het niet een blok aan het been worden bij updates en nieuwe functionaliteit, anders zou ik je willen afraden om er uberhaupt aan te beginnen.

Iedereen kan bedenken dat je de website in een dergelijke structuur benaderd, sterker nog ik ben de volgende in het rijtje van de al 10.000 cmsén die een dergelijke benadering hebben.

Enige wat het cms zo "speciaal" maakt is wellicht de grafische schil, en als je begrijpt op welke manier het is opgebouwd ook de backend.

[ Voor 9% gewijzigd door Verwijderd op 23-05-2003 12:40 ]

[Verwijderd]

Verwijderd schreef op 23 May 2003 @ 12:35:
[...]


Lees de draad voor je blaat

Heb ik gedaan... maar ja, jouw verlengstuk is even down he...

[Eijkb]

offtopic:
[quote]Nieuws is content (inhoud) van je site, en managen betekent beheren. Ik zou dus niet weten waarom je dat niet al een CMS zou mogen noemen[/quote]

Dan ga ik screenies maken van mijn formuliertje. Kan ook de code geven hoor. Mijn CMS is onder het GNU verhaal geschreven, zeg maar

[Verwijderd]

Eijkb schreef op 23 May 2003 @ 12:36:
Overigens, moet een CMS alles kunnen om een CMS genoemd te worden of zijn een paar formpjes om nieuws toe te voegen, te editten en te deleten ook al een CMS?

Ook het CMS wat ik heb gemaakt is peanuts vergeleken bij grote spelers op de markt hoor. Het kan wel een groot CMS systeem worden, maar dat was voor mij niet eens haalbaar in een dergelijk korte doorlooptijd, en bovendien maak je het qua gebruik en onderhoud ook steeds lastiger.

Een gemiddelde programmeur maakt per uur 2 bugs. Als je dus ontzettend veel functionaliteit gaat toevoegen ben je continue aan het bugfixen, zeker als je het in je uppie hebt gemaakt. Ik probeer expres de zooi back to basic te houden, dat scheelt een hoop gedoe.

Nu kan je bijvoorbeeld wel instellen bij oplevering dat er zaken als drive quotas, workflow, versiebeheer, etc. mag worden geactiveerd. Afhankelijk hiervan krijg je dus extra of minder items in je menu's te hangen.

[ Voor 19% gewijzigd door Verwijderd op 23-05-2003 12:48 ]

[Eijkb]

Om nu even terug te gaan naar het begin. Wat is een klantvriendelijk CMS? We hebben verscheidene mooie screenies voorbij zien komen van "profi" CMS-sen. Hoe weten de ontwikkelaars hiervan bij het programmeren dat ze iets klantvriendelijks maken? Is dat maken, opleveren en vervolgens leren van je fouten voor de nieuwe versie? Is daar aandacht aan besteed in een eventuele opleiding? Is dat ervaring? Vertel!

Gordijnstok, je hebt het over een dergelijke structuur. Misschien domme vraag, maar welke structuur bedoel je?

[Verwijderd]

Eijkb schreef op 23 mei 2003 @ 12:47:
Gordijnstok, je hebt het over een dergelijke structuur. Misschien domme vraag, maar welke structuur bedoel je?

Nou heel simpel. Je komt een heleboel CMS systemen tegen die uitgaan van containers. Een pagina wordt vervolgens opgebouwd uit blocks, met hier een fladder content, en hier een fladder content, en dat wordt allemaal heel gebruiksvriendelijk samengeperst in een content verzamelbak.

De gebruiker weet gewoon op een bepaald moment niet meer, waar hij een bepaald stuk content moet zoeken, en je beperkt je ,ondanks dat het flexibel lijkt, behoorlijk.

Waarom niet gewoon de structuur direct overnemen in een treeview zoals je door een site navigeert?

En wat betreft gebruiksvriendelijkheid, tja, ik denk dat ervaring wel een beetje meetelt ook in het ontwikkelen. Qua ontwikkelen zijn grenzen beter te overschrijden die normaliter maar op een andere manier worden opgelost omdat men niet weet hoe het gedaan moet worden.

Verder heb je altijd heel veel aan collega's en vrouwen. Niet lullig bedoeld, maar een vrouw is echt het prototype computer nitwit (moet eigenlijk zeggen, de meeste vrouwen). Kortom gewoon gebruik van maken. Verder kun je altijd informatie inwinnen van de mensen die support leveren. Waar mensen vastlopen, over welk onderwerp worden veel vragen gesteld, etc.

[ Voor 30% gewijzigd door Verwijderd op 23-05-2003 12:57 ]

[alienfruit]

Ik heb altijd het idee, dat de beheerfunctie ter aller tijden moet kunnen worden aangepast aan de klant, daarom worden er sessie's gehouden waarbij de klant de beheerfunctie kan testen en vervolgens commentaar en suggestie's kan geven, om het te verbeteren. Dit is onderdeel vande quality assurance (bij onderdeel van de ALM) na mijn idee.

Verder heb ik wel intresse in welke taal Gordijnstok's cms is geschreven (oh heb ik nog geen screenshot gezien); ik heb hem nu geschreven in PHP; wat ik zelf toch niet echt een geschikte taal hiervoor vind. Ik ben zelf naar Java en/of .NET aan het orientiëren. Waarbij ik zelf denk dat het een goed idee is om het te schrijven in .NET; of anders dmv. Jeneva in .NET en Java.

Verder heb je altijd heel veel aan collega's en vrouwen. Niet lullig bedoeld, maar een vrouw is echt het prototype computer nitwit

Nou, Astrid Hackenberg is echt geen nitwit hoor

[ Voor 14% gewijzigd door alienfruit op 23-05-2003 13:05 ]

[Eijkb]

Ik heb altijd het idee, dat de beheerfunctie ter aller tijden moet kunnen worden aangepast aan de klant, daarom worden er sessie's gehouden waarbij de klant de beheerfunctie kan testen en vervolgens commentaar en suggestie's kan geven, om het te verbeteren. Dit is onderdeel vande quality assurance (bij onderdeel van de ALM) na mijn idee.

Het moet inderdaad aangepast worden aan de klant. Maar wat doen al die standaardpakketten dan op de markt? Als een soort lokmiddel om vervolgens de klant te kunnen factureren op het aantal uren dat je bezig bent aan te passen?

[Verwijderd]

alienfruit schreef op 23 mei 2003 @ 13:00:
Nou, Astrid Hackenberg is echt geen nitwit hoor

Je noemt nu ook een individu. Niet alle vrouwen zijn een ramp op het gebied van computergebied, dat bewijst die vrouw gelukkig maar weer eens.

Wat betreft de taal.

Backend:
MS SQL Server 2000 Enterprise
Macromedia ColdFusion Server 5 Enterprise

ColdFusion code is met een OO benadering geschreven, en dit geld ook voor de directory structuur (hier ga ik niet alteveel over uitleggen).

Alle transacties lopen via stored procedures.

Frontend:
gebruikelijke html, js, exploits (of features), xslt en xml

Er valt nog een hoop snelheidswinst te behalen. Ik heb me nog niet volledig kunnen orienteren op tuning etc.

[Verwijderd]

alienfruit schreef op 23 May 2003 @ 13:00:
Ik heb altijd het idee, dat de beheerfunctie ter aller tijden moet kunnen worden aangepast aan de klant

Ik heb altijd het idee, dat de beheerfunctie zo goed is opgezet en zo duidelijk is, dat er geen aanpassingen meer nodig zijn.

Ik wil absoluut voorkomen dat elke klant die van het systeem gebruik wil maken, aanpassingen vereist in de core van het systeem. Je werkt zo heel snel bugs in de hand. Een workaround voor de ene klant, kan per ongeluk een bug zijn voor een andere klant, zeker als er onder extreme tijdsdruk wordt gewerkt.

[mulder]

Komt me toch bekend voor dat cms Gordijnstok

En idd een tree is goud waard, een component dat in (web)applicaties z'n sporen heeft wel heeft verdient.

alienfruit: waarom vind je PHP niet geschikt, prima taal en kan imho in principe het zelfde als bv het hier bovengenoemde ColdFusion (wat ik nooit echt geweldig heb gevonden)

[Verwijderd]

Don Facundo schreef op 23 May 2003 @ 14:18:
Komt me toch bekend voor dat cms Gordijnstok

Eindelijk die vieze groene kleuren weg

[ Voor 62% gewijzigd door Verwijderd op 23-05-2003 14:36 ]

[alienfruit]

Ik vind PHP niet echt OO, je kunt er prima dingen mee doen hoor. Ik werk zelf liever met Java en/of .NET. Ik heb inmiddels besloten dat ik maar een .NET versie ga bouwen gezamelijk met BDP en C#Builder; heb ik tot 6juni de tijd voor Research

Ik ben van mening dat de beheerfunctie niet onderdeel uit maakt van de core functionaliteit van een cms; en dus eigenlijk onderdeel is van iets anders. Zodoende zou je het dus kunnen aanpassen voor de gebruiken; gezien het feit dat mijn online beheerfunctie binnen het cms draait (like Delphi in Delphi ) kun je dus via templates e.d. gemakkelijk de beheerfunctie aanpassen voor de gebruiker.

[Verwijderd]

alienfruit schreef op 23 May 2003 @ 14:36:
Ik vind PHP niet echt OO, je kunt er prima dingen mee doen hoor. Ik werk zelf liever met Java en/of .NET. Ik heb inmiddels besloten dat ik maar een .NET versie ga bouwen gezamelijk met BDP en C#Builder; heb ik tot 6juni de tijd voor Research

Ik ben van mening dat de beheerfunctie niet onderdeel uit maakt van de core functionaliteit van een cms; en dus eigenlijk onderdeel is van iets anders. Zodoende zou je het dus kunnen aanpassen voor de gebruiken; gezien het feit dat mijn online beheerfunctie binnen het cms draait (like Delphi in Delphi ) kun je dus via templates e.d. gemakkelijk de beheerfunctie aanpassen voor de gebruiker.

In principe is ook de beheerfunctie onderdeel van een stukje core. als jij objecten en properties via een centraal punt insert, updated, en deleted wil je niet dat centrale punt telkens moeten aanpassen.

[alienfruit]

Sorry, Gordijnstok maar ik doelde meer op de vormgevings aspect van de beheerfunctie.

Overigens vind ik het databasebeheer maar een stukje van een core-component; zodoende heb ik een klasse die verschillende dingen ondersteund zoals triggers e.d. voor als men gebruik maakt van MySQL e.d.

Hier onder een foto van een beheerfunctie van een web-site die gebruikt maakt van een verouderde cms (noem ik zelf niet echt een cms; mist zekere essentiele delen van een cms; deploy management, versioning, rollback support e.d.).





Momenteel ben ik samen met de database analist/ontwerper bezig met het implementeren van een xml database voor iig de assets management.

[ Voor 104% gewijzigd door alienfruit op 23-05-2003 15:05 . Reden: %#$%$# trage internet hier 8)7 ]

[Verwijderd]

Wat een hoop tables, waarom wordt er een password history opgeslagen, en waarom sla je artikelen apart op, en niet als een object artikel, met de properties in een andere table?

[Skef]

offtopic:
Gordijnstok, ik las in een ander topic dat jij de complete icon-set en stijl van WinXP hebt. Zou je me daar op een of andere manier een versie van kunnen leveren?

[Verwijderd]

Skef schreef op 23 mei 2003 @ 15:26:

offtopic:
Gordijnstok, ik las in een ander topic dat jij de complete icon-set en stijl van WinXP hebt. Zou je me daar op een of andere manier een versie van kunnen leveren?

Zou ik even moeten zoeken waar ik die heb gelaten

[Verwijderd]

alienfruit schreef op 23 May 2003 @ 14:36:
Ik vind PHP niet echt OO, je kunt er prima dingen mee doen hoor. Ik werk zelf liever met Java en/of .NET. Ik heb inmiddels besloten dat ik maar een .NET versie ga bouwen gezamelijk met BDP en C#Builder; heb ik tot 6juni de tijd voor Research

Wat ik dus zo jammer vind van .NET zijn die eeuwige postbacks. Dat maakt een applicatie zo traag. Ik kom bijvoorbeeld calendar controls tegen, die voor iets simpels als een datum selecteren, of het wijzigen van een maand al meteen een postback doen. Je bent wat dat betreft heel beperkt in controle over je pagina.

[alienfruit]

Wat een hoop tables, waarom wordt er een password history opgeslagen, en waarom sla je artikelen apart op, en niet als een object artikel, met de properties in een andere table

Ooh dat is een winkelwagen pagina dat is gewoon geintregeerd.

Gordijnstok, ik las in een ander topic dat jij de complete icon-set en stijl van WinXP hebt. Zou je me daar op een of andere manier een versie van kunnen leveren?

Kunt ze gewoon kopen bij www.glyfx.com hoor

[thomasfilius]

Die iconset is idd erg goed, zou je hem publiekelijk beschikbaar willen maken? Ben er namelijk ook wel in geinteresseerd.

Voor mij 1 van de grootste frustraties bij het bouwen van webapplicaties: geschikte iconen vinden, met name in 1 bepaalde stijl.

@ alienfriut:
thanks, k'heb er gelijk 1 gekocht. zijn wel erg prijzig maar superhandig.
@ gordijnstok:
ben echter nog steeds geinteresseerd in die iconset van jou

[ Voor 26% gewijzigd door thomasfilius op 23-05-2003 17:03 ]

[alienfruit]

@gordijnstok laat mij je plaatjes eens zien! Kan ik jouw iconset ook checken
@thomas ja, wel duur maar zijn wel mooi!

[Verwijderd]

nou gordijnstok, je vrimibo is weer over, hup naar huis om ons tweakers je plaatjes te laten zien...

[thomasfilius]

Voor de ongeduldige onder u, de CMS van gordijnstok:



Voor de nieuwsgierige onder u:

Veel van de javascripts die hier worden gebruikt zijn (denk ik) die van WebFX. Grotendeels van de kunsten die Gordijnstok ons hier laat zien zijn daar te vinden. Zelf gebruik ik ze voor al mijn webapplicaties en hebben ze nagenoeg ook hetzelfde uiterlijk.

WebFX

[flashin]

ah bedankt. Kan ik ook ff wat moois maken

ik vind zelf deze mooi (als hij nog niet genoemd is ):
http://www.solutior.nl/spidox.demo/content.asp?init=1

Slepen en alles !

[Verwijderd]

thomasfilius schreef op 23 May 2003 @ 18:09:
Voor de ongeduldige onder u, de CMS van gordijnstok:

[afbeelding]

Voor de nieuwsgierige onder u:

Veel van de javascripts die hier worden gebruikt zijn (denk ik) die van WebFX. Grotendeels van de kunsten die Gordijnstok ons hier laat zien zijn daar te vinden. Zelf gebruik ik ze voor al mijn webapplicaties en hebben ze nagenoeg ook hetzelfde uiterlijk.

WebFX

Het contextmenu komt inderdaad van webfx. Die bieden de beste opties is bijna bugvrij, en het scheelt je heel veel ontwikkeltijd. Het tree component zou ik niet willen aanraden. Het is helaas te buggy als je custom zaken wilt doen.

Overigens kwam ik nog een site tegen die ook ontzettend toffe dingen had in xp style. Het is helaas allemaal vbscript, maar dat was nog toffer dan webfx.

[ Voor 14% gewijzigd door Verwijderd op 23-05-2003 18:44 ]

[DeverauX]

Overigens kwam ik nog een site tegen die ook ontzettend toffe dingen had in xp style. Het is helaas allemaal vbscript, maar dat was nog toffer dan webfx.

Heb je misschien ook een link van deze site

[Verwijderd]

DeverauX schreef op 23 May 2003 @ 18:47:
[...]

Heb je misschien ook een link van deze site

http://www.stedy.com/

[DeverauX]

Verwijderd schreef op 23 mei 2003 @ 18:56:
[...]
http://www.stedy.com/

Thanx. Ik had namelijk ook al eerder naar WebFX gekeken en sommige hiervan werken toch nog niet helemaal perfect en was dus eigenlijk wel opzoek naar iets anders

[Verwijderd]

DeverauX schreef op 23 May 2003 @ 19:02:
[...]

Thanx. Ik had namelijk ook al eerder naar WebFX gekeken en sommige hiervan werken toch nog niet helemaal perfect en was dus eigenlijk wel opzoek naar iets anders

Vooral de tree werkt.. *kuch* slecht. Browser die freezed, meerdere focusses, als je cut & paste zelf maakt, dan worden parent en childs geselecteerd, reloads selecteren parents, en als je daarna childs selecteerd ook meerdere selecties, timeouts niet geregeld voor node settings, etc. een ramp.

[Dennis]

Ik heb het menu van brainjar.com gisteren weer eens gedownload en dat is redelijk simpel aan te passen naar Office 2003 lay-out. Dat is me tot nu toe gelukt.

[djluc]

Dat namaak menuutje van internet explorer op http://www.stedy.com/ werkt niet echt lekker. Als je het menu wilt verlaten moet je ect op het knopje zelf drukken, je mag dus niet ergens anders klikken. Waarschijnlijk was dit niet mogelijk door het gebruik van frames op hun site.

Die tree van Ie ziet er wel gaaf uit, zeker met die vertraagde icoontjes ziet het er erg XP achtig uit. Wel jammer dat het VB is.

[thomasfilius]

Grote voordeel van het menu-script van webfx vind ik persoonlijk dat hij over selectboxen kan en je niet hoeft te eikelen als je frames gebruikt.

edit:
op het moment dat ik dit bericht verstuur realiseer ik me dat het helemaal niet meer gaat om wat de topic-starter vroeg. echter vind ik het wel een interessante topic.

p.s. gordijnstok hoe zit dat met die iconset?

[ Voor 45% gewijzigd door thomasfilius op 23-05-2003 23:05 ]

[drm]

Gordijnstok:
http://www.stedy.com/

Ik vind het bij dergelijke dingen toch wel erg teleurstellend dat ik in Mozilla (waar ik normaal gesproken mee browse) gewoon helemaal niets te zien krijg. Dan kan je nog zulke mooie dingen kunnen bouwen maar het is gewoon een trap in het gezicht van degenen die hard bezig zijn standaarden te ontwikkelen Gewoon poep aan hebben dus. Jammer ...
[/offtopic]

edit:

Over het uitwisselen van iconsets en dergelijke:
Doe dat liever via de mail. Ik heb liever niet dat het hier uitdraait op een "wie heeft dat ikoontje nog voor mij"-topic

[ Voor 20% gewijzigd door drm op 23-05-2003 23:08 ]

[Verwijderd]

Verwijderd schreef op 23 mei 2003 @ 19:13:
[...]


Vooral de tree werkt.. *kuch* slecht. Browser die freezed, meerdere focusses, als je cut & paste zelf maakt, dan worden parent en childs geselecteerd, reloads selecteren parents, en als je daarna childs selecteerd ook meerdere selecties, timeouts niet geregeld voor node settings, etc. een ramp.

Ik heb net de nieuwste versie (1.17) ervan geprobeerd.... erg leuk dingetje en niet van die rare bugs die jij hier opnoemt.... totdat ik er achterkwam dat de tree niet al te groot mag worden... krijg nu allemaal meldingen van de browser dat er een script in de pagina de hele pc vertraagd met de vraag ik ik wil stoppen met het script...... Doe ik dit niet blijft de melding constant komen....

Dit is het geval in Mozilla en in IE....

erg jammer....

Edit:

Ik bleek het bij het verkeerde eind te hebben en alles werkt perfect Ik ben weer helemaal vrolijk

[ Voor 16% gewijzigd door Verwijderd op 24-05-2003 01:29 ]

[Verwijderd]

Verwijderd schreef op 23 May 2003 @ 23:10:
Ik bleek het bij het verkeerde eind te hebben en alles werkt perfect Ik ben weer helemaal vrolijk

Nee hoor, het is onmogelijk dat de tree goed werkt Hij is namelijk kandidaat voor deze bug:

http://support.microsoft....aspx?scid=kb;en-us;269802

En dit gebeurt dus altijd, ook onder Mozilla, Opera etc. gewoon omdat deze bug is gerelateerd aan wininet.dll. Deze bug zit er al sinds de eerste IE versies in.

Verder probeer bijvoorbeeld maar eens snel een reload() te doen op een node, en vervolgens een childNode focus() te geven, en je krijgt 2x focus. Doe maar eens een remove() op alle nodes en bij de laatste childNode crashed de tree. Zelfde geld voor een reload op de root, ook crash. etc.

Ik moet er wel bijzeggen, dat de beschikbaarheid van dhtml treeviews erg slecht is. Ze zijn op 1 hand te tellen, zeker als je on demand loading wilt gebruiken (pas childnodes inladen als je een node uitklapt).

[ Voor 12% gewijzigd door Verwijderd op 24-05-2003 13:40 ]

[hobbit_be]

ik vind het allemaal dapper hier op met (D)HTML iets te maken dat overal werkt. Zit nu al 5 jaar te werken met Inet maar aan dat 'spul' kom ik niet aan (behalve CSS , eerste versie) en een simpele rollover. Vind het allemaal veel te slecht geimplementeerd (ik kies geen 'kant' hier, het is aan de maker om te zien dat iets overal werkt of niet). Zal blij zijn dat er ooit een logisch standaard (Flash MX, maar dan snel? )komt voor UI design op het web. DHTML is en blijft imho 'evil' (for now).

[Dennis]

Zeg Gordijn, dit topic gaat ondertussen helemaal over jouw CMS, maarre... is dat ding van jou ook multi-browser ?

[swampy]

Nozzman schreef op 19 May 2003 @ 23:03:
Bij "wat is gebruiksvriendelijk" moet je je goed inleven in degene die het systeem gaat gebruiken. En die hebben vaak kaas gegeten van alles waar meer dan 1 klik voor nodig is. Je zal ze dus door het proces moeten loodsen en het gebruik zo laagdrempelig en Nijntje mogelijk moeten houden. Ons systeem gaat bijvoorbeeld nog teveel uit van kennis-aanname. Voorbeeld: een klant moet voor een navigatieitem een volgnummer opgeven, om de volgorde te bepalen. No way dat ze dat snappen.

Zo'n windows achtige interface is prima. Herkenbaar en dus gebruiksvriendelijk. De uitdaging is om visuele elementen zo in te zetten dat een gebruiker intuitief aan de slag kan met zijn CMS. En daar slaat men de plank nogal eens mis.

Leuk trouwens om voorbeelden te zien: meer!

Waarom niet inderdaad een nijntje als helper inbouwen, dan weet je zeker dat de grootse n00b ermee kan werken!

[drm]

hobbit_be:
ik vind het allemaal dapper hier op met (D)HTML iets te maken dat overal werkt. Zit nu al 5 jaar te werken met Inet maar aan dat 'spul' kom ik niet aan (behalve CSS , eerste versie) en een simpele rollover. Vind het allemaal veel te slecht geimplementeerd (ik kies geen 'kant' hier, het is aan de maker om te zien dat iets overal werkt of niet). Zal blij zijn dat er ooit een logisch standaard (Flash MX, maar dan snel? )komt voor UI design op het web. DHTML is en blijft imho 'evil' (for now).

Een logische standaard voor het gebruik van dHTML (dhtml opzich is eigenlijk een buzzword, heeft niets met standaarden te maken) is het Document Object Model (DOM), wat langzamerhand toch heel prima ondersteunt wordt door browsers (IE, Mozilla, Opera). Ik kan me voorstellen dat je 2 jaar terug gedesillusioneerd raakte van het gezeur, maar langzamerhand wordt het toch steeds eenvoudiger om interfaces op standaarden te baseren. Ik denk dus dat je langzamerhand wel kunt zeggen dat dHTML dmv DOM en i.c.m. CSS (level 2 is toch echt wel leuk ) echt wel volwassen aan het worden is. Zeker als je de lijn doortrekt naar XML/xslt wordt het interessant, omdat het DOM ook daarop van toepassing is.

[Verwijderd]

ddc schreef op 24 mei 2003 @ 14:13:
Zeg Gordijn, dit topic gaat ondertussen helemaal over jouw CMS, maarre... is dat ding van jou ook multi-browser ?

Nee, het is ontwikkeld specifiek voor Msie vanaf 5.0. Mac zal zowiezo niet gaan omdat hier geen XML Support voor is.

Tevens zijn de webfx menu's die ik heb gebruikt puur ontwikkeld voor Msie. Ik ga op een later tijdstip als ik teveel tijd over heb, en de huidige basis heb verbeterd en geoptimaliseerd wel kijken naar crossbrowser support en er eigen snippets inhangen, maar vooralsnog is de animo naar andere ondersteuning dan Msie extreem laag, danwel niet nihil.

[Verwijderd]

drm schreef op 24 May 2003 @ 14:31:
[...]
Een logische standaard voor het gebruik van dHTML (dhtml opzich is eigenlijk een buzzword, heeft niets met standaarden te maken) is het Document Object Model (DOM), wat langzamerhand toch heel prima ondersteunt wordt door browsers (IE, Mozilla, Opera). Ik kan me voorstellen dat je 2 jaar terug gedesillusioneerd raakte van het gezeur, maar langzamerhand wordt het toch steeds eenvoudiger om interfaces op standaarden te baseren. Ik denk dus dat je langzamerhand wel kunt zeggen dat dHTML dmv DOM en i.c.m. CSS (level 2 is toch echt wel leuk ) echt wel volwassen aan het worden is. Zeker als je de lijn doortrekt naar XML/xslt wordt het interessant, omdat het DOM ook daarop van toepassing is.

Wat je hierboven aanstipt is zeker een goed punt, maar wat ik hier wel wil bij vermelden, is dat de meeste developers niets willen weten van hetzelf schrijven van Javascripts, en waarschijnlijk nog niet eens een blik hebben geworpen op de CSS 2 specs.

Dan kun je met alle toffe goodies die je tot je beschikbaarheid wel iets in elkaar stampen, maar mensen om dit te onderhouden naast de maker zelf zijn heel slecht te vinden of aan te sporen.

Ik heb het zelf meegemaakt dat je op je dit soort zaken op je CV vermeld, maar dat het allemaal maar als onbelangrijk wordt gezien. Onder de trand van "dat geloof ik allemaal wel". Het wordt allemaal op een grote kluit gegooid onder het mom van "is allemaal html en dat is basic, iedereen kan dat".

En vooral een baas die vroeger Delphi heeft gedaan, die verwacht dan dat grids, treeviews, dockbars, contextmenu's etc allemaal wel gewoon te slepen zijn vanuit een box met controls

[ Voor 18% gewijzigd door Verwijderd op 24-05-2003 14:43 ]

[hobbit_be]

drm schreef op 24 mei 2003 @ 14:31:
[...]
Ik kan me voorstellen dat je 2 jaar terug gedesillusioneerd raakte van het gezeur, maar langzamerhand wordt het toch steeds eenvoudiger om interfaces op standaarden te baseren. Ik denk dus dat je langzamerhand wel kunt zeggen Zeker als je de lijn doortrekt naar XML/xslt wordt het interessant, omdat het DOM ook daarop van toepassing is.

Langzamerhand ja, maar nu nog niet - of waarom krijg je niets dan 'bug' reports als je iets anders dan tables gebruikt - nee DHTML is er echt nog niet. Qua angst van javascript gebruik: helemaal niet, ben programmeur zie het liefst allemaal 'code' wise building.

XML+XSLT-> ?HTML. Wat er nou zo speciaal is aan die combinatie heeft imho geen bal met DHTML te maken (of doel je dat het dan eenvoudiger word om per browser (versie) een andere Stylesheet te maken?. Ik ben net mijn site aan het XML+XSLT-en, (allemaal cached serverside, want client side XSLT gaat ook nog een tijdje duren) maar dat is puur practisch (ie Data != UI).

Overigens ben ik net XLST van O Reilly aan het lezen en daar staat ook steeds in dat XSLT niet CSS overbodig maakt - maar ik zie zelfs niet in wat de twee in efite met elkaar te maken hebben??? XSLT is gewoon een XML transformerke (best lekker hoor) maar wat heeft dat met de juiste opbouw en CSS te maken?.

Buzzwords idd .

ps: mijn xml+xslt is gewoon pure HTML 1.0. Ziet er bijna overal hetzelfde uit ( ). dus nogmaals mijn appreciatie voor mensen die er zoveel tijd in steken. Met flash doe ik in 10 minutes hetzelfde en werkt overal (ideaal voor 'tree-views' and such things).

[djluc]

XML+XSLT-> ?HTML. Wat er nou zo speciaal is aan die combinatie heeft imho geen bal met DHTML te maken (of doel je dat het dan eenvoudiger word om per browser (versie) een andere Stylesheet te maken?. Ik ben net mijn site aan het XML+XSLT-en, (allemaal cached serverside, want client side XSLT gaat ook nog een tijdje duren) maar dat is puur practisch (ie Data != UI).

IE6 kan dat toch wel aan? Voor sommige CMS projecten, bijvoorbeeld over een intranet is het dus wel te gebruiken?

Overigens ben ik net XLST van O Reilly aan het lezen en daar staat ook steeds in dat XSLT niet CSS overbodig maakt - maar ik zie zelfs niet in wat de twee in efite met elkaar te maken hebben??? XSLT is gewoon een XML transformerke (best lekker hoor) maar wat heeft dat met de juiste opbouw en CSS te maken?.

Niet veel, behalve natuurlijk dat je in je XSL bestand aangeeft welke CSS stylesheet je wilt gebruiken en waarvoor.

Met flash doe ik in 10 minutes hetzelfde en werkt overal (ideaal voor 'tree-views' and such things).

Ik ben nu toch aan het kijken naar een tree gebaseerd op XML, die heb ik nu een kant-en-klare gevonden. De implemementatie daarvan is heel erg eenvoudig omdat je alleen het XML bestand maar uit de database hoeft te halen. Het enige prob wat ik nu nog heb is het doorsturen van wijzigingen in de tree (je kunt o.a. objecten in de tree verslepen!) naar de database. Daarvoor ga ik nu de javascript functies die dit verslepen regelen nog even aanpassen zodat ze in een hiddenframe de juiste wijzigingen naar de database sturen.

[drm]

hobbit_be:
Langzamerhand ja, maar nu nog niet - of waarom krijg je niets dan 'bug' reports als je iets anders dan tables gebruikt

Hier blijkt wel uit dat je je nog niet echt verdiept hebt in de kracht van CSS2

- nee DHTML is er echt nog niet. Qua angst van javascript gebruik: helemaal niet, ben programmeur zie het liefst allemaal 'code' wise building.

gelukkig, want zonder javascript lever je vaak een hoop snelheid in

XML+XSLT-> ?HTML. Wat er nou zo speciaal is aan die combinatie heeft imho geen bal met DHTML te maken (of doel je dat het dan eenvoudiger word om per browser (versie) een andere Stylesheet te maken?.

Ik bedoel maar aan te geven dat als je je systeem op standaarden wilt baseren dat het je steeds makkelijker gemaakt wordt, zeker als je met DOM aan de slag gaat. De noemer HTML dreigt dan namelijk te vervallen, bijvoorbeeld door xhtml te genereren (is tenslotte niet veel meer dan een subset van XML), en je dus eigenlijk de kunsten van het "dHTML kennen" kunt laten voor wat het is omdat je met standaarden (XML en DOM) werkt om clientside transformaties uit te voeren -> clientside dynamiek -> snelheid en gebruikersvriendelijkheid.

Ik ben net mijn site aan het XML+XSLT-en, (allemaal cached serverside, want client side XSLT gaat ook nog een tijdje duren) maar dat is puur practisch (ie Data != UI).

Same here. Maar dat is precies mijn punt: daar moeten we naar toe. Feitelijk zou je CMS gewoon een XML boom moeten genereren die je vervolgens kunt presenteren door middel van XSL(T) -> xhtml. Bij de client beschik je dan dus ook over een XML boom (x(ht)ml) die je dmv. DOM kunt aanspreken en daarmee dynamische (clientside) toestanden kunt bouwen.

Overigens ben ik net XLST van O Reilly aan het lezen en daar staat ook steeds in dat XSLT niet CSS overbodig maakt - maar ik zie zelfs niet in wat de twee in efite met elkaar te maken hebben??? XSLT is gewoon een XML transformerke (best lekker hoor) maar wat heeft dat met de juiste opbouw en CSS te maken?.

CSS (vooral 2) werkt feitelijk ook op basis van een boomstructuur die je in XML en DOM terugvindt. Dat is een kracht van CSS die nog weinig toegepast wordt maar wel degelijk goed en functioneel toe te passen is. Denk aan het contextueel selecteren van nodes:

Cascading Stylesheet:

div.nav a {
   /* een A node die in een DIV node met class 'nav' voorkomt */
}

Ik heb bijvoorbeeld ook wel eens een discussie gehad met Cheatah over de vraag waarom het selecten van nodes in CSS niet door middel van XPath gedaan wordt.

Maar XSLT maakt CSS absoluut niet overbodig. De scheiding zit hem volgens mij in het probleem dat in een xml-document wat door de browser begrijpbaar moet zijn nog steeds gebruik wordt gemaakt van elementen die een speciale betekenis hebben. Je merkt in de xhtml 2.0 specificatie dat daar al steeds meer vanaf gestapt wordt. XSLT is in die zin feitelijk meer het plak-middel tussen nieuwe en oude standaarden dan CSS.
Als voorbeeld kun je voor de grap eens in Mozilla het volgende doen:
neem een html document

HTML:

<html>
   <head>
      <link rel="stylesheet" type="text/css" href="./css.css" />
   </head>
   <body>
      <myElement>myContent</myElement>
   </body>
</html>

en

Cascading Stylesheet:

myElement {
   font-size:20px;
   display:block;
   color:#f00;
}

Wat het eigenlijk al aangeeft: HTML als standaard wordt op den duur overbodig gemaakt en daarmee misschien wel XSLT als plakmiddel tussen XML (een stijl-onafhankelijke documentstructuur) en HTML (en stijl-afhankelijke documentstructuur). Waar ik overigens niet mee wil zeggen dat ik denk dat XSLT zijn functie helemaal gaat verliezen, maar wel als XSL (stylesheet) voor XML. Het zou eigenlijk enkel voor transformatie-doeleinden gebruikt moeten worden, ergo een manier om van het ene doctype naar het andere te transformeren.

Buzzwords idd .

Ik bedoel maar aan te geven dat door die ontwikkeling in standaarden de verschillende technieken steeds dichter bij elkaar komen te liggen: xml, xslt, dom, css en last but not least dus het gebruik van JS om je DOM-tree te benaderen en te manipulen (wat dus dhtml genoemd wordt).

ps: mijn xml+xslt is gewoon pure HTML 1.0. Ziet er bijna overal hetzelfde uit ( ). dus nogmaals mijn appreciatie voor mensen die er zoveel tijd in steken. Met flash doe ik in 10 minutes hetzelfde en werkt overal (ideaal voor 'tree-views' and such things).

En dat vind ik dus zonde Net als Gordijnstok eigenlijk ook al zegt:

Gordijnstok:
Wat je hierboven aanstipt is zeker een goed punt, maar wat ik hier wel wil bij vermelden, is dat de meeste developers niets willen weten van hetzelf schrijven van Javascripts, en waarschijnlijk nog niet eens een blik hebben geworpen op de CSS 2 specs.

Als iedereen zou blijven bij de oudere standaarden en uit zou wijken naar Flash krijgen de genoemde technieken nooit de draagkracht om ook standaarden te worden en zullen standaarden voor die nieuwe technieken altijd achter blijven, hence => de nieuwere (betere) technieken worden voor niets bedacht.

Wanneer je de (nieuwe) standaarden terzijde laat liggen als webdeveloper krijgen ze nooit de kans echt iets te worden. Als je dan zegt dat de nieuwe technieken niets zijn omdat ze niet werken/niet geimplementeerd worden ben je dus bezig een kip-ei probleem te vormen wat er volgens mij niet hoeft te zijn.

Het feit dat jij niet de moeite hebt genomen om CSS2 te verkennen geeft al aan dat je eigenlijk gewoon bevooroordeeld bent met "Het zal toch wel niet werken" o.i.d. Toegegeven: het werkt (in IE) nog niet helemaal zoals het hoort, maar als je daar niet mee aan de slag gaat, waarom zouden we dan uberhaupt met nieuwe dingen aan de slag gaan?

imho is dat de essentie van de explosieve ontwikkeling in alles wat met techniek te maken heeft: de nieuwe ideeen moeten gebruikt worden om ze volwassen te laten worden en op den duur overbodig omdat er weer nieuwe (betere) ideeen zijn gekomen. Anders hadden we nu nog steeds in een hutje op de hei zonder stroom gezeten (bij wijze van spreken). Potje Monopolie? Nee dus, je gaat UT of Warcraft of wat dan ook doen...

HTML 1 is dus van den gekke en ik hoop van harte dat je dat begrijpt HTML is momenteel nog een noodzakelijk kwaad omdat de uitrangering van HTML uitblijft doordat het nog te veel gebruikt wordt.
_{Als voetnoot daarbij vraag ik me af wanneer de DTD's nou eens echt draagkracht krijgen. Dat is feitelijk hetzelfde verhaal}

[djluc]

Wat het eigenlijk al aangeeft: HTML als standaard wordt op den duur overbodig gemaakt en daarmee misschien wel XSLT als plakmiddel tussen XML (een stijl-onafhankelijke documentstructuur) en HTML (en stijl-afhankelijke documentstructuur). Waar ik overigens niet mee wil zeggen dat ik denk dat XSLT zijn functie helemaal gaat verliezen, maar wel als XSL (stylesheet) voor XML. Het zou eigenlijk enkel voor transformatie-doeleinden gebruikt moeten worden, ergo een manier om van het ene doctype naar het andere te transformeren.

In welk opzicht zie jij dat dan precies. Zo gebruik ik een Filemaker database die vanzelf XML kan uitspugen. Ik denk dat ik dan heel handig gebruik kan maken door gewoon een XSL bestandje te gebruiken als stylesheet?

[Verwijderd]

Voor mijn tree gebruik ik overigens xml -> xsl

Ik zou met alle liefde alles richting CSS2 duwen, maar dan ga ik mezelf teveel werk op de schouders halen.

xsl template

code:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" language="JavaScript">
<cfoutput>
<xsl:template match="tree">
  <xsl:apply-templates select="entity"/>
</xsl:template>

<xsl:template match="entity">
  <div 
    treeItem="true"
    onclick="window.event.cancelBubble = true;clickOnEntity(this);return false;" 
    ondblclick="window.event.cancelBubble = true;dblClickOnEntity(this);return false;" 
    onselectstart="return false" 
    ondragstart="return false">
  <xsl:attribute name="image"><xsl:value-of select="image"/></xsl:attribute>
  <xsl:attribute name="imageOpen"><xsl:value-of select="imageOpen"/></xsl:attribute>
  <xsl:attribute name="open">false</xsl:attribute>
  <xsl:attribute name="id">f<xsl:value-of select="@id"/></xsl:attribute>
  <xsl:attribute name="open">false</xsl:attribute>
  <xsl:attribute name="oncontextmenu">window.event.cancelBubble = true;loadContextMenu('<xsl:value-of select="onContextMenu"/>', this);return false;</xsl:attribute>
  <xsl:attribute name="xmlSrc"><xsl:value-of select="@xmlSrc"/></xsl:attribute>
  <xsl:if test="instanceId">
    <xsl:attribute name="instanceId"><xsl:value-of select="instanceId"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="parentId">
      <xsl:attribute name="parentId"><xsl:value-of select="parentId"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="objectType">
      <xsl:attribute name="objectType"><xsl:value-of select="objectType"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="positionNumber">
      <xsl:attribute name="positionNumber"><xsl:value-of select="positionNumber"/></xsl:attribute>
  </xsl:if>  
  <xsl:if test="objectName">
      <xsl:attribute name="objectName"><xsl:value-of select="objectName"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="instanceStatus">
      <xsl:attribute name="instanceStatus"><xsl:value-of select="instanceStatus"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="startDateTime">
      <xsl:attribute name="startDateTime"><xsl:value-of select="startDateTime"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="endDateTime">
      <xsl:attribute name="endDateTime"><xsl:value-of select="endDateTime"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="description">
      <xsl:attribute name="description"><xsl:value-of select="description"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="isLastVersionPublished">
      <xsl:attribute name="isLastVersionPublished"><xsl:value-of select="isLastVersionPublished"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="lastVersion">
      <xsl:attribute name="lastVersion"><xsl:value-of select="lastVersion"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="currentVersion">
      <xsl:attribute name="currentVersion"><xsl:value-of select="currentVersion"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="lastVersionId">
      <xsl:attribute name="lastVersionId"><xsl:value-of select="lastVersionId"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="usesVersioning">
      <xsl:attribute name="usesVersioning"><xsl:value-of select="usesVersioning"/></xsl:attribute>
  </xsl:if>
  <xsl:if test="isPageObject">
      <xsl:attribute name="isPageObject"><xsl:value-of select="isPageObject"/></xsl:attribute>
  </xsl:if>  
  <xsl:attribute name="STYLE">
    background-repeat: repeat-y;
  <xsl:if expr="depth(this) > 2">
    display: none;
    <xsl:choose>
      <xsl:when expr="this.parentNode.parentNode.parentNode.parentNode.nextSibling != null">
        background-image: url(#Request.Application.RootUrl#includes/tree/gfx/I.gif);
      </xsl:when>
      <xsl:otherwise>
        <xsl:if expr="this.parentNode.parentNode.nextSibling != null">
          background-image: url(#Request.Application.RootUrl#includes/tree/gfx/I.gif);
        </xsl:if>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:if>
    padding-left: 20px;
    cursor: hand;
  </xsl:attribute>
    <table border="0" cellspacing="0" cellpadding="0" style="border-top:1px solid white" <!---onmouseout="this.style.borderTop='1px dotted white';" onmouseover="this.style.borderTop='1px dotted navy';"--->>
      <tr>
        <td valign="middle" nowrap="nowrap"><img border="0" id="plusImage" align="absMiddle" hspace="0" vspace="0">
          <xsl:choose>
              <xsl:when test="@xmlSrc">
                <xsl:choose>
                    <xsl:when expr="this.nextSibling != null">
                        <xsl:attribute name="src">#Request.Application.RootUrl#includes/tree/gfx/TPlus.gif</xsl:attribute>
                    </xsl:when>
                    <xsl:otherwise>
                        <xsl:attribute name="src">#Request.Application.RootUrl#includes/tree/gfx/LPlus.gif</xsl:attribute>
                    </xsl:otherwise>
                </xsl:choose>
              </xsl:when>
              <xsl:otherwise>
                <xsl:choose>
                    <xsl:when expr="this.nextSibling != null">
                        <xsl:attribute name="src">#Request.Application.RootUrl#includes/tree/gfx/T.gif</xsl:attribute>
                    </xsl:when>
                    <xsl:otherwise>
                        <xsl:attribute name="src">#Request.Application.RootUrl#includes/tree/gfx/L.gif</xsl:attribute>
                    </xsl:otherwise>
                </xsl:choose>
              </xsl:otherwise>
          </xsl:choose>
          </img><img border="0" id="image" vspace="0" hspace="0" align="absMiddle">
            <xsl:attribute name="SRC">
              <xsl:value-of select="image"/>
            </xsl:attribute>
          </img>
          <xsl:if test="instanceStatus">
            <img border="0">
            <xsl:choose>
                <xsl:when match=".[isLastVersionPublished=0 &amp;&amp; instanceStatus=2 &amp;&amp; usesVersioning=1]">
                    <xsl:attribute name="src">#Request.Application.RootUrl#admin/gfx/iman_subnav_orange_btn.gif</xsl:attribute>
                </xsl:when>
                <xsl:when match=".[instanceStatus=3]">
                    <xsl:attribute name="src">#Request.Application.RootUrl#admin/gfx/iman_subnav_purple_btn.gif</xsl:attribute>
                </xsl:when>
                <xsl:when match=".[instanceStatus=2]">
                    <xsl:attribute name="src">#Request.Application.RootUrl#admin/gfx/iman_subnav_green_btn.gif</xsl:attribute>
                </xsl:when>
                <xsl:otherwise>
                    <xsl:attribute name="src">#Request.Application.RootUrl#admin/gfx/iman_subnav_red_btn.gif</xsl:attribute>
                </xsl:otherwise>
            </xsl:choose>
            </img>
         </xsl:if>
        </td>
        <td valign="middle" nowrap="nowrap">
        <a class="treeitem" id="anchor">
        <xsl:attribute name="href">
            <xsl:choose>
                <xsl:when test="href">
                    <xsl:value-of select="href" />
                </xsl:when>
                <xsl:otherwise>
                    javascript:void(0)
                </xsl:otherwise>
            </xsl:choose>
        </xsl:attribute>
        <xsl:if test="isLocked">
        <xsl:choose>
            <xsl:when match=".[isLocked=1]">
                <xsl:attribute name="STYLE">
                margin-left: 7px;
                font-family: Verdana;
                font-size: 11px;
                color: gray;
                </xsl:attribute>            
            </xsl:when>
            <xsl:otherwise>
                <xsl:attribute name="STYLE">
                 margin-left: 7px;
                 font-family: Verdana;
                 font-size: 11px;
                </xsl:attribute>
            </xsl:otherwise>
        </xsl:choose>
         </xsl:if>
        <xsl:value-of select="description"/></a>
        </td>
      </tr>
    </table>
    <xsl:if test="@xmlSrc">
        <div style="display: none;padding-left: 20px;cursor:hand;">Items worden ingeladen...</div> 
    </xsl:if>
  </div>
</xsl:template>

</xsl:stylesheet>
</cfoutput>
<cfsetting showdebugoutput="No">

[ Voor 24% gewijzigd door Verwijderd op 24-05-2003 16:54 ]

[hobbit_be]

drm schreef op 24 May 2003 @ 16:08:
Hier blijkt wel uit dat je je nog niet echt verdiept hebt in de kracht van CSS2

toch wel, maar wat heb je aan kracht als het in bepaalde environments meer tijd kost dan wat ook. Hieruit blijkt dat in mijn projecten het gewoon moet werken en dat is altijd Lowest Common ... (Porsche vs Polo )

gelukkig, want zonder javascript lever je vaak een hoop snelheid in

Tja maar dat wil niet zeggenb dat ik dat ga gebruiken voor DOM stoten (nou echt 'programming' dan) : ik krijg de pest van 'script' errors. Voor de rest allemaal netjes met een request string. Again: omdat dit overal werkt, no redundancy etc etc...

Ik bedoel maar aan te geven dat als je je systeem op standaarden wilt baseren dat het je steeds makkelijker gemaakt wordt, zeker als je met DOM aan de slag gaat.

als je hiermee doelt op XPath/XSLT dan idd, maar toch alleen maar server-side. en dan maakt het imho ook niet echt uit.

Same here. Maar dat is precies mijn punt: daar moeten we naar toe. Feitelijk zou je CMS gewoon een XML boom moeten genereren die je vervolgens kunt presenteren door middel van XSL(T) -> xhtml. Bij de client beschik je dan dus ook over een XML boom (x(ht)ml) die je dmv. DOM kunt aanspreken en daarmee dynamische (clientside) toestanden kunt bouwen.

Waarom is XML zo heilig? persoonlijk vind het ik het nog erug gelimiteerd (ie 'Rect' data, non-hierarchical info). Gebruik het gewoon waarvoor het goed is, voor ander dingen zijn er beter oplossingen. (of ben jij ook zo een die in XML wil proggen? )

Als de 'DOM' van het (x)html documents op iedereens PC werkt en consistent is is dat idd leuk, maar dan komt DOM2 en ben je weer van af. Ik gebruik dus alleen tech die af is. Heeft me al erg veel tijd bespaart. Overigens alleen voor prof toestanden he .

Ik heb bijvoorbeeld ook wel eens een discussie gehad met Cheatah over de vraag waarom het selecten van nodes in CSS niet door middel van XPath gedaan wordt.

omdat er a) geen ideale solution is b) de mensen van w3c meestal maar aanmodderen en zichzelf heilig hebben verklaard.

HTML als standaard wordt op den duur overbodig gemaakt

dit geloof je zelf toch niet? We zitten met HTML nog heel wat jaren opgescheept totdat MM of M$ een cross platform 'plugin' maakt voor elke browser die 100% overal hetzelfde doet. In feite kan Flash nu al HTML volledig redundant maken mocht men daar een beetje meer nadenken over snelheid. (ie stop een wat ruwere Window Toolkit erin). Of kun je in HTML push/pull/ en zowat alles wat je er maar tegen aan kunt gooien. ? XML blijft nog veel langer (al een geluk) en wordt gewoon de backbone daarvan.

Ik bedoel maar aan te geven dat door die ontwikkeling in standaarden de verschillende technieken steeds dichter bij elkaar komen te liggen: xml, xslt, dom, css en last but not least dus het gebruik van JS om je DOM-tree te benaderen en te manipulen (wat dus dhtml genoemd wordt).

CSS valt wel mooi uit het lijstje, maar ik snap wel wat je bedoelt: Maar tergelijkertijd is het ook weer aan het open breken: XPointer/XLink/XSLT2/XQuery/XUpdate. Voor grote bedrijven van software zijn standaard ook niet echt 'profijtig' hoor...

En dat vind ik dus zonde Net als Gordijnstok eigenlijk ook al zegt:

Je hebt altijd meerdere typische personen he: degene die werken met spul dat werkt maar mischien niet het effecient is, en de andere die wat meer speelt. Een prof zou altijd deel 1 moeten gebruiken. Thuis doe je maar 2 . Maar toch als ik moet developpen thuis met 6 browsers (Netscape 4.0 (yeah), IE 4.0, 5.0, 6.0, Mozilla (like I care , sorry maar die aandeel is nog steeds geeks only ), en Opera) en dan nog effe de Mac afgaan (gaat altijd fout) dan denk ik toch: laat ik echt maar het aller-aller simpelste gebruiken. Dat was 4 jaar terug zo en is het nu nog steeds (Helaas he, )

Als iedereen zou blijven bij de oudere standaarden en uit zou wijken naar Flash krijgen de genoemde technieken nooit de draagkracht om ook standaarden te worden en zullen standaarden voor die nieuwe technieken altijd achter blijven, hence => de nieuwere (betere) technieken worden voor niets bedacht.

Dus jij vind CSS+DHTML wel leuk voor UI design ofzo? Sorry maar dat is absurd: Flash is daar voor gebouwd van de 'ground' up. en doet het zoveel beter dat ik er geen woorden aan vuil ga maken. Flash is ook een standaard net als een ander (je kan gerust een eigen packetje samen stellen). Beter Ouder al die termen doen er niet toe: wat werkt en wat gebruikt word wel. (Small thing called evolutionary process ). Waarom worden de standaarden niet gebruikt: a) te moeilijk om deftig te doen werken b) geen echt voordeel voor companys c) standaarden zijn niet standaard.

Wanneer je de (nieuwe) standaarden terzijde laat liggen als webdeveloper krijgen ze nooit de kans echt iets te worden. Als je dan zegt dat de nieuwe technieken niets zijn omdat ze niet werken/niet geimplementeerd worden ben je dus bezig een kip-ei probleem te vormen wat er volgens mij niet hoeft te zijn.

Nou jij bent idealist dan , ik realist

Het feit dat jij niet de moeite hebt genomen om CSS2 te verkennen geeft al aan dat je eigenlijk gewoon bevooroordeeld bent met "Het zal toch wel niet werken" o.i.d. Toegegeven: het werkt (in IE) nog niet helemaal zoals het hoort, maar als je daar niet mee aan de slag gaat, waarom zouden we dan uberhaupt met nieuwe dingen aan de slag gaan?

op client side ben ik niet echt 'verkennend' nee omdat zoals je zei het nog niet allemaal werkt (ie dus niet goed genoeg) ik doe dus meer op serverside (ie Cocoon/XSP(wel Puur XML geklooi ), Xindice, etc) om zo alsnog projecten aan te bieden met maximale flexibility voor mezelf aan anderen. Server-side is leuk omdat standaarden dan geen bal uitmaken. De meeste profs die ik ken doen net hetzelfde. Voor Intranets zoals iemand aanhaalde is het een different story natuurlijk.

imho is dat de essentie van de explosieve ontwikkeling in alles wat met techniek te maken heeft: de nieuwe ideeen moeten gebruikt worden om ze volwassen te laten worden en op den duur overbodig omdat er weer nieuwe (betere) ideeen zijn gekomen. Anders hadden we nu nog steeds in een hutje op de hei zonder stroom gezeten (bij wijze van spreken). Potje Monopolie? Nee dus, je gaat UT of Warcraft of wat dan ook doen...

Ook weer een tikkeltje naief hoor: nergens zie ik het woord macht en geld in jouw tekst . Technology is niet voor ons te dienen - het is voor een deel van ons te dienen om anderen(niet per se mensen) te onderdrukken. De snelheid van adoptie is hoe effecient dat gebeurt (en dan nog met een heel hoop nuances).

offtopic:
Overigens is mijn computerke te traag om UT of Warcraft te spelen en ook voor de meeste mensen te wereld, dus ik hou het nog of StarCraft . En ja ik zit nog op een TNT2 kaartje.

HTML 1 is dus van den gekke en ik hoop van harte dat je dat begrijpt HTML is momenteel nog een noodzakelijk kwaad omdat de uitrangering van HTML uitblijft doordat het nog te veel gebruikt wordt.

Wat anders zou jij dan gebruiken? .

_{Als voetnoot daarbij vraag ik me af wanneer de DTD's nou eens echt draagkracht krijgen. Dat is feitelijk hetzelfde verhaal}

Wanneer: DTD leesbaar worden (ie NOOIT), ze ook wel degelijk echt alles kunnen validaren (welcome XMLSchema), ze niet in veel gevallen even hinderlijk zijn als handig.

Nou word ik zelf depri van de post Neem het dus niet als persoonlijk commentaar maar als 'statement'

[Verwijderd]

Poe wat een lap tekst, moet gewoon zoeken naar wat ik wil quoten

hobbit_be schreef op 24 May 2003 @ 18:16:
Tja maar dat wil niet zeggenb dat ik dat ga gebruiken voor DOM stoten (nou echt 'programming' dan) : ik krijg de pest van 'script' errors. Voor de rest allemaal netjes met een request string. Again: omdat dit overal werkt, no redundancy etc etc...

Script errors komen niet voort uit fouten in de DOM, maar uit fouten die mensen zelf maken tijdens het programmeren. Tuurlijk zijn er hier en daar nog wel wat bugs, maar niet op een manier dat alles wat je doet direct in een error belandt.

Ik gebruik dus alleen tech die af is. Heeft me al erg veel tijd bespaart. Overigens alleen voor prof toestanden he .

Maar op deze manier ga je nooit iets creeren wat vernieuwend is. Een frisse blik werpt op gebruik van webapplicaties.

Tijd besparen is altijd leuk voor de vloermanager, want die geeft geen moer om hoe verkregen ervaring op een later moment weer gebruikt kan worden. En tuurlijk loop je tegen momenten aan dat je voor zekerheid gaat, maar je moet ook eens durven te proberen. Van fouten leer je, maar van bewezen technieken die je van voor naar achteren kent, leer je niets meer.

Ik zeg nu niet dat je meteen alle goodies in het werk moet gooien, maar gefaseerd experimenteren kan nooit kwaad.

Of kun je in HTML push/pull/ en zowat alles wat je er maar tegen aan kunt gooien. ?

Ja, niet native, maar ik ken genoeg manieren om dit te simuleren. xmlHttp is er onderdeel van.

Je hebt altijd meerdere typische personen he: degene die werken met spul dat werkt maar mischien niet het effecient is, en de andere die wat meer speelt. Een prof zou altijd deel 1 moeten gebruiken.

Nee vind ik niet. Ik gebruik ook heel vaak deel 2. Ik maak wel altijd de afweging of het wel verstandig is of niet, en soms loop je tegen lastige situaties aan dat wat je wilt bereiken toch niet zo haalbaar is.

Ik heb in de tijd dat ik dit werk doe, al regelmatig technieken toegepast die niet mainstream waren, soms zelfs experimenteel en dit heeft gebruikers van de producten en het product zelf gewoon goed gedaan.

Dus jij vind CSS+DHTML wel leuk voor UI design ofzo? Sorry maar dat is absurd: Flash is daar voor gebouwd van de 'ground' up. en doet het zoveel beter dat ik er geen woorden aan vuil ga maken.

Ik ben het hier totaal niet mee eens. Flash is op een hoop punten ontzettend beperkt, oa in connectivity met de rest van de browser. Daarintegen kun je momenteel zowat alles doen met de beschikbare technieken voor browsers.

[crisp]

Ik vind de discussie flash vs javascript eigenlijk wel interessant.

Als je er eens objectief naar gaat kijken, dan moet je tot de conclusie komen dat het eigenlijk geen bal uitmaakt; actionscript is niets anders dan een implementatie van ECMA v3 net als javascript 1.5 (wat de meeste moderne browsers gebruiken).
Clientside javascript heeft koppelingen naar de DOM waar in flash je met actionscript je movies etc kan benaderen en manipuleren (vraag me niet naar de juiste termen, ik werk niet met flash ).
Daaruit zou ik willen concluderen dat javascript ism DOM net zo krachtig is als flash, met als grote voordeel dat je geen plugin nodig hebt.
Aan de andere kant is het plugin model weer in het voordeel van flash; je kan zo simpel ondersteuning binnenhalen in oudere browsers, waar je voor javascript/DOM ondersteuning je hele browser moet upgraden.

Ik heb dus juist weer een zekere afkeer van flash omdat het veelal gebruikt wordt voor reclames die mij het browsen op bepaalde sites beletten. Nu wordt javascript natuurlijk ook gebruikt voor reclame (popups en dergelijke), maar dat vind ik persoonlijk weer net ietsje minder irritant (maar goed, aan het gebruik van een techniek moet je natuurlijk niet de techniek zelf beoordelen. Hoewel het wel de toekomst van de techniek kan gaan bepalen).
Doet dus niets af aan flash verders, maar het argument dat flash beter geschikt zou zijn voor bepaalde zaken dan javascript zou ik zeker niet zo zwart-wit stellen omdat voor beiden aan bepaalde voorwaarden voldaan moet zijn (plugin versus moderne browser). Als aan de laatste voorwaarde voldaan wordt, dan is javascript minstens zo krachtig.

Javascript wordt denk ik vaak een beetje met minachting naar gekeken door developpers die zich 'professioneel webdesigner' plegen te noemen. Misschien juist wel door de angst om meer met javascript te gaan doen dan alleen een veldje valideren of een mouseovertje te doen, terwijl ze dat met actionscript weer wel doen (remember: het is allebei ECMA).

Helaas leven we in een wereld waar gebruikers sneller een plugin downloaden dan hun hele browser upgraden, dus snap ik de voorkeur voor flash. Dat is echter geen argument om te zeggen dat flash 'geschikter is' dan javascript.

[ Voor 7% gewijzigd door crisp op 24-05-2003 19:06 ]

[Bluestorm]

crisp schreef op 24 May 2003 @ 18:59:
Helaas leven we in een wereld waar gebruikers sneller een plugin downloaden dan hun hele browser upgraden, dus snap ik de voorkeur voor flash. Dat is echter geen argument om te zeggen dat flash 'geschikter is' dan javascript.

Aan de andere kant zijn er ook plaatsen waar de gebruiker zelf geen plugin kan installeren... en de browser wel netjes geupdate wordt. Zoals bij bedrijven.

Een groot probleem van javascript ( nou ja... eigenlijk meer het DOM gebeuren, etc) bij meer kritische applicatieonderdelen is dat je moeilijk kunt voorspellen wat je script in allerlei verschillende browsers doet. Het echte probleem is niet eens dat niet alle browsers alles ondersteunen... maar dat er eigenlijk niet echt een makkelijke manier is om uit te vinden of een bepaalde browser kan wat jij wilt. Dat resulteert dan weer in allerlei rare browser detectie scriptjes... Die dan ook na een tijdje niet meer werken omdat browsers en standaarden veranderen.

[Verwijderd]

Mag ik even het ijs breken door een enorm nadeel aan Flash te noemen, namelijk dat het zich als plugin net als een applet bovenop alles wat zich in je browser plaatst. Hierdoor kun je heel weinig meer met layers doen die er over moeten vallen.

[hobbit_be]

Verwijderd schreef op 24 May 2003 @ 18:41:
Poe wat een lap tekst, moet gewoon zoeken naar wat ik wil quoten

idd he - als je aan het typen bent besef je de size niet:)

Maar op deze manier ga je nooit iets creeren wat vernieuwend is. Een frisse blik werpt op gebruik van webapplicaties.

een 'webapplicatie' is een ruim begrip - persoonlijk is het meer wat serverside gebeurt (ie daar staat de 'logic')

Van fouten leer je, maar van bewezen technieken die je van voor naar achteren kent, leer je niets meer.Ik zeg nu niet dat je meteen alle goodies in het werk moet gooien, maar gefaseerd experimenteren kan nooit kwaad.

History is doomed to repeat itself - idd 'gefaseerd' experimenteren is de gulden middenweg, aan de terughoudende kant (maw voorzichtig) zijn valt veeleer in de smaak bij big coorp. Persoonlijk knoei ik ook vaak met alle tech (net als meeste hier) ivm IT. Daaruit leer je dan wat er kan op prof vlak. En mijn persoonlijke ervaring is dat DHTML er nog niet echt is, terwijl Flash wel zover is. (Natuurlijk zijn er altijd wel bepaalde dingen die echt overal werken, zoals hide/view een div ofzo - maar op UI vlak heb ik het meer over positioning enzo)

Ik ben het hier totaal niet mee eens. Flash is op een hoop punten ontzettend beperkt, oa in connectivity met de rest van de browser. Daarintegen kun je momenteel zowat alles doen met de beschikbare technieken voor browsers.

Waarom zou flash nog met de browser moeten communiceren? (alles behalve dan een file upload dat ze er jammerlijk niet hebben ingestoken, maar met reden) Je moet flash niet beschouwen (meer) als de UI 'pretty' thingy - hij kan gewoon beter en sneller met dynamic data overweg. Helaas is de weergave snelheid er nog niet echt (niet dat je daar op een snelle machine iets van merkt). Om maar te zwijgen van reliable user input/client side validation. Graag dus nog een paar van die punten die zo slecht zouden zijn? (Behalve dat het rete duur is )

crisp:

Tja het is nu eenmaal een feit dat het Ecma script in Flash werkt en in een browser misschien wel, misschien niet. Ik zei ook niet over Javascript vs Flash (flash is wel heel wat meer dan een programmeer (slap: script ) taaltje. Het in UNIFORM ie een standaard (open btw - je kunt de SDK gewoon downloaden). Je punt dat sommige mensen geen Plugin kunnen downloaden is idd valid... Net zoals altijd zien of zoiets kan of niet voor je clientele.

edit:

Gordijnstok: waarom zou je flash in een layer steken? Wat ik wil zeggen dat met flash je helemaal GEEN enige ondersteuning nodig hebt van eender welke Browser tech. Gewoon 1 'html' (or zelfs een pure link naar .swf voor de brave souls) met daarin fullsize flash. als je niet te 'flashy' gaat is dit perfect mogelijk op zelfs een trage PC...

edit edit:

Om maar even te zeggen dat ik al 2 jaar in Flash met XML als data source (zelf een XPath engineke geschreven), XML-RPC als message protocol werk, en XML-Sockets werk.

[ Voor 13% gewijzigd door hobbit_be op 24-05-2003 20:03 ]

[oh,when?]

Verwijderd schreef op 24 May 2003 @ 18:41:
Ik ben het hier totaal niet mee eens. Flash is op een hoop punten ontzettend beperkt, oa in connectivity met de rest van de browser. Daarintegen kun je momenteel zowat alles doen met de beschikbare technieken voor browsers.

HO HO HO!!!!!

Want na deze lange discussie zelf op de achtergrond te blijven, moet ik toch ff inspringen. Want nu schiet je kennis van de Flash wereld toch iets te kort. Deze bestaat tegenwoordig uit verschillende onderdelen:

- Macromedia Flash MX ( wat meestal wordt bedoeld met 'Flash', de IDE waarin Flash Applicaties worden gemaakt )
- Macromedia Flash Remoting, communcatielaag tussen Flash op de client en je business logic op de applicatieserver ( zowel Coldfusion, .NET en J2EE )
- Flash Communication Server, server waarmee streaming en rich media in een multi-user omgeving ontwikkeld kunnen worden

Zoals jullie wel weten ben ik zelf ook niet vies van het promoten van standaarden, en heb ikzelf ook intensief ontwikkeld in DHTML, echter wat hobbit_be ook zegt, ben ik ook realistisch. De Flash wereld levert mij nu een mogelijkheid om multi-platform ( dus Windows, Macintosh, Linux EN PDA! ) applicaties te ontwikkelen die zowel de business logic makkelijk kunnen benaderen zonder hiervoor een extra laag te schrijven, als een standard look and feel GUI te ontwikkelen via FUIC of zelfgeschreven interface controls, en in korte tijd ( zelfs via drag-n-drop ) een rich-media multi user omgeving te creeren. En natuurlijk heeft ook de Flash wereld zijn eigenaardigheden en zijn bugs, daar ontkom je niet aan. Echter ik zie de technologieen die je noemt, deze eigenschappen zeker niet omvatten. Noem ff 2 cases:

- hoeverre wordt DHTML ondersteunt op een PDA of Linux, iig de zeer intensieve voorbeelden ( treeview, xmlHttp controls en functionaliteit als rechtsklik? )
- technologieen als HTML + Javascript + CSS + XML/XSLT bieden alleen functionaliteit voor de presentatie, terwijl ik met Flash Remoting gelijk toegang heb tot de business logic die op de server draait. Deze laag zullen jullie toch echt eerst zelf moeten schrijven

En ik wil niet de kant opgaan tussen een Flash vs ( insert any technolgie hier ) alleen op wijzen dat 'Flash' nog steeds iets te snel wordt geassocieerd met de eerder genoemde banners, intro animaties en dat wij als professionele developers met van alles bezig zijn behalve dit....

just my two cents

[Verwijderd]

oh,when? schreef op 24 May 2003 @ 20:16:
Zoals jullie wel weten ben ik zelf ook niet vies van het promoten van standaarden, en heb ikzelf ook intensief ontwikkeld in DHTML, echter wat hobbit_be ook zegt, ben ik ook realistisch. De Flash wereld levert mij nu een mogelijkheid om multi-platform ( dus Windows, Macintosh, Linux EN PDA! ) applicaties te ontwikkelen die zowel de business logic makkelijk kunnen benaderen zonder hiervoor een extra laag te schrijven, als een standard look and feel GUI te ontwikkelen via FUIC of zelfgeschreven interface controls, en in korte tijd ( zelfs via drag-n-drop ) een rich-media multi user omgeving te creeren. En natuurlijk heeft ook de Flash wereld zijn eigenaardigheden en zijn bugs, daar ontkom je niet aan. Echter ik zie de technologieen die je noemt, deze eigenschappen zeker niet omvatten. Noem ff 2 cases:

- hoeverre wordt DHTML ondersteunt op een PDA of Linux, iig de zeer intensieve voorbeelden ( treeview, xmlHttp controls en functionaliteit als rechtsklik? )
- technologieen als HTML + Javascript + CSS + XML/XSLT bieden alleen functionaliteit voor de presentatie, terwijl ik met Flash Remoting gelijk toegang heb tot de business logic die op de server draait. Deze laag zullen jullie toch echt eerst zelf moeten schrijven

Kun jij mij een case geven, waarin je op je PDA het CMS Systeem beheert? Ik ben er iig nog geen tegengekomen. Wat betreft Linux, de mensen die de content werkelijk gaan beheren zijn niet van de systeembeheer afdeling.

De punten die je voor Flash opnoemt, daar heb je helemaal gelijk in, maar dan ga je wel uit van een systeem wat in zijn geheel onder de Flash plugin draait. Wat betreft toegang tot de business logic, ook met Flash MX zul je daar net zoals via html calls moeten maken op de componenten, dus daar zie ik het voordeel niet echt van in. In beiden gevallen zul je zelf nog code moeten schrijven.

[ Voor 3% gewijzigd door Verwijderd op 24-05-2003 20:43 ]

[hobbit_be]

Verwijderd schreef op 24 May 2003 @ 20:42:
[...]
Kun jij mij een case geven, waarin je op je PDA het CMS Systeem beheert?

Ik kan je helaas het adress niet geven (niet echt veilig connectie ), maar mijn makker (ie partner in It world) doet dat enorm vaak (als zijn laptop weer eens battery leeg is) kan ie met zo'n mobieltje en zijn palmpje effe snel de nodig updates leveren waar ie ook zit - dat is dus Business to Business service...

ik ben er iig nog geen tegengekomen. Wat betreft Linux, de mensen die de content werkelijk gaan beheren zijn niet van de systeembeheer afdeling.

Euh heel veel grote bedrijven stappen over naar een Linux als desktop solution dus voor big business zeker letten dat ie Wel werkt op X. (met Mozilla no longer a prob)

html calls moeten maken op de componenten, dus daar zie ik het voordeel niet echt van in. In beiden gevallen zul je zelf nog code moeten schrijven.

html calls? http protocol zul je bedoelen. Ik gebruik persoonlijk gewoon XML-sockets das is gewoon veel sneller dan wat ook (helemaal geen gechat tussen client/server na de eerste talk).Nog een paar verschillen: met flash kan je NU al je content gewoon doorstromen (zelfs streaming als je het kunt ) zonder daar al die overhead van nog maar een een hele HTML pagina door te pompen (alhoewel je vast ook *.js gebruikt) - En niets is zo impressionant als je app terwijl je aan het werken bent effe een addition doet van iemand anders. Dat gaat NIET in html(herrinner jullie nog die 'ad' van Microsoft - dit is dus nu ook echt mogelijk . (en ook nooit) - nu goed dat laatste is wel 'push the limit with flash' maar als je je creatieve energie ergens moet steken waarom niet in die richting. Voorlopig is er nog plaats voor beide en zal ook wel zo blijven.

Persoonlijk vind ik het ook niet leuk om een site die 100% Flash is (te traag op mijn bakkie) maar net een van de site bezocht van een fellow GoTTer en hey presto script error galore met allemaal nuteloos DHTML spul. Alt F4

[alienfruit]

Het gebruik van een PDA voor het beheren van een CMS, lijkt verdomd handig!
Als je op pad bent en je baas wilt dat je de web-site update, hoef je niet te wachten tot je terug bent op het werk om het te beheren.

[Verwijderd]

hobbit_be schreef op 24 May 2003 @ 23:02:
Euh heel veel grote bedrijven stappen over naar een Linux als desktop solution dus voor big business zeker letten dat ie Wel werkt op X. (met Mozilla no longer a prob)

De personen die over het algemeen de content beheren zitten op de marketing afdeling, en ik zie ze nog niet zo snel overstappen op linux, want dan missen ze hun favo Ms Office.

En niets is zo impressionant als je app terwijl je aan het werken bent effe een addition doet van iemand anders. Dat gaat NIET in html

Hier volg ik je even niet, leg dit is uit?

Persoonlijk vind ik het ook niet leuk om een site die 100% Flash is (te traag op mijn bakkie) maar net een van de site bezocht van een fellow GoTTer en hey presto script error galore met allemaal nuteloos DHTML spul. Alt F4

Dus omdat jij een error krijgt op een site met dhtml, wat jij meteen al als nutteloos betiteld, ben jij dus tegen het gebruik van dhtml, of heb ik je standpunt wb dhtml niet goed opgevat?

[ Voor 3% gewijzigd door Verwijderd op 25-05-2003 00:04 ]

[Verwijderd]

alienfruit schreef op 24 May 2003 @ 23:38:
Het gebruik van een PDA voor het beheren van een CMS, lijkt verdomd handig!
Als je op pad bent en je baas wilt dat je de web-site update, hoef je niet te wachten tot je terug bent op het werk om het te beheren.

Tuurlijk lijkt het verdomd handig, maar dat houdt wel in dat er voor de pda kant gewoon templates moeten worden ontwikkeld en dat kost teveel tijd voor een te lage afzetmarkt, iets waar managers graag de term ROI aanhangen. Let wel, ik heb het hier over een generiek product. Bob de bouwer custom solutions zijn wat dat betreft flexibeler.

Het scherm van een PDA is gewoon net te klein om dit soort taken lekker te kunnen uitvoeren (en dan praat ik niet over een 5 lullige invoerveldjes). Als je een artikel wijzigt gaat het nog. Maar ook daar is geen heavy dhtml voor nodig, daar hangt ook geen extreme interface aan.

[ Voor 7% gewijzigd door Verwijderd op 25-05-2003 00:03 ]

[Verwijderd]

Ik ben ook een CMS aan het maken wat als een WYSIWYG moet gaan werken, het werkt met javascript,php, mysql en java en het ziet er zo uit



Ik test het momenteel op de site van de lokale voetbal club. Alle voorpagina stukjes en achterliggende documenten daar zijn nu met deze CMS gemaakt, de voorpagina stukjes gaan via een wizard die je na het doorlopen van de wizard in het WYSIWYG gedeelte brengt, vanafwaar je kan typen.

[ Voor 4% gewijzigd door Verwijderd op 25-05-2003 09:19 ]

[hobbit_be]

Verwijderd schreef op 24 May 2003 @ 23:57:
De personen die over het algemeen de content beheren zitten op de marketing afdeling, en ik zie ze nog niet zo snel overstappen op linux, want dan missen ze hun favo Ms Office.

Nou op de meeste bedrijven waar ik werkte gebeurt de content input op een MAC.

Hier volg ik je even niet, leg dit is uit?

Push tech: ie wat als je met 10 mensen op je content zit te knoeien dan is het in Flash perfect mogelijk om live dus zonder refresh aan te duiden wat editable is of niet. (Ie beperkt het aantal 'merges'). Of gewoon een image library die live aanblijft, chat programmaatje, white board, etc, etc. En het meest impresionante is dat je RDB data kunt pushen zodra deze veranderd (voor vele de holy grail)

Dus omdat jij een error krijgt op een site met dhtml, wat jij meteen al als nutteloos betiteld, ben jij dus tegen het gebruik van dhtml, of heb ik je standpunt wb dhtml niet goed opgevat?

Ik ben erg tegen het overmatig gebruik van client side scripting (of wel ligt het aan mijn browser IE 6.0.2) maar net (ook toevallig) op een grote site en weer niets dan errors (en de typisch fouten dat de DOM nog niet is geladen als ze al met scripting beginnen) dan is het voor mij al genoeg. Gebruik welke tech je maar wil maar zie dat het werkt. (ie over een rollover zul je me niet horen klagen maar toch liefst niet). Ook de hele chunkc code die eraan vast hangt is soms grappig (ie IE4.0 or NS3.0 then else if... en ga zo door). Als je een DHTML Site maakt zet er dan heel duidelijk bij voor welke Browser deze gegarandeert te werken, beter nog detect de browser en redirect. Maar het is net het multiversioning dat zo rot is (ie hail XLST, maar toch allemaal dubbel werk).

Toen IE5.0 uitkwam had ik al direct XML Dataislands gebruikt gemaakt en dat werkte natuurlijk op die versie van IE en nergens anders.

Maar ik poste eigenlijk gewoon om je te feliciteren met je CMS in DHTML. Tis gewoon dat ik dat NOOIT zou doen (nog liever een ActiveX plugin dan . Heads off.

[Verwijderd]

Jongens en meisjes, een beetje meer respect voor elkaars expertise zou niet misstaan. Er hangt hier een nogal vervelende wat de boer niet kent dat vreet ie niet-sfeer. Als je geen ervaring hebt met het succesvol implementeren in een bepaalde techniek, ga er dan ook geen uitspraken over doen. Dan kun je beter je snavel houden en proberen iets op te steken. Er zijn hier hopen profs en expert-amateurs waarvan we allemaal veel zouden kunnen leren als we stoppen met proberen elkaar te overtuigen van ons eigen gelijk.

Zowel Flash als client-side scripting zijn technieken die staan als een huis, mits goed uitgevoerd. Helaas is het gewoon zo dat voor elke goede uitvoering er tien bagger-variaties te vinden zijn. Da's jammer, maar het is niet anders. Probeer niet de techniek op die manier af te schrijven.

hobbit_be schreef op 25 May 2003 @ 14:16:
Push tech: ie wat als je met 10 mensen op je content zit te knoeien dan is het in Flash perfect mogelijk om live dus zonder refresh aan te duiden wat editable is of niet. (Ie beperkt het aantal 'merges'). Of gewoon een image library die live aanblijft, chat programmaatje, white board, etc, etc. En het meest impresionante is dat je RDB data kunt pushen zodra deze veranderd (voor vele de holy grail)

Push is zonder problemen mogelijk in HTML+JS+Flash/Java. Als je content naar je Flash kan pushen kan je het toch ook in je HTML pushen?

Ik ben erg tegen het overmatig gebruik van client side scripting

Ach vergelijk het met drugs, drank en vrouwen: geniet maar (...) met mate
Ik ben erg tegen het overmatig gebruik van wat dan ook. Dat is een van de moeilijkheden van dit vakgebied: je leert zoveel mogelijk techniek om er maar een klein (waardevol) gedeelte van toe te passen in de echte wereld. Ik heb er nog steeds moeite mee om te bepalen waar de toegevoegde waarde van vernieuwende technieken begint en ophoudt.

Heads off.

Ik mag hopen dat je 'hats off' bedoelt

[Verwijderd]

hobbit_be schreef op 25 May 2003 @ 14:16:
Maar ik poste eigenlijk gewoon om je te feliciteren met je CMS in DHTML. Tis gewoon dat ik dat NOOIT zou doen (nog liever een ActiveX plugin dan .

Ik zou zeggen, ga het gewoon eens uitproberen Als je eenmaal een beetje weet wat er kan dan wordt je blij echt waar

[Verwijderd]

De image bug kan opgelost worden kwam ik zojuist achter. De image niet inladen als <img src> maar als <span style="background-image;url('');background-repeat:no repeat;">

[hobbit_be]

Verwijderd schreef op 25 mei 2003 @ 15:13:
[...]
Ik zou zeggen, ga het gewoon eens uitproberen Als je eenmaal een beetje weet wat er kan dan wordt je blij echt waar

nou ben ik volop bezig met zo min mogelijk tech maar met maximaal effect (ie design) m'n site aan het re-maken - als ik in de problemen kom weet ik vast waar te vragen . De RUSH als iets lukt geld niet alleen voor DHTML

[Mithrandir]

Verwijderd schreef op 25 May 2003 @ 16:58:
De image bug kan opgelost worden kwam ik zojuist achter. De image niet inladen als <img src> maar als <span style="background-image;url('');background-repeat:no repeat;">

offtopic:
Als ik zo vrij mag zijn, welke image bug bedoel ej eigenlijk?
Dank je Rickets

Verder wou ik even zeggen dat je CMS er werkelijkwaar uitziet

[ Voor 8% gewijzigd door Mithrandir op 25-05-2003 17:55 ]

[djluc]

Rutger extreme: moet groote, niet grootTe zijn in je CMS?
Tis toch "de grootte van een voorwerp"

[ Voor 27% gewijzigd door djluc op 25-05-2003 17:55 ]

[Verwijderd]

djluc schreef op 25 May 2003 @ 17:50:
Rutger extreme: moet groote, niet grootTe zijn in je CMS?
Tis toch "de grootte van een voorwerp"

is een uhhhh bug...
Het is nog geen final, dus kleine spelfouten mogen nog net

[ Voor 23% gewijzigd door Verwijderd op 25-05-2003 18:03 ]

[djluc]

Haha, lijkt me wel grappig als je straks dus een situatie krijg waarin er allemaal van diezelfde spelfouten, alles gewoon met 1 T in de content zitten

Waar heb je eigenlijk java voor gebruikt? Ik dacht dat je er helemaal DHTML van had gemaakt?

[Verwijderd]

Mithrandir schreef op 25 May 2003 @ 17:33:

Als ik zo vrij mag zijn, welke image bug bedoel ej eigenlijk?

Verder wou ik even zeggen dat je CMS er werkelijkwaar uitziet

Ik bedoel deze bug:
http://support.microsoft....aspx?scid=kb;en-us;269802

en die wordt veroorzaakt door:
http://support.microsoft....aspx?scid=kb;en-us;183110

Ik heb er nog steeds last van, maar ben met de workaround bezig. Als je bijvoorbeeld uit je xml bestand gaat parsen voor je tree, en je de icons wilt tonen, blijft af en toe de browser freezen door dit geintje. Al met al zit je al gauw op 200 icons voor de tree (indent, plus, min, L, T, I etc.) Je zou kunnen zeggen dat het dus te snel is Wat ook vaag is, is dat hij deze requests maakt. Hij hoort het gewoon uit de cache te halen.

Bedankt voor je compliment, maar ik denk dat er nog wel mooiere cms'en te vinden zijn, die helaas niet worden geshowed.

[ Voor 12% gewijzigd door Verwijderd op 25-05-2003 18:30 ]

[flashin]

Dit is er eentje waar ik onlangs aan begonnen ben:


De tree die je nu ziet gaat weg, en het 'content'-gedeelte komt er heel anders uit te zien. Wordt een combo van PHP/MySQL/XML/DHTML en duurt nog wel een tijdje voor ik hem af heb.

Maar eigenlijk heb je nog niet veel aan deze screen .

[Verwijderd]

Ik wil mijne binnenkort wel showen... maar ik moet eerst even de nieuwe layout verder implimenteren... heb er niet zo veel zin in (ben lui vandaag) dus volgende week is het wel keer af ofzow.. maar het is zeer uitgebreid... dat wel

[Verwijderd]

"Netscape Explorer" ?

[djluc]

Flashin: ik vind het eigenlijk wel mooi zo'n lege lay-out. Wat is de basis van je tree, de bron zal ik maar zeggen, XML?

[Verwijderd]

flashin schreef op 25 May 2003 @ 18:46:
duurt nog wel een tijdje voor ik hem af heb.

Dergelijke projecten kosten zowiezo bakken vol met tijd. Je komt zelfs, met een goede planning of uitgebreid FO altijd zaken tegen die je niet had verwacht.

[Verwijderd]

djluc schreef op 25 May 2003 @ 19:34:
Flashin: ik vind het eigenlijk wel mooi zo'n lege lay-out. Wat is de basis van je tree, de bron zal ik maar zeggen, XML?

Ik zie hier vaak een tree structuur voorbij komen zelf heb ik hier een niet al te hoge dunk van en probeer daarom op dit moment de standaard 'open/save windows' van office na te maken. Ben ik de enige die de office style verkiest boven de tree of zijn er nog meer lotgenoten ?

djluc schreef op 25 May 2003 @ 18:17:
Haha, lijkt me wel grappig als je straks dus een situatie krijg waarin er allemaal van diezelfde spelfouten, alles gewoon met 1 T in de content zitten

Waar heb je eigenlijk java voor gebruikt? Ik dacht dat je er helemaal DHTML van had gemaakt?

Bijvoorbeeld voor het kleur kies gedeelte gebruik ik java:



Net zoals voor het upload venster, hierdoor kan ik een upload venster met een progress bar laten zien.

[Verwijderd]

Verwijderd schreef op 25 May 2003 @ 19:17:
"Netscape Explorer" ?

die heeft in zijn register zitten knoeien

[Mithrandir]

Rutger extreme:
Bedoel je zo'n soort van filetree?



Ik vind het niet echt geweldig werken...

[Verwijderd]

Verwijderd schreef op 25 mei 2003 @ 20:00:
[...]

Ik zie hier vaak een tree structuur voorbij komen zelf heb ik hier een niet al te hoge dunk van .

Ik denk dat een tree momenteel de beste oplossing is om een hierarchische structuur aan te tonen. Als je andere opties hebt, hoor ik ze graag.

[Verwijderd]

Verwijderd schreef op 25 May 2003 @ 20:50:
[...]


Ik denk dat een tree momenteel de beste oplossing is om een hierarchische structuur aan te tonen. Als je andere opties hebt, hoor ik ze graag.

"Dat natuurlijk wel ja" maar ik vindt het file browsen in een tree structuur altijd zeer irritant vooral wanneer het veel files zijn in een map, de manier die microsoft doorgaans gebruikt vindt ik in zulke situaties gebruiksvriendelijker.
Misschien is de hierarchische structuur dan niet geheel duidelijk maar als deze boven in het venster in command style wordt weergeven is het meestal duidelijk genoeg:
"f3/wedstrijdverslag/13-03-03.html"

[djluc]

Dat je Java gebruikt voor een upload met status vindt ik wel een mooie techniek omdat dit niet met de standaard tools kan.

Bijvoorbeeld voor het kleur kies gedeelte gebruik ik java:

Waarom gebruik je hier java, er is toch zo'n standaard geval voor in Javascript geloof ik? Of in IE zelf?

Ik vind persoonlijk een tree erg goed werken omdat de mensen die toch al kennen van de windows explorer. Wat natuurlijk nog mooier is, even b.t.w. is de gebruiker gewoon zelf laten kiezen wat ze fijn vinden werken...

[flashin]

Verwijderd schreef op 25 May 2003 @ 20:04:
[...]

die heeft in zijn register zitten knoeien

tja je moet toch wat

@djluc: nog geen idee. Dit is gewoon zo'n standaard ding van web-fx, beetje om te kijken hoe het eruit ziet. Verder niet echt boeiend hoor.

Mijn eigen echte tree moet ik nog helemaal aan beginnen, dus ik kan nog niets laten zien helaas .

@Gordijnstok: ik neem er ook de tijd voor he , maak gewoon eerst de basis waar je alles al wel mee kan, daarna komen de details wel.

@Rutger: hoe precies bodoel je die office style? wil wel is zien Waarom laat je de gebruiker kleuren kiezen? vaak komen er dan de vreemdste combinaties uit op de website zelf , maak gewoon een paar css classes met de kleuren erin die ze kunnen selecteren uit een dropdown

[Verwijderd]

Verwijderd schreef op 25 May 2003 @ 21:01:
[...]

"Dat natuurlijk wel ja" maar ik vindt het file browsen in een tree structuur altijd zeer irritant vooral wanneer het veel files zijn in een map, de manier die microsoft doorgaans gebruikt vindt ik in zulke situaties gebruiksvriendelijker.
Misschien is de hierarchische structuur dan niet geheel duidelijk maar als deze boven in het venster in command style wordt weergeven is het meestal duidelijk genoeg:
"f3/wedstrijdverslag/13-03-03.html"

Ik heb eigenlijk de windows explorer compleet nagebouwd in dhtml. Ik gebruik dus ook de tree alleen om folders te laten zien. Aan de rechterkant krijg je dan de subfolders, en files te zien.

Klik je rechts op een folder, dan wordt de tree recursief mee uitgeklapt. De tree en de rechterkant wordt dus continue gesynchroniseerd.

Het is wel een teringwerk om te bouwen, en oa de controles op cut & copy & paste, maar daar heb ik een smerig trucje voor toegepast.

[Verwijderd]

flashin schreef op 25 May 2003 @ 22:13:
@Gordijnstok: ik neem er ook de tijd voor he , maak gewoon eerst de basis waar je alles al wel mee kan, daarna komen de details wel.

Ik zou voor je basis uitgebreid de tijd nemen. Het is ontzettend frustrerend als je complete code moet omgooien omdat een nieuwe feature niet naar een dergelijk principe werkt.

[Skef]

offtopic:
Gordijnstok, zou je mij ff willen contacten? Kan via mail, msn of icq...

[alienfruit]

Ik ben dit weekend ook bezig geweest, met de beheerfunctie van de cms. Overigens is dit nog alleen de gui, doet verder nog niets. Omdat ik dit momenteel schrijf voor het .NET framework; waarbij ik nog druk ben met het porten van Toolbar 2000 en maken van een vervanger voor TSyntaxMemo.

Ik ben van mening dat je een beheerapplicatie kan aanbieden dat alleen werkt onder Windows; omdat de kans dat de gebruiker met Windows werkt erg groot is. Verder kun je een veel gebruiksvriendelijke interface opbouwen.



Overigens is het maken van .NET Componenten als VCL Component developer, nog best wel vervelend; alles is precies andersom genoemd (i.e: paint is de event; en onpaint-method)

[ Voor 19% gewijzigd door alienfruit op 26-05-2003 17:06 ]

[Mithrandir]

alienfruit schreef op 26 May 2003 @ 16:57:
Ik ben dit weekend ook bezig geweest, met de beheerfunctie van de cms. Overigens is dit nog alleen de gui, doet verder nog niets. Omdat ik dit momenteel schrijf voor het .NET framework; waarbij ik nog druk ben met het porten van Toolbar 2000 en maken van een vervanger voor TSyntaxMemo.

Ik ben van mening dat je een beheerapplicatie kan aanbieden dat alleen werkt onder Windows; omdat de kans dat de gebruiker met Windows werkt erg groot is. Verder kun je een veel gebruiksvriendelijke interface opbouwen.

[afbeelding]

Overigens is het maken van .NET Componenten als VCL Component developer, nog best wel vervelend; alles is precies andersom genoemd (i.e: paint is de event; en onpaint-method)

Je wilt zeggen dat dit puur webbased is?

Voor de 'gemiddelde' website-admin is dit trouwens nog best ingewikkeld, lijkt mij.

[alienfruit]

Mithrandir, neen sorry het zijn nog geen web .NET component (was het maar waar) maar de gewone .NET componenten is al moeilijk genoeg

[CodeIT]

alienfruit schreef op 26 May 2003 @ 18:34:
Mithrandir, neen sorry het zijn nog geen web .NET component (was het maar waar) maar de gewone .NET componenten is al moeilijk genoeg

Het lijkt wel verrekte veel op de interface van Visual studio .NET. Ik vind het voor een CMS wel een heel uitgebreide gui. Ik denk dat je na het maken van het systeem ook nog wel wat tijd kunt uittrekken voor documentatie. |

offtopic:
Hoeveel geheugen en andere resources gebruikt jouw programma, ik was pas ook bezig met het porten van een VB6 applicatie naar .NET (niet met de wizard, want die maakte alles buggy), maar dat ding gebruikt een geheugen waar je niet goed van word.

[alienfruit]

Ja. Je hebt nu ook de view voor de supervisser, via rechten kun je bepalen of wat de gebruiker te zien krijgt.

offtopic; ongeveer 12mb moet alleen nog uitvinden hoe je de GC kunt uitzetten, want dat vind ik maar niks!

[CodeIT]

offtopic; ongeveer 12mb moet alleen nog uitvinden hoe je de GC kunt uitzetten, want dat vind ik maar niks!

Zonder de gc blijft dat geheugen maar oplopen denk ik. Of je moet zelf alles heel snel en goed kunnen destroyen, 12 MB valt trouwens voor een .Net applicatie nog wel mee.

[Verwijderd]

alienfruit schreef op 26 May 2003 @ 16:57:
Ik ben dit weekend ook bezig geweest, met de beheerfunctie van de cms....

Sommige mensen vind het maar saai, maar ik vindt het toch wel erg mooi en rustig een interface in standaard windows kleuren. Ik houd hier wel van, maargoed het is ook een windows programma in dit geval en geen webapplicatie dus dat maakt het wat makkelijker in het gebruik van kleuren.

[Verwijderd]

Hier alvast een kleine blik van mijn cms... dit is alleen de intro pagina waar de gebruiker als eerst komt... heb ff de naam van het bedrijf weg gehaald ...

[ Voor 11% gewijzigd door Verwijderd op 26-05-2003 20:45 ]

[Mithrandir]

Verwijderd schreef op 26 May 2003 @ 20:45:
Hier alvast een kleine blik van mijn cms... dit is alleen de intro pagina waar de gebruiker als eerst komt... heb ff de naam van het bedrijf weg gehaald ...

[afbeelding]

Hmm... Weinig op te zien eerlijk gezegd

[Verwijderd]

Mithrandir schreef op 26 mei 2003 @ 21:00:
[...]


Hmm... Weinig op te zien eerlijk gezegd

jah weet het maar ik heb morgen laatste examen... daarna ga ik verder om de oude layout te veranderen in de nieuwe ... dit had ik alleen nog maar klaar

[Verwijderd]

Waarom begint *iedereen* hier met de layout Je dal, en business logic is het belangrijkste en vanuit daar kun je elke presentatielaag erop stampen die je maar wil.

[Bosmonster]

Verwijderd schreef op 26 mei 2003 @ 21:18:
Waarom begint *iedereen* hier met de layout Je dal, en business logic is het belangrijkste en vanuit daar kun je elke presentatielaag erop stampen die je maar wil.

Omdat je normaal eerst bepaalt wat het voor de gebruiker moet kunnen en vervolgens dat maakt of in ieder geval probeert te maken En dat je er vervolgens een goed datamodel onder hangt mag voor zich spreken. Vaak weet je ook pas precies hoe die logica eruit moet zien als je precies weet wat het systeem moet gaan kunnen.

Of begin jij met ieder project ook altijd met het technisch ontwerp en dan pas het functioneel ontwerp Ok.. een hele grafische lay-out uitwerken is misschien wat te ver, maar het helpt je vaak wel de details van je functioneel ontwerp te ontdekken.

[ Voor 29% gewijzigd door Bosmonster op 24-09-2008 19:50 ]

[Bosmonster]

alienfruit schreef op 26 mei 2003 @ 16:57:
Ik ben dit weekend ook bezig geweest, met de beheerfunctie van de cms. Overigens is dit nog alleen de gui, doet verder nog niets. Omdat ik dit momenteel schrijf voor het .NET framework; waarbij ik nog druk ben met het porten van Toolbar 2000 en maken van een vervanger voor TSyntaxMemo.

Ik ben van mening dat je een beheerapplicatie kan aanbieden dat alleen werkt onder Windows; omdat de kans dat de gebruiker met Windows werkt erg groot is. Verder kun je een veel gebruiksvriendelijke interface opbouwen.

[afbeelding]

Overigens is het maken van .NET Componenten als VCL Component developer, nog best wel vervelend; alles is precies andersom genoemd (i.e: paint is de event; en onpaint-method)

Hehe.. kword wel erg negatief zo... maar als ik dit zie dan zie ik geen CMS, maar een ontwikkeltool Een klant heeft toch helemaal geen kaas gegeten van tags, html, stylesheet checkers en weet ik niet wat