Eh, nee? Font is al jaren verouderd. Er is een kans dat browsers deze tag ooit gaan droppen. Geen idee wanneer, maar het is niet zomaar 'Deprecated'!
ja dat is waar ik ik zal om deze reden het ook heus wel veranderen
dit stukje functie is echter een deel die allen gebruikt wordt in mijn eigen gemaakte inlogpanel
deze inlog panel is niet aanpasbaar door gebruiker, ik bepaal dus de styling hiervan
als inderdaad de gehele font wegvalt dan wordt mijn rode text ineens weer gewoon standaard zwart
wat dus geen ramp is
Ivo P op 20/03/2020 08:43:35
de zinsnede "ff sneller en simpeler" is nu net waar al pagina's lang tegen geageerd wordt: nu inderdaad sneller en simpeler, maar straks zit je met 3 verschillende formateer-bedrag functies, net als je 100-en variabelen met zinnen als naam gebruikt, omdat je even verdiepen in gebruik van functies en of classes net een uurtje meer werk was
net als ik gezegd heb tegen Ariën
de styling bepaal ik zelf
die font staat in een funcie die speciaal bedoeld is om alleen die delen rood te maken
als dit wegvalt wordt dit dus gewoon weer zwart
ik heb me heel lang proberen te verdiepen in classes en functies en hetgeen dat ik zoek kan ik daar niet in vinden tenminste in veel gevallen niet, mensen kunnen mij ook niet gelijk doorsturen naar waar ik het deel datik moet heb zou kunen leren
want als ik mijn hele code laat zien dan schrikken ze zich rot van alle berekeningen en zeggen vaak dat functies het wel nieuwer maakt kwa verouderde code maar niet altijd beter
ik gebruik namen omdat ik inderdaad 100-en variabelen heb
omdat dit de beste in meest overzichtelijke manier was
ja ik kan dit ook nog bv in een array zetten
code word dan nieuwer
code wordt iets langer, maar omdat ik alle $ niet meer nodig zou hebben komt dit ongeveer gelijk
voordeel?
ik zou nu het geheel in 1 keer ergens kunnen pakken
is dit beter Ja
heb ik dit nodig nee,
kost mij dit extra onnodig werk op dit moment ja
deze inlog panel is niet aanpasbaar door gebruiker, ik bepaal dus de styling hiervan
als inderdaad de gehele font wegvalt dan wordt mijn rode text ineens weer gewoon standaard zwart
wat dus geen ramp is
Eerst beweerde je dat er meerdere gebruikers zijnd ie hier gebruik van maken?
Als ik opeens merk dat de rode kleur, waar ik op let lijkt te negeren, en mijn administratie daardoor in de war schop, dan zou ik niet blij zijn.
net als ik gezegd heb tegen Ariën
de styling bepaal ik zelf
die font staat in een functie die speciaal bedoeld is om alleen die delen rood te maken
als dit wegvalt wordt dit dus gewoon weer zwart
Wat is de moeite nou als het in een functie wordt gegenereerd?
En bovendien is een simpele stylesheet al in een minuutje of 10 gemaakt. En een 'search & replace' wat zeker een onderdeel van je editor is, is ook een handig hulpmiddel.
Ik heb een beetje het idee alsof je te moeilijk denkt over zulke simpele taken.
Een editor maakt het juist makkelijker om je code te onderhouden. En ik kan mij niet voorstellen dat je echt uren nodig hebt voor zo'n simpele taak als dit.
ik heb me heel lang proberen te verdiepen in classes en functies en hetgeen dat ik zoek kan ik daar niet in vinden tenminste in veel gevallen niet, mensen kunnen mij ook niet gelijk doorsturen naar waar ik het deel dat ik moet heb zou kunnen leren
want als ik mijn hele code laat zien dan schrikken ze zich rot van alle berekeningen en zeggen vaak dat functies het wel nieuwer maakt qua verouderde code maar niet altijd beter.
Schrijf op papier in 'Jip en Janneke taal' de werking van je code op, en probeer dit te ontleden. In je vorige topic (of was dat dit topic?) gaf je aan dat je blij was dat je inzag hoe het beter kon. En nu lijk je terug te krabbelen?
ik gebruik namen omdat ik inderdaad 100-en variabelen heb
omdat dit de beste in meest overzichtelijke manier was
ja ik kan dit ook nog bv in een array zetten
code word dan nieuwer
code wordt iets langer, maar omdat ik alle $ niet meer nodig zou hebben komt dit ongeveer gelijk
voordeel?
ik zou nu het geheel in 1 keer ergens kunnen pakken
Als je het goed doet kan je juist veel code besparen, maar dat is geloof ik nu wel duidelijk gemaakt.
is dit beter Ja
heb ik dit nodig nee,
kost mij dit extra onnodig werk op dit moment ja
Ik zou toch aanraden om zo veel adviezen die hier gegeven worden aan te grijpen, als je een strakke applicatie wilt hebben.
Ik vermoed dat je inmiddels in zo'n oerwoud aan code zit, dat je zelf ook niet meer het overzicht hebt.
Om dat te refactoren wordt ook een hels karwei.
Maar wat let je om aanpassingen en uitbreidingen wél op een gestructureerde manier uit te voeren?
Behalve dan misschien een gekrenkt ego, omdat je script toch niet perfect zou zijn.
Ik kom dergelijke code nog vaak tegen.
Ooit een "ja deze pagina werkt" en dan 20 keer kopieren en slopen wat je niet nodig hebt en voila een nieuw pagaina.
Of 10 if statements "if onderdeel = x: doe iets" en "if onderdeel = y: doe bijna hetzelfde" waarbij "doe" toch gauw steeds 150 regels beslaat.
Wordt je niet vrolijk van om daarin aanpassingen te moeten doen.
Begrijpelijk hoe de code onstaan is en was toen de snelle oplossing, maar 5 jaar later heb je de ellende er nog dagelijks van.
Maar goed. Ook dit topic laat ik maar voor wat het is verder.
Eerst beweerde je dat er meerdere gebruikers zijnd ie hier gebruik van maken?
Als ik opeens merk dat de rode kleur, waar ik op let lijkt te negeren, en mijn administratie daardoor in de war schop, dan zou ik niet blij zijn.
uhm mijn script is een soort cms
elk bedrijf heeft een appart deel om het zo maar even te noemen
in dit deel kunnen zij styling van website aanmaken
elk bedrijf heeft dus in feite zelfde website die geheel doormiddel van css enz aanpasbaar is per klant
echter het inlog panel en alles daarachter is niet aanpasbaar, dit deel is zoals ik het maak
Wat is de moeite nou als het in een functie wordt gegenereerd?
En bovendien is een simpele stylesheet al in een minuutje of 10 gemaakt. En een 'search & replace' wat zeker een onderdeel van je editor is, is ook een handig hulpmiddel.
Ik heb een beetje het idee alsof je te moeilijk denkt over zulke simpele taken.
Een editor maakt het juist makkelijker om je code te onderhouden. En ik kan mij niet voorstellen dat je echt uren nodig hebt voor zo'n simpele taak als dit.
ik kan inderdaad dit zo maken maar that was not the point
ik hoef dit nu niet op dit moment te doen
ik ben bezig met andere dingen die even voor gaan
Schrijf op papier in 'Jip en Janneke taal' de werking van je code op, en probeer dit te ontleden. In je vorige topic (of was dat dit topic?) gaf je aan dat je blij was dat je inzag hoe het beter kon. En nu lijk je terug te krabbelen?
nee niet terug krabbelen
wat ik nodig heb kan ik niet vinden in vernieuwde functies/ classes (even los van of het wel bestaat ja of nee )
mensen/ scripter kunnen mij ook niet precies naar goede richting sturen,
het is zo van "gebruik classes of functies, maar hoe enz kan ik je niet uitleggen"
kijk ik geef je even 1 heel stom voorbeeld
ik heb 100 variabelen op 1 pagina
netjes gesorteerd onder elkaar met eventuele uitleg delen erbij
deze variabelen heb ik echt nodig in deze pagina, en alleen op deze pagina
alle variabelen hebben een apparte naam
deze namen zijn niet aanpasbaar of kunnen niet kleiner worden gemaakt
hoe maak ik hier een kleinere code van, die ook dus sneller en overzichtelijker is ?
Verdeel het onder in een multi-dimensionale array, zoals eerder geopperd en uiteindelijk werd begrepen.
Maar goed, ik ben zelf ook wel klaar met deze discussie die terug blijft keren. Er zijn al adviezen gegeven waar je hopelijk wat mee kan doen. Misschien is het zinvol om alles eens terug te lezen, en alle adviezen op papier op te schrijven, en dit te verwerken in een "How to refurbish this application" document, want ik kan me indenken dat je nu even door alle bomen het bos niet meer ziet.
Neem de tijd, maak testscriptjes en het komt helemaal goed op de duur.
Veel succes gewenst,
Ok, je hebt wel gelezen je?
De variabelen zijn niet aanpasbaar
Ik heb dus de hele lijst die ik nu heb, nodig
Het enigste verschil van die multi zou dus zijn dat ze naast elkaar staan in plaats van onder elkaar
Ik zie dus alleen nadelen
Als ik inderdaad helemaal terug ga naar begin
En dan alles helemaal herscript
En dan een heel uitleg deel voor mezelf maak zodat ik de complexiteit van de nieuwe code kan begrijpen en onthouden
Dan en alleen dan zou het nut hebben
Is dit nieuw en modern: ja
Zou dit beter zijn: misschien
Is dit sneller: ja en nee
Kost dit heel veel tijd: ja
Is dit verder een voordeel voor mij en mijn klanten: nee
Zou dit beter zijn voor toekomst uitbreiding: ja zeker
Variabelen kan je prima aanpassen? Het is niet zo alsof je editor dit blokkeert. En er is je ook vertelt wat de voor en nadelen zijn als je opnieuw begint vs. de huidige code refactoren. Ik kan me ook niet indenken dat je nog steeds denkt dat het geen voordeel voor jou of je klanten heeft, omdat je gisteren nog opeens blij was met het verwijderen van een zee aan overbodige code.
Maar goed, ik houd me nu echt afzijdig van deze discussie die nu al vele pagina's loopt.
Het is nu aan jouw om een goede plan van aanpak te maken. Mocht je verder nog op andere plekken vastlopen, start dan een nieuw topic vermeld met je huidige code, en wat je al geprobeerd en gevonden hebt, en zorg voor een constructief opgebouwde vraag, en sla de gegeven antwoorden niet steeds in de wind.
gelukkig heeft een van onze voorvaderen wel de moeite genomen om een wiel te maken.
was het nodig: nee ik kan alles ook dragen of slepen.
kost het tijd: ja. in de tijd dat ik een wiel maak, kan ik ook 3 keer een omgehakte boom en een hert naar mijn hut slepen.
De voorvader van Sylvester heeft echter altijd de nieuwerwetsigheid van zo'n wiel genegeerd: ook zonder kon hij wel leven. Was vermoeiend, en kostte veel tijd om alles thuis te krijgen. Maar he: hij had wel mooi de moeite gespaard om een wiel te maken. Want in die tijd dat de buurman dat deed, had hij toch mooi zijn hert en hout thuis gebracht.....
Geheel offtopic modus:
Ik zit in m'n broek te piezen van het lachen.
De prachtige metafoor die Ivo hier zet, is precies zoals het is.
Hij is geweldig. :)
Het is niet dat wij jouw code in een keurslijf proberen te persen. Het is geen kwestie van oude wijn in nieuwe zakken. Het is een kwestie van je code slimmer maken.
Dit zou in ieder geval tot effect moeten hebben dat deze een stuk korter wordt, maar ook dat delen echt herbruikbaar worden. Dit heeft ook een sneeuwbaleffect: de kans op fouten wordt kleiner omdat je meer structuur aanbrengt, het doen van wijzigingen zonder code op te breken wordt makkelijker en gaat sneller, et cetera et cetera.
Eigenlijk net zoals in tegengestelde richting jouw applicatie is gesneeuwbald: dit is nu één grote baksteen.
Ik heb het idee dat wij eindeloos tegen je aan kunnen praten maar dat het echt niet aankomt zonder een concreet voorbeeld als "bewijs", dit lijkt de enige manier om jou inzicht te verschaffen.
Daarom nu een voorbeeld van een generieke functie die wat kleur aanbrengt in een tekst. Met als verschil dat je niet meer in code hoeft te breken op het moment dat je vindt dat de kleur anders moet.
Allereerst de code:
<?php
function kleur($tekst) {
echo 'Tekst met een kleurtje: <span class="kleur">'.$tekst.'</span>';
}
?>
Vervolgens zou je in CSS de kleur kunnen vastleggen. Idealiter koppel je dit aan een class, en niet direct aan een element. Je kunt dit op verschillende manieren ophangen: als span.kleur, of simpelweg als .kleur:
.kleur { color: #ff0000; }
En je zou hier nog meer stijlregels aan op kunnen hangen om de informatie tussen <span> er meer uit te laten springen: hoe dit uitgelijnd is (jaja span is inline, maar dat kun je ook aanpassen :)), de font grootte, de letterdikte, het lettertype, de afstand tussen de karakters (monospace leest prettiger voor bedragen?) et cetera.
Wil je een keer afwijken van deze kleur? Geen probleem. Dit kun je *buiten de functie wel oplossen* zet er bijvoorbeeld een container omheen:
Nu is het bovenstaande een gesimplificeerd voorbeeld, maar stel dat je code vele malen complexer is, en je hierin zou moeten gaan breken omdat je een kleurtje wilt aanpassen terwijl dit met een andere opzet een kwestie is van een iets andere HTML-structuur en het aanpassen van een simpele stijlregel.
Dat bedoel ik met code slimmer maken: trek dit soort zaken uit elkaar (separation of concerns, opmaak heeft geen zak te maken met wat iets functioneel doet).
Ik denk dat je dit soort dingen nog niet "ziet" omdat je op dit moment dat soort programmeerervaring simpelweg ontbeert. Het is dus zaak dat je dit zelf intensief gaat oefenen wil je ooit jouw code naar een hoger niveau trekken.
Maar simpelweg omdat je dit abstracte jargon van ons (nog) niet begrijpt, wil niet zeggen dat wij (uitsluitend :)) onzin praten :).
EDIT: in zekere zin is wat je hier doet "het uitstellen van het nemen van een beslissing" die wordt gedelegeerd naar een andere plek. De beslissing die je hier uitstelt is "welke kleur geef ik mijn tekst" - de stylesheet handelt dit verder voor je af. De code heeft hier verder geen weet van en interesseert het ook eigenlijk geen biet. De code draait tekst uit en manipuleert deze, de stylesheet zorgt voor de opmaak.
