Open develth opened 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.
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...
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 ;)
Hm, we could start with a lot of PHP code fixes/changes. :-)
For sure. Are there open issues regarding those fixes / changes?
No, not really. It is a "start anywhere".
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?
I could help out if you guys decide to not go the PHP route but rather stick to Django/Flask (Python).
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
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.
KISS approach would be best, maybe consider a microframework ? https://lumen.laravel.com/ or the mighty https://laravel.com/
@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?
@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.
@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
I am making the exact transition at work. I am planing these big steps:
Symfony would be a great choice
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
@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?
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.
@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.
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?
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.
@develth irc.freenode.org:#mailcow
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.
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
I would also like to participate, still think Symfony would be a great fit.
@Hecke29 Do you know symfony?
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
We could use strangler pattern to wrap the legacy app with symfony and then fallback for not yet implemented parts.
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.
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,...)
@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
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 :)
I'm sure you have much more experience than me. 👍 PHP is not (surprise) my favorite scripting language...
Let's ditch PHP and go Flask/Django then :D
@develth You forgot ditching most of HTTP for websockets with vue/react
Django? No way.
Maybe a little java /spring for performance and vue.js for frontend? 😜 Let's keep it simple
Just out of curiosity, how is Django less simple than Symfony?
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
OK, that makes sense.
I think use this will be great:
Roadmap:
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