[PHP/(My)SQL] voor dummies #117

quote:

Op woensdag 20 augustus 2014 23:25 schreef robin007bond het volgende:

[..]

Misschien zeg ik iets stoms hoor.

Maar kan je niet een aparte tabel maken met synoniemen en met allemaal foreign keys van dingen die synoniem van elkaar zijn binnen een bepaalde context?

Dat je dus een row hebt met appel, banaan en peer (als dat synoniemen zouden zijn natuurlijk ) en dan met een join legt naar de synoniemen zodra de zoekopdracht wordt gedaan?

Ik volg je mischien niet helemaal, maar wat ik bedoel; een gebruiker doet een zoekopdracht via een tekstveld, hier vult hij appel in.

Vervolgens submit hij deze, en moet er een query uitgevoerd worden waar ik op dat moment alleen de waarde "appel" heb.

Heel simpel gezegd krijg je dan zo iets SELECT * FROM gerechten WHERE naam LIKE '%appel%'

Dus ook appelmoes wordt getoond, maar dit moet ook perenmoes zijn omdat het ( in dit voorbeeld dan ) een synoniem is.

Jouw suggestie is dus om een aparte tabel te hebben waarbij je zo iets krijgt:

naam - synoniem
appel - peer
appel - banaan
appel - etcetc

maar hoe koppel ik die 3 rijen dan weer efficient terug naar de gerechten tabel, zodat hij ook hier op gaat zoeken.

Ik had zelf het idee om tijdens het toevoegen van die synoniemen of gerechten al alle matchende rijen op te zoeken, en alle koppelingen al direct opslaan zodat ik hier op kan joinen wanneer een gebruiker zoekt.

Maar dat is naar mijn idee ook wel een beetje lomp.

Je sluit je foreach niet eens af?

quote:

Op zondag 24 augustus 2014 14:22 schreef Igen het volgende:
O ja, het gaat dus fout bij het volgende stukje code:
[ code verwijderd ]

Bij die laatste regel regel met "$name = ..." ontstaat dus een aanroep naar __autoload met die schijnbaar totaal willekeurige letters en cijfers als class-naam.

Iemand enig idee waarom?

omdat de functie call_user_func eerst de callback mee moet krijgen en als tweede argument de parameter. Nu doe je het andersom

mixed call_user_func ( callable $callback [, mixed $parameter [, mixed $... ]] )

quote:

Op zondag 24 augustus 2014 16:12 schreef remi1986 het volgende:

[..]

omdat de functie call_user_func eerst de callback mee moet krijgen en als tweede argument de parameter. Nu doe je het andersom

mixed call_user_func ( callable $callback [, mixed $parameter [, mixed $... ]] )
[ code verwijderd ]

Nee hoor, volgens mij wil hij als callback GetName van de betreffende childclass aanroepen. Op zich is het valide code, maar wellicht is GetName niet static.

quote:

Op zondag 24 augustus 2014 16:57 schreef Igen het volgende:
Ja, dat was de fout hoor! Bedankt!

Geen probleem. Vraag me alleen wel af wat je probeert te bereiken, want erg logisch ziet het er niet uit.

quote:

Op zondag 24 augustus 2014 17:52 schreef Igen het volgende:

[..]

Heb voor m'n persoonlijke website een simpele CMS gemaakt, als programmeeroefeningetje. De data bestaat uit een boomstructuur van pagina's, subpagina's, koppen, alinea's, plaatjesgalerijen, losse plaatjes, embedded youtube-filmpjes enz. Het stukje code wat ik liet zien, maakt een menuutje waar je kan kiezen uit de geldige soorten inhoud die je op een bepaald punt kan invoegen (een plaatje of filmpje bijv. alleen in een galerij, etc.).
[ code verwijderd ]

(Ik geloof dat het niet netjes is om HTML direct in de code te genereren, maar dat is weer een ander verhaal)

Maar al die classes hebben dus een statig GetName die een bepaalde naam teruggeeft of hoe moet ik het zien?

Wat een vage constructies je hier soms ook tegenkomt

Eerst uit de database een rijtje namen halen, en dan vervolgens aan de class vragen van "hee hoe heet jij?"

quote:

Op zondag 24 augustus 2014 18:26 schreef Igen het volgende:

[..]

Ja.

[..]

Klopt. Ik wil niet dat de eindgebruiker rechtstreeks in de HTML-code kan zien hoe de klassen intern heten.

Daar heeft de gebruiker niet zo veel aan hoor.

Dit soort bijzondere constructies zijn ook echt schering en inslag in PHP.

quote:

Op zondag 24 augustus 2014 18:49 schreef Igen het volgende:

[..]

Ik vond het netjes om het zo te abstraheren. Maar misschien heb je gelijk en is het overbodig. Niet dat de code er veel anders van zou worden, op z'n simpelst zou het zoiets worden:
[ code verwijderd ]

Gebruikt nog steeds dezelfde constructies. Welke constructie vind je eigenlijk zo "bijzonder"?

De hele manier waarop je data in de database en de code zelf verwoven lijken te zijn.
Sla dan dit soort informatie in zijn geheel op in de database.
Sowieso heb ik het idee dat hier weer een brij aan inheritance ipv composition wordt gebruikt.

quote:

Op zondag 24 augustus 2014 18:49 schreef Igen het volgende:

[..]

Ik vond het netjes om het zo te abstraheren. Maar misschien heb je gelijk en is het overbodig. Niet dat de code er veel anders van zou worden, op z'n simpelst zou het zoiets worden:
[ code verwijderd ]

Gebruikt nog steeds dezelfde constructies. Welke constructie vind je eigenlijk zo "bijzonder"?

het idee van classes is dat je er objecten van maakt. Een getname functie zou dan logischerwijs betekenen dat je de naam van het desbetreffende object krijgt, en niet de naam van de class.

Waarom zet je die screenname niet in de database erbij dan? Scheelt je loopen door al die classes en hoef je ook niet in elke class die functie aan te maken.

Phred is an open-source initiative aimed at providing PHP with a consistent, completely object-oriented coding standard that enjoys a comfortable API for creating modern-day web applications with native support for Unicode, with components for internationalization and localization, clear-cut fundamental data types focused on performance and reliability, enhanced testing and debugging, and other features.

[…]

PHP 6 or Uniphant vs. Elecorn
Most of the hopes for a better PHP were being put in PHP 6 announced around 2006. However, PHP 6 became more like a mythical creature over the time, a creature that no one has ever seen. The new features that were planned for PHP, including the highly anticipated Unicode support, had never got released under PHP 6 label. Instead, the PHP 6 development branch was discontinued and only some of the features were backported into the 5.x versions afterwards, still without built-in Unicode. There was no beta or even alpha version of PHP 6.

One of the main reasons behind PHP 6 getting abandoned was a disagreement inside the development team as to which character encoding would serve best for storing and processing Unicode strings. Despite of the fact that the team then picked UTF-16 as the internal encoding to be used for Unicode, the development ran out of steam and eventually came to a halt. This happened not only because the choice of UTF-16 turned out to be suboptimal, but also because of the immense body of work that was required to be done for the PHP's core and all the extensions by the developers becoming less and less enthusiastic with the direction that was chosen and due to other issues. Andrei Zmievski, who was the head of the PHP 6 project, later admitted that he would probably choose UTF-8 over UTF-16 if it was possible to start over.

[...]

こんにちは, Phred
The idea of Phred is resonating with the principle of separation of concerns. Let the PHP's core contributors remain focused on the language's underpinnings and further improve the PHP's engine to make it even faster, effectively providing a high-performance foundation upon which a consistent and completely object-oriented coding standard can be implemented by PHP developers themselves.

By extending PHP 7, which is now twice as fast, Phred converts PHP into an up-to-date and clean standard advantageous for creating sophisticated web sites and applications to be used by people all over the world, while keeping performance at a high level. Fortunately, the OOP-related features that are already present in PHP 5.6 and PHP 7 have made this possible. And not to forget the vital OOP infusions into the language that were faithfully made by some of its core contributors, most notably Nikita Popov.