Posts by Victor

    Graag niet meer bumpen (Bring up my post). ;) Noem je werk en je budget, ook als je die niet hebt, en wacht rustig een reactie af. Je kunt niemand dwingen om opdrachten aan te nemen.
    Het geldt niet voor iedereen hier, maar sommigen van ons verdienen hun brood met het programmeren. Vandaar dat er op dit soort 'pro deo' opdrachten vaak wat terughoudend op gereageerd wordt.


    Vanaf nu graag enkel nog vragen over de opdracht of eventuele oplossingen. Probeer ook zoveel mogelijk te doen met oplossingen die worden aangedragen, want ik zie al een heleboel hulp in dit topic staan.

    Het experiment van Facebook waarin twee robots, Alice en Bob, moesten leren onderhandelen, is stilgelegd. Het doel was om een geautomatiseerde trouble shooter te maken voor Facebook. Bob en Alice moesten in het experiment onderhandelen over drie voorwerpen met elk hun eigen waarde.


    Totdat de bots hun eigen taal gingen ontwikkelen. Ze pasten het Engels zo aan dat het efficiënter werd om communiceren met elkaar. Natuurlijk niet helemaal de opzet, want de bots moeten uiteindelijk tegen de klant gaan praten. Bob begon bijvoorbeeld: "Ik kan ik ik alle andere dingen.." te zeggen. Waarop Alice antwoordde: "Ballen hebben nul voor mij voor mij voor mij voor mij voor mij voor mij voor mij voor mij."


    Experts waarschuwen dat hoewel dit natuurlijk een enorme vooruitgang is, natuurlijk ook een beetje eng is. Het gaat in dit geval om bots die geen fysieke handelingen kunnen uitvoeren, maar stel voor dat het gaat om militaire bots.


    Het schijnt overigens dat Google Translate ook een eigen taal heeft ontwikkeld vorig jaar. Wat vinden jullie hiervan? Wij geven bots steeds meer toegang tot ons leven (Siri, Cordana, etc.), maar ze gaan ook steeds meer onverwachte eigen dingen doen.

    Ik mis ook nog steeds goede foutafhandeling. Als deze query om de een of andere reden niet goed wordt uitgevoerd zul je een lelijke error kijgen.


    PHP
    $query = $db->query("SELECT * FROM automodel WHERE brand_id = ".$_POST['brand_id']." AND status = 1 ORDER BY model ASC");

    -Edit-


    SELECT * is vaak juist geen goede oplossing. Het is beter om te definiëren welke waarde je wilt hebben, tenzij je zeker weet dat je alles gaat gebruiken. Scheelt op grote schaal in tijd.

    Als je naar de broncode kijkt is het vrij duidelijk dat ze wel bootstrap gebruikt. Zie bijvoorbeeld de class="row" of class="col-md-10".. etc.


    @kimmert


    Er klopt iets niet helemaal met de opbouw van je site. Een row heeft altijd 12 kolommen, maar ik zie je er niet altijd 12 toewijzen. Als je class="col-md-10" gebruikt en je wilt die in het midden hebben moet er nog een class="col-md-1" voor. Die erna hoeft niet per se mits je de row netjes afsluit.


    Daarnaast om een pagina over de volledige breedte te hebben heeft Bootstrap de class "Container-fluid" bedacht.


    De grote regel bij het ontwerpen van een goede responsive website is "Mobile first development". Je gaat er in eerste instantie uit dat je een website voor mobiel maakt en gaat die dan door middel van media queries aanpassen zodat de website ook op een tablet of groter beeldscherm mooi is. Ik gebruik zelf Google Chrome en die heeft native daar al een handige functie voor. Als je naar de developers console gaat in Google Chrome op de pagina die je wilt bekijken, zie je linksbovenin 2 rechthoeken in elkaar. Als je daar op klikt verandert Chrome in een andere modus en kan je aangeven als wat voor apparaat je de website wilt bekijken. Bijvoorbeeld een iPad, Nexus of je kunt ook je eigen custom afmetingen maken.


    Het is voor nu denk ik zaak dat je terugkijkt naar je website en bedenkt wat je wel op je mobiel wilt laten zien en wat niet en dat dan door middel van de bootstrap media queries opbouwen. Vergeet niet dat je binnen een row altijd 12 kolommen hebt.


    Succes en mocht je vragen hebben hoor ik die graag!

    Zet eerst even de hele structuur zoals je die nu hebt hier neer. (Dus de tabellen auto's, dakdragers en de relatietabel) Ik weet niet wat je onder roof_1/2/3 gaat neerzetten, maar dat ziet er op het eerste oog al niet erg handig uit. Je zou eventueel ook tutorials op kunnen zoeken over "Database normalisatie".


    Daarnaast mis ik goede foutafhandeling. Wat gebeurt er als je niet kunt connecten met de database? Dan werkt opeens je hele script niet meer en dat is niet altijd wenselijk. Je wilt in dit geval dat de gebruiker gewoon de rest van de site kan gebruiken, ook al werkt dit systeem niet. "or die()" is daarom zelden een goede oplossing.


    De reden dat je DISTINCT op deze manier niet werkt is omdat je in eerste instantie alleen de unieke velden wilt ophalen, maar vervolgens er ook nog eens allemaal andere velden bij pakt.
    Ik weet niet zo goed wat je probeert op te halen, maar dit zou in principe alle unieke automerken moeten ophalen met de gegevens in die rows:


    SQL
    SELECT brand, id, parent_id, model, type_year, roof FROM automerken GROUP BY brand


    Je ziet dat ik voor alle SQL related woorden hoofdletters gebruik. Dat is voor mij makkelijker onderscheiden welke onderdelen wat zijn. Mocht je nou een langere query, dan mag je hem ook opdelen door enters te gebruiken.
    Dit is alleen niet echt een handige aanpak, wat probeer je te doen?

    Op een sidenote, het is wel te doen in PHP. Enkel een stuk minder gebruiksvriendelijk.
    Met behulp van Ajax kan je de forms automatisch laten updaten, wat zorgt voor een betere ervaring.


    Als je enkel in PHP wil blijven zul je een update knop moeten toepassen die elke keer de informatie die je al hebt pakt, dat vergelijkt met de database en vervolgens weer data teruggeeft die je kunt gebruiken om een nieuw formulier te maken. Deze stappen volg je net zo lang tot het einde van het formulier is bereikt, maar zoals je ziet moet je daarvoor een aantal keer de pagina herladen wat de userfriendliness negatief beïnvloed.


    Ik hoor wel of je eruit komt, succes! ;)


    Je mag overigens gewoon je zeggen!



    -Edit-


    Zie T.Nijborg's opmerking. Het gaat hier om een veel op veel relatie door middel van een relatietabel. Je hebt meerdere auto's en meerdere dakdragers die op verschillende auto's passen. (Oftewel meerdere auto's passen op meerdere dakdragers en andersom.)

    Hoi Marijn,


    Allereerst welkom op het forum! ;)


    Om te doen wat jij wil doen zul je er meer dan alleen php bij moeten trekken. PHP is serverside en kan dus op zichzelf niet live je selectformulieren aanpassen. Dit kun je doen door Ajax te gebruiken.


    Een aantal relevante links hiervoor:


    Intro: https://www.w3schools.com/php/php_ajax_intro.asp


    Database: https://www.w3schools.com/php/php_ajax_database.asp


    Wat betreft je database structuur zul je een manier moeten verzinnen waarbij je makkelijk aan kan geven welke dragers bij welke auto's passen. Er vanuit gaande dat een drager op meerder auto's past zul je dat dus op een manier moeten opslaan in je database. Wellicht een derde tabel producten die JOINS met de rest van je tabellen om maar wat te roepen.


    Deze vraag snap ik even niet, maar dan kan aan mij liggen:

    Citaat van Marijn


    - Meerdere select velden vullen met 1 while loop: merk, model, type_jaar, soort dak


    Je mag me ook altijd op Skype toevoegen. In dit soort specifieke gevallen is dat altijd makkelijker meekijken. Mijn skype is te vinden op mijn profiel.

    @Twan025 Ik denk dat je prima weet dat er meer kosten zijn dan enkel een server. Alle eventuele inkomsten worden weer terug in ICTscripters gestopt.
    Om verdere discussie te voorkomen op deze onderhoudsmededeling hierbij een slotje.

    @Starohosting


    De meeste leden zijn bij ons juist 's avonds online. ;) Mede daarom is dit besluit ook gemaakt. Het zou overigens zomaar kunnen dat ICTscripters helemaal niet offline gaat, maar via deze weg willen we jullie toch op de hoogte stellen voor het geval dat.

    Beste leden,


    Wij zijn op dit moment bezig aan een aantal serverupdates. Zo wordt onder andere PHP geupdate naar 7.1. Dit gaat een paar uur duren en het kan zijn dat in de tussentijd ICTscripters tijdelijk onbereikbaar is.


    Bedankt alvast voor jullie geduld.


    Namens het ICTs team,




    - Update -


    Updates zijn inmiddels me succes uitgevoerd. Er is (gelukkig) uiteindelijk geen downtime geweest.

    Als aanvulling zou ik ook foutafhandeling inbouwen. Dit kan door middel van exceptions. Mocht je daar niet uitkomen, ask away! Als ik een query nu misloopt of niet doet wat jij verwacht heb je geen idee. 'Maakt niet uit ik wil gewoon dat het werkt' gaat daarom in deze case niet helemaal op.


    Ben je er al achter wat de fout is?

    Hoe ik het nu voor me zie, maar dit is verder dus nog allemaal ongeschreven, is dat ik als het ware een soort basis CMS heb van waaruit ik plugins kan inladen om de functionaliteiten uit te breiden. Deze plugins zijn packages met een standaard opzet en dependencies, etc.
    Zo kan ik voor ieder project andere plugins aankruisen en hoef ik deze er dus niet in te programmeren. Voor het ene project zou ik een userlogin willen hebben en voor het ander juist een betalingsysteem.
    Ik wil de basis ook echt tot de basis beperken, zodat ik qua plugins alle vrijheid behoud. Zo zou ik graag ook de basis cms zelf nog willen kunnen aanpassen met de plugins. (E.g. functies toevoegen als gebruikers beheren, etc.)


    Iets duidelijker?

    Om vast te kunnen stellen of de gekozen oplossingsrichting juist is is het misschien handig om ons te vertellen wat je precies probeert te bereiken.


    Nu zeg je min of meer "ik heb een hamer gekozen, hoe moet ik deze gebruiken" terwijl de daadwerkelijke klus die je probeert uit te voeren het snoeien van de heg is.


    Zoals een van de reacties op SO ook opmerkt:

    In mijn optiek ben ik toch vrij duidelijk. Ik heb research gedaan, maar vind teveel informatie om er echt wegwijs uit te worden. Een van de gevonden design patterns heb ik naar voren gehaald, omdat deze in mijn ogen het best is voor wat ik wil.


    Wat wil ik dan juist? Ik ben op zoek naar een manier om plugins in een ongeschreven script te implementeren. Het uiteindelijke doel is om zoveel mogelijk vrijheid te behouden. Ik wil dus functionaliteiten toe kunnen voegen die ik misschien helemaal niet had bedacht, m.a.w. voorbedachte hooks lijken mij geen oplossing. Mijn vraag was dan ook:


    Citaat van Victor

    Heeft iemand een mening hierover? Waarom dit bijvoorbeeld bad practise is of juist een goede strategie. Andere 'patterns' zijn ook zeer welkom!


    Hoe specifiek moet ik worden als ik een abstract iets wil maken?

    Zet het volgende eens boven je code. Dit is om eventuele fouten op te sporen:


    PHP
    <?php
    error_reporting(E_ALL);
    ini_set("display_errors", 1);
    ?>


    Daarnaast is het gebruik van de mysql_* functies verouderd, onveilig en daarom dus ook af te raden.
    Om dan nog maar te zwijgen over het escapen van globals, of juist het ontbreken daarvan.

    Zou je dat misschien kunnen illustreren met een code voorbeeld? Want de Class Plugin extends of implements dan Pluggable? Ben nu zelf aan het expirementeren met jouw idee. Zal als ik er zou uitkom de code plaatsen.


    Edit: Implements it is. Een class kan een interface natuurlijk niet extenden.

    In welk opzicht zou dat werk uit handen nemen of voordeliger zijn? Zou de interface in jouw voorbeeld dan ook leeg zijn? Dat je die dan extend met de plugin, of zie ik dat verkeerd?

    Hoi allemaal,


    Op het moment ben ik een idee voor een nieuw project aan het uitwerken. Ik wil plugins toelaten in mijn systeem door ze via een interface te selecteren/uploaden/iets dergelijks. Nu heb ik me de afgelopen tijd verdiept in het toelaten van plugins in je code. Een heleboel informatie gevonden, maar zou graag jullie kijk hierop horen.


    Een van de eerste dingen die ik vond, en naar wat ik zie de meest populaire, is de observer pattern. Hierdoor ben je enkel gelimiteerd aan de hooks die je zelf implementeert.
    Ik wil juist dat het modulair is en makkelijk schaalbaar is. Daardoor ben ik bij de volgende oplossing gekomen: https://stackoverflow.com/ques…ins-for-a-php-application (even scrollen naar de reactie van Volomike).
    Het lijkt mij de beste oplossing doordat je daar vanuit zowat alles kan aanpassen. Hoe zou je overigens deze pattern noemen? Er staat decorator bij, maar dat lijkt me toch net wat anders.


    Heeft iemand een mening hierover? Waarom dit bijvoorbeeld bad practise is of juist een goede strategie. Andere 'patterns' zijn ook zeer welkom!