Skip to main content


Questions Depository


!Friendica Developers
Calling @Hypolite Petovan for help :-)

Why did you introduce a separate "Navigation" directory under "src"?

My guess: this is really a DDD practice using a directory for a use cases and define the different class-types under it (creating boundaries between differently purposed code). But if so, why don't you include the Modules/Notification as well?
And "Navigation/Notification" triggers for me, that the focus of this class is only the notifications at the top of the navbar, am I right?
I'm trying to follow your pattern and refactor the ProfileField / PermissionSet.

Would it be a new "src":
"src/Profile" , where PermissionSet and ProfileField are Entities/ValueObjects ? Or how would you structure these repositories/models?
This entry was edited (2 weeks ago)

Friendica Developers reshared this.

hm .. no I'd say PermissionSet is a "src/Items/Entity" thing, isn't it?
When I started working on the 2FA feature, I got the idea of grouping all the related classes in the same subfolder instead of having them grouped by type. After all, when you're working on any given task, you're more likely to need to access the classes of different types relating to the same feature than to need to access the classes of the same type for different features.

However, modules are completely different from the Entity/Collection/Depository/Factory paradigm, mostly because they depend on the global context and as such they are the only ones that should make use of the DI shorthands. They also are depending on the routes file, and it is nicer to see all the available routes in the same folder.

I kept this trend with notifications, and I chose "Navigation" because notifications are meant to redirect users to the relevant content.

I think ProfileField classes should go under "Profile" like you suggested and PermissionSet may go under "Privacy" since I feel like "Item" feels too broad and we don't use permission sets just for item (post and replies).
Aaahh sounds like the "good old" Model View Controller (MVC) pattern:
- Model --> where the business logic is (=> Entity, Depository, ...)
- View --> the presentation layer (=> Renderer / smarty templates)
- Controller --> The logic to show the right business logic (glue between model & view) (=> Modules)
=> And I like it :-)

I'll give it a try after finishing the WebDav class ;-)
I didn't think in so many terms, but it looks like it, indeed!
I'm sorry, I'm mostly thinking that way ^^..