mailcow / mailcow-dockerized

mailcow: dockerized - 🐮 + 🐋 = 💕
https://mailcow.email
GNU General Public License v3.0
8.95k stars 1.17k forks source link

Bring in MVC / OOP #708

Open develth opened 7 years ago

develth commented 7 years ago

Hi,

wanted to start a discussion if it would be a good idea to bring in some MVC / OOP style into this Project´s web application. I recognized that there is a lot of duplicate code and a mixture between PHP & HTML ( and javascript and css ).

I think it would improve the web application a lot to separate those stuff and make things reusable. Bring in some OOP for API handling and e.g. Entity / Form Validation.

IMHO: A good first step would be to integrate a template engine like twig.

What do you guys think?

I think this is and will be a powerful application / toolset and we could improve the code quality ( e.g. integrate unit tests etc. ) a lot.

Thanks & Cheers, Thomas

develth commented 7 years ago

To better show off what i mean i started to implement the mailbox.php into twig ( pretty basic ):

https://github.com/gigabit-gmbh/mailcow-dockerized/tree/feature_twig

You can see here a example of the usage of e.g. macros for a better reusability.

andryyy commented 7 years ago

Sure, sounds like a great idea. It was never supposed to grow like that, so I always postponed it until... tomorrow. 👎

But that's a bunch of work...

develth commented 7 years ago

Yep, absolutely a lot TODOs.

But maybe starting at some points ( e.g. twig ) and later switch with a new Version to a another setup. I´m ready to help ;)

andryyy commented 7 years ago

Hm, we could start with a lot of PHP code fixes/changes. :-)

develth commented 7 years ago

For sure. Are there open issues regarding those fixes / changes?

andryyy commented 7 years ago

No, not really. It is a "start anywhere".

mablae commented 7 years ago

Hi there,

I also thought about introducing a more OOP approach to the webUI. Maybe we could use symfony as a framework for that on the long term? It also uses twig as default template engine.

@andryyy The project seem to grow on a daily basis and has many github likes already. Handling the webUI stuff in a more serious way opens new possibilities regarding form validation, api, Database Modeling and so on. There was already some guy, who has coded an symfony based crud system for your database scheme, I will look it up.

@develth Did you already start?

Braintelligence commented 7 years ago

I could help out if you guys decide to not go the PHP route but rather stick to Django/Flask (Python).

develth commented 7 years ago

hi @mablae

symfony would be also my first choice - but to switch hard and in one step isn´t possible, i think. Because of that i wanted to start step by step, starting with twig to separate php from html.

I started just with an little example: https://github.com/gigabit-gmbh/mailcow-dockerized/tree/feature_twig

mablae commented 7 years ago

Yeah, it would be step by step. What do you think about Controller / Router as one of the next steps? I would say it's nice having just a single index.php Frontcontroller for everything.

extremeshok commented 7 years ago

KISS approach would be best, maybe consider a microframework ? https://lumen.laravel.com/ or the mighty https://laravel.com/

develth commented 6 years ago

@extremeshok I would like to go into the symfony direction and use the components of that (whats used by lumen, laravel).

@mablae i think to separate templates and controllers would be the first step, second as you mentioned the controller and routing. A single FrontendController could be lead to a bad maintenance. I would separate the sections in single controllers, and provide functions that deliver a format defined by e.g. the "Accept" Header. So we do not have multiple functions for json or html calls.

Or do you guys want to build it in another way?

Dragnucs commented 6 years ago

@develth Symfony has a very good and detailed best practices guid covering all of what you mention, like controllers, templates, internationalization and even business logic.

Symfony 4 is also very light and slim, uses very good design patterns and has a 3 years long term support release. It also intergrates well with webpack, so using Vue.js or other JavaScript frameworks is easy and seamless.

develth commented 6 years ago

@Dragnucs thats why i mentioned it. But IMHO its not possible to do an "big change" switch - thats why i suggested to integrate one component step by step until we can make the full switch to the current symfony version

Dragnucs commented 6 years ago

I am making the exact transition at work. I am planing these big steps:

  1. Implement views in Vue.js
  2. Refactor to a cleaner code (ours is messy)
  3. Introduce Vuex
  4. Implement proper backend API
  5. Make necessary changes in Vuex actions when needed
  6. Introduce Symfony
mablae commented 6 years ago

Symfony would be a great choice

develth commented 6 years ago

Wouldn't go vue / vuex template implementation. 1) The change would be too big from php to something totally other 2) Views should be done with twig and server side processing.

But integrate vue as js framework would be a great choice in one of the next steps

develth commented 6 years ago

@andryyy I want to start with that before the application grows and grows (whats really nice) and the changes will go to a massive amount. Is there a platform (slack, irc) to discuss and plan this project with you and some other coders?

mhf-ir commented 6 years ago

core applicatiom better to design as api server, php/node/python/ruby etc ... dosnt matter ... clean api could be good if you integrate mailcow to another systems. Api with openapi standards will be great.

Hecke29 commented 6 years ago

@develth I'm a symfony developer with main focus on JSON REST-APIs. Since I like to see that mailcow gets a good API, feel free to contact me: 0xDCB68FB86823E595 (PGP) or tell me about an slack / IRC.

develth commented 6 years ago

Maybe a Slack / IRC Channel would be the best, so others could also join the discussion. @andryyy Is there anything we could join / connect to?

mhf-ir commented 6 years ago

API with admin access can CRUD domain domain_aliases user user_aliases and some stuff like generate smtp/pop/imap configuration on the fly based on mailcow configuration. Even if any http interface for download and process mailboxes like folders spam unreadmessages will be awesome. It's will be awesome.

MAGICCC commented 6 years ago

@develth irc.freenode.org:#mailcow

stale[bot] commented 6 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Hecke29 commented 6 years ago

What would be a good way to start work at this - like defining a desired state and what exactly should be archived or something like that? Maybe kind of a roadmap which steps to take. It's hard to start work (together) on this with no clear and common vision

mablae commented 6 years ago

I would also like to participate, still think Symfony would be a great fit.

@Hecke29 Do you know symfony?

develth commented 6 years ago

Symfony would be great target, but it's far far away. We have to begin with the symfony components, going step by step, migrate part of pages. That will be a long way with a lot of single steps - because we shouldn't risk a feature freeze or a too huge code change that runs into struggle. IMHO we need a better platform to communicate and for planning

mablae commented 6 years ago

We could use strangler pattern to wrap the legacy app with symfony and then fallback for not yet implemented parts.

andryyy commented 6 years ago

A full blown framework? I don't know. Isn't that too much? mailcow isn't a very large application, that would probably grow its size by factor 10 or something.

develth commented 6 years ago

It will reduce the code size that have to be maintained. And brings a lot of features that mailcow will love :) (the console component, doctrine, database update/ migrations,...)

Hecke29 commented 6 years ago

@mablae I'm developing with symfony on a daily basis. I'm not a full-pro but yeah. @develth I agree. Especially with the communication part. I also think starting to integrate symfony-components is the way to go. @andryyy imho a application can't be too small to use a framework. Especially symfony is basically a set/bunch of other components. I personally also like other abilitys that will open up for this project (e.g. Console Command). Also it's easier to find other developers that will get familiar with the code when you use a framwork

develth commented 6 years ago

Isn't that too much? mailcow isn't a very large application, ...

I even use symfony for small web applications - it saves time, duplicate code and you can focus on your business logic - not on daily code like on how to make a dB query to a obejext to use it later :)

andryyy commented 6 years ago

I'm sure you have much more experience than me. 👍 PHP is not (surprise) my favorite scripting language...

Braintelligence commented 6 years ago

Let's ditch PHP and go Flask/Django then :D

@develth You forgot ditching most of HTTP for websockets with vue/react

andryyy commented 6 years ago

Django? No way.

develth commented 6 years ago

Maybe a little java /spring for performance and vue.js for frontend? 😜 Let's keep it simple

Braintelligence commented 6 years ago

Just out of curiosity, how is Django less simple than Symfony?

develth commented 6 years ago

For the current Project and the current maintainers.

Edit: Wasn´t meant to say django isn´t simple, simple was meant to the project setup - don´t mix too much, keep it maintainable for the people that already work with it and those who will work with it. don´t make a too big changes within the current system

Braintelligence commented 6 years ago

OK, that makes sense.

mhf-ir commented 5 years ago

I think use this will be great:

Roadmap:

  1. Define REST API openapi interface
  2. Write nodejs app
  3. Write integration parts to other services
  4. Develop Admin UI
  5. Develop Mail client :smile_cat: