Suggestion: Usage of Django CMS about basxconnect HOT 3 CLOSED

Hi Joejoe

Glad to hear from you and thanks for bringing this up.

Short answer

basxConnect is a CRM and not a CMS, therefore we will not use a CMS (even though most CMS can be abused to work as frontend for any kind of data).

Long answer

A CRM needs more flexibility in how the system can be customized through a developer and less flecility for the user to define how content should be displayed (like the layout of different page types).

We can see the difference in focus of a CRM when looking at the features listed in the Django CMS github repo. I list them here with my comments in parentheses:

From https://github.com/django-cms/django-cms#features

• hierarchical pages (no needed in a CRM)
• extensive built-in support for multilingual websites (not needed in a CRM)
• multi-site support (not needed in a CRM)
• draft/publish workflows (not needed in a CRM)
• version control (might be necessary, but there other common used django apps which provide this functionality)
• a sophisticated publishing architecture, that's also usable in your own applications (not needed in a CRM)
• frontend content editing (not needed in a CRM)
• a hierarchical content structure for nested plugins (not needed in a CRM)
• an extensible navigation system that your own applications can hook into (necessary but is a not a complicated implementation)
• SEO-friendly URLs (not needed in a CRM)
• designed to integrate thoroughly into other applications (should be the case with all django applications)

My point here is: There are many features implemented in a CMS which are completely unnecessary for a CRM. For example if you look at CiviCRM it basically uses only the user-management functionality from the underlying CMS but has a completely different user interface and a completely different way to store and edit data. There is good reason for this. The few advantages one gains through the use of an existing CMS are quickly lost when customization is necessary. We have to bow and stretch concepts from the CMS even though we could design much clearer custom implementations. An example is that almost all CMS have some type of "page" object. We either never use that type of data or try to make all of our "person", "relationship", etc. types a subtype of a that "page" type. Another central feature is a user-definable menu structure which can be defined by the CRM administrators and editors. In a CRM the users of the system should not have to worry about menu structure but should be presented with the correct menu options according to their permissions and roles. I could go on but I think it is clear what my point is.

Now, if you would like to convince us that there are many useful features inside Django CMS which can be used for a CRM implementation feel free to continue the discussion. One thing for example which I really really envy the drupal guys for is the "views" system. Implementing something similar inside django is a ton of effort and basically a project on its own.

However, I think our ultimate decision will not be changed, mostly because we decided to base our user interface on carbon design and did most of the implementation regarding that already. It would need a lot of convincing arguments before we would decide to drop that or implement it again based on another framework.

In any case, thanks again for reaching out. If I or we can help in getting things up and running let me know. It would be great to get some people try basxConnect.

from basxconnect.

Hi Samideluxe,
thanks for taking the time and the detailed answer.
I totally understand your points, so no worries ;-)

I already executed the get-script to give basx a try but faced a database error. (See my other issue in the other repo)

Thanks again
Joejoe

from basxconnect.

👍

from basxconnect.