Conversation

Notices

1. Embed this notice
   Matthias Moritz (matthias@anonsys.net)'s status on Wednesday, 23-Nov-2022 00:45:56 JST Matthias Moritz
   I don't realy like how I implemented this because I have some of the privacy Logic in the Calendar Module/Events and some in the Event Model.
   
   So How is the usual approach for that?
   
   Model makes the connection to the database and fetches the Events.
   - I can decide there what conditions must be applied (needs to load and read the configuration).
   - Or I can create different methodes for different use cases in the Model and decide in the Module which one I call.
   - Or I can call a more generic methode in the model with the privay parameter from the Module
   
   So many possibilities. Which one would you choose and why?
   • Embed this notice
     hypolite (hypolite@friendica.mrpetovan.com)'s status on Wednesday, 23-Nov-2022 00:45:54 JST hypolite

     in reply to
     @matthias So, you caught me in a bind, because the codebase is split between the previous coding paradigm with static Model classes with direct access to the database, and the new coding paradigm involving Entities, Factories and Repositories.
     
     I do not want you to subject you to the complex migration that it would take to bring events to the new paradigm, so I'm left with advising you on the old coding paradigm that will eventually be replaced.
     
     I would say the privacy SQL conditions should be set in the Model class. Who these conditions apply for should be provided by the module class through a User Id. However, having separate methods for the different use cases in the Model class is closer to what it would look in the new coding paradigm.
     
     Is this clear to you?
   • Embed this notice
     Matthias Moritz (matthias@anonsys.net)'s status on Wednesday, 23-Nov-2022 01:03:12 JST Matthias Moritz

     in reply to

     • hypolite
     @hypolite Absolut clear what you mean. Thx!
     hypolite likes this.