Jump to content

ignace

Moderators
  • Content count

    6,445
  • Joined

  • Last visited

  • Days Won

    25

ignace last won the day on May 14

ignace had the most liked content!

Community Reputation

196 Excellent

About ignace

  • Rank
    Prolific Member
  • Birthday 09/05/1986

Profile Information

Recent Profile Visitors

25,574 profile views
  1. ignace

    simple entity validator - critique

    Okay, let's try something simpler. Say you have this code: <?php declare(strict_types=1); // .. public function setAge(int $age) { $this->age = $age; } Passing a string to this method will throw an exception. The form processing code should validate that the age is indeed a number before passing it to your setAge() method. You can't start accepting "Dave", TRUE, ['foo']['bar'] = 'bat' as age. What I said above is basically the same thing. You protect your model from invalid data. If the business you are writing this software for has other rules, like must be over the age of 18. Then you will need to add additional checks, that his rule is not broken. And this is where you use exceptions. To halt the code from polluting your model. So to answer your question: yes, you must validate the data both in your model and in your form. The reasoning here is that your data might not always come from a form. But perhaps some data is input from a 3rd party API. Or from the CLI. Wherever the data comes from, you can be certain your model will always be valid. If you are too lazy to write out all the exceptions, follow these rules: Use this library: https://github.com/webmozart/assert Write custom value objects like the example in my previous post: BirthDate. Which you can use over and over again. Need another example? <?php class EmailAddress { private $emailAddress; public function __construct(string $emailAddress) { if (!filter_var($emailAddress, FILTER_VALIDATE_EMAIL)) { throw new InvalidArgumentException(sprintf('The e-mail address "%s" is invalid.', $emailAddress)); } $this->emailAddress = $emailAddress; } public function getMailTo(string $subject, string $body): string { return sprintf('mailto:%s?%s', $this->emailAddress, http_build_query([ 'subject' => $subject, 'body' => $body, ])); } public function getEmailAddress(): string { return $this->emailAddress; } } To answer your 2nd question: Don't use exceptions for validation. The code should not be halted at that point, as you want to report back ALL errors at once to the user instead of 1-by-1.And use a format that is most easy to work with like an array to store the validation errors. Also create dedicated validators for your entities. As you might need to validate your entity in more than 1 place. It can still extend from a base generic validator: <?php class LoginValidator extends Validator { public function validate(array $data) { return parent::validate($data, [ 'username', 'password', ]); } }
  2. ignace

    simple entity validator - critique

    Yes, your form and any other client-side code should have validation that checks that all business rules (being 18+) have been enforced. Validation and exceptions are not the same thing. Validations are done before you pass it down. While exceptions are thrown after it has been passed down and is invalid. Because your model sits at the center of your application and is guarded with exceptions it becomes impossible to use them with invalid data. Which makes your life as a developer much easier. And anything you add on top adds it's own validation and has it's own method of communicating error's back to the user.
  3. ignace

    simple entity validator - critique

    Entities should not have error messages, they should throw exception's on invalid input. Error messages are to indicate to the user that what he input is invalid. Why exceptions? Because your model must be a source of truth, it enforces the business rules. The application (forms, buttons, ui) lies on top of your model. So for the application to communicate effectively with the model it must ensure all input is valid BEFORE the model is called. The exception's are usually called like this in the model: <?php public function setBirthDate(DateTimeInterface $dt) { $this->assertGreaterThanOrEqualTo18($dt); $this->assertLessThan100($dt); $this->birthDate = $dt; } Because you may have these business rules. You can take it one step further: <?php class BirthDate { private $date; public function __construct(DateTimeInterface $date) { $this->assertGreaterThanOrEqualTo18($date); $this->assertLessThan100($date); $this->date = $date; } } public function setBirthDate(BirthDate $bd) { $this->birthDate = $bd; } Now every time you use a birthdate you will apply the business rules.
  4. ignace

    Header problems

    1) Let the view do a sub-request to the header controller to load the menu. 2) Create a view helper that loads the menu. Both will require the current route to determine which hierarchy to load/show.
  5. ignace

    Do i have to pay tax if teach on the web

    If you have a monetary income in any officially recognized currency*, you need to pay tax! It's that simple, really. Now it's possible that certain income is exempt from tax, for example, a yearly turn-over less then 5.000 individually, or 25.000 as a business. That's the current law in Belgium. I am not an accountant, and I am unfamiliar with tax regulations in Australia. If you have a business, it's recommended to have an accountant, he'll advise you on the best approach, and keep your taxes in check. *So anything not monetary, or any unofficial currency, would be tax-free. Get paid in litecoin?
  6. ignace

    New Guru: maxxd

    Nope, they don't. At least not in my case, others may have had better luck. I was only joking when I said that. I am already happy if I get a thumbs up on my answers.
  7. ignace

    Composition over inheritance examples

    Admin seems more like a privilege/role, so I would make that a field of User. Then your User and Person. I get what you are saying, and I have this in my system. I would have a Person object with no reference to a User. And let the User reference Person. Thus decoupling my application from the auth layer. <?php class User { const ROLE_SYSTEM = 'role_system'; const ROLE_ADMIN = 'role_admin'; /** * @var string[] */ private $roles = [ ]; /** * @var Person|null */ private $person; } For system accounts, the Person reference would be NULL as it's not required and it's role would be ROLE_SYSTEM.
  8. ignace

    Should mappers digest objects?

    And after you started using the power sander, how often have you done it by hand since? And if given the chance to do it by hand, would you still do it? Regardless of the fact that these are apples and oranges. If done by hand or machine delivers about the same end-product. Regardless with which you started or ended. You can start by hand, go to the machine, and finish by hand. Also the work still has to be done, to get the final product. This is not the case in software development. You would basically pick up an already sanded object of any length and any given size in an infinite supply.
  9. ignace

    Should mappers digest objects?

    Events are a good way to extend your code without adding unnecessary dependencies. A ghost copy is a class with only it's ID filled in. Personally I avoid writing things that have been written before and rather build upon them. In the long run of an application you get burned by the "not invented here" syndrome. I have seen it over and over, and over again.
  10. ignace

    Should mappers digest objects?

    What requinix said, and to reduce unnecessary: querying, hydrating, etc.. for what is essentially throwing something into the bin. And it still allows your mapper to fire off any associated events, if there would be any. Another option would be to use a ghost copy, and drop the deleteOneById. But that depends on how you architect your software. Since a DELETE is the opposite of a SELECT. You can create any "query" methods for it: deleteAllByCompanyName(string $companyName); Internally they do the same thing as with the deleteOneById. They query and store any ID's scheduled for deletion. So that any future find's would return NULL even before the database is synchronised. Avoid any createFromArray or updateFromArray methods though, use the find methods instead.
  11. ignace

    Should mappers digest objects?

    For a Data Mapper this is mixed. Since your mapper maps from and to the database. You would need to be able to use several types of input to get what you need. <?php interface UserMapper { function findOneById(int $id): ?User; function findAllById(array $id): ?UserCollection; function findOneByUsernameAndEmail(string $username, string $email): ?User; function findAllRegisteredBetween(DateTimeInterface $start, DateTimeInterface $end): ?UserCollection; function findAllRecentlyRegistered(DateTimeInterface $currentDate): ?UserCollection; function create(User $user): void; function createAll(UserCollection $users): void; function update(User $user): void; function updateAll(UserCollection $users): void; function delete(User $user): void; function deleteAll(UserCollection $users): void; function deleteOneById(int $id): void; }
  12. ignace

    Collection classes

    And that's bad? Why? Ever seen classes implement nothing more than __invoke? Or a Command with only an execute() method. What about 2 methods? How many methods should in your opinion a class have?
  13. ignace

    Should properties with methods be public or private?

    @NotionCommotion
  14. ignace

    Should properties with methods be public or private?

    Properties are like your intestines, you don't want anyone else to touch them. Unless, perhaps for surgery (my architect mind is already modelling this, I'll spare you the details). Therefor they should always be private. If something does need access, they can use an interface you control. In certain cases you could opt to mirror methods instead of exposing the sub-object, but it's certainly not advisable to mirror the entire interface. In this case, just create a getter. But don't ever expose a public property, you are inviting bugs. PHP does not yet have the powers other OO languages have.
  15. ignace

    New Guru: maxxd

    Well, pretty much everyone on here has a "Donate to me!" button so go ahead and buy us all a round Congrats on the promotion!
×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.