how should I organize my project?

1
Hi makers,   We were having an internal discussion regarding organizational best practices and naming conventions, folder structures, module structures and were curious about the things you guys like, or dislike?   I know mendix has a docs page about this, but are there things you do differently? https://docs.mendix.com/refguide/dev-best-practices/   ps: you can also edit the documentation on this page if it is outdated on the github do you do things like: ACT_Create_Student ACT_Edit_Student or ACT_Student_Create ACT_Student_Edit   Is project organization just personal preference? what is the goal? maintainability? readability? who can help me have a meaningful discussion around this?
asked
3 answers
1

We mostly try to adhere to the Mendix best-practices, only adding or adjusting them when we feel it's beneficial.

 

For example, we also use the SUB prefix in microflow as it makes sure there's always a similar order in the microflows for an entity(if you don't use SUB, the ‘sub’ microflows for an entity starting with a ‘AB’ would be on top, while the sub flows starting with ‘ZZ’ would be on the bottom of the list).

Another example is the folder structure. We usually adhere only an Entity Related folder structure. For example a flow ‘SUB_Order_SetStatus’ could be triggered by multiple processes, thus organizing them by process makes it easier to forget to reuse the same logic(an increases the changes of unwanted duplicates). For this same reason we also always organize the documents within a folder to group them by their document type(Microflows, Nanoflows, Pages etc).

 

Adhering to the best practices is really important in our opinion as it makes it much easier to onboard new developers to a project and helps devops to do their work better.

answered
1

My personal preference for folder structures is very similar to the  Mendix best practices. Either Process-Related Sources or Entity-Related Sources. But often we/I use also apply this to the sub-folder structures.

 

Structure

Structure the folders to reflect individual processes and their steps or reflect the entities, a combination is sometimes also possible.

├── _Resources
│   ├── JavaActions
│   ├── JavaScriptActions
│   ├── ScheduledEvents
│   ├── Integrations
│   ├── Constants
├── Entity A
│   ├── Enumerations
│   ├── Microflows
│   ├── Nanoflows
│   ├── Pages
│   │   ├── Native
│   │   ├── Phone
│   │   ├── Responsive
│   │   ├── Snippets
│   │   ├── Tablet
├── Entity B
│   ├── Enumerations
│   ├── Microflows
│   │   ├── Assign
│   │   ├── Complete
│   ├── Nanoflows
│   ├── Pages
│   │   ├── Native
│   │   ├── Phone
│   │   ├── Responsive
│   │   ├── Snippets
│   │   ├── Tablet
└── ProcesStep1
│   ├── Enumerations
│   ├── Microflows
│   │   ├── Assign
│   │   ├── Complete
│   ├── Nanoflows
│   ├── Pages
│   │   ├── Native
│   │   ├── Phone
│   │   ├── Responsive
│   │   ├── Snippets
│   │   ├── Tablet

 

Note 1: that the full folder structure is only necessary if there are many (like 4 or more) from the that type to put in the folder. If there are only responsive pages and no other elements, you can skip the level Pages and make Responsive directly nested under EntityA. If π LogNode and some other constant are the only ones you can put them in _Resources instead of _Resources/Constants. This structure is to guide you in a module with a bulk of documents. Don’t create empty folders and try to avoid folders with only 1 or 2 items.

 

 

Note 2: mixing of Entity-Related and Process-Related is possible as shown. But try to keep it intuitive. If you have an Entity called Task it makes sense that all microflows related to assigning a task are grouped in an additional sub folder as well as microflows related to the completion of task.

 

Modules

Try to keep them focussed on one responsibility (which might be really small like “Notes” or more complex like Planning).


Modules for API's I like to separate in a “Connector” module which just exposes all the API features (like a marketplace connector would) and an “Implementation" module which does the translations/mappings from the internal modules in the Mendix app to the connector (the Implementation module should handle stuff like translating numeric status values received from the API into an human readable format and storing it in a specific entity with relations to internal modules)

 

answered
0

I would prefer student_create over create_student, because you are working with an object / entity and then want to do something with it. So hence I have a student and then want to edit or create one. And for the rest just the Mendix prefixes.

And for the hasInteriorHeight or HeightInteriorHAS discussion. If it is has then it must be a boolean because it either has an heigt or it does not. We always prefix booleans with an underscore so it is inmediately visible that it is a boolean. So in our model it would be _interiorHeight and it would be a boolean.

 

Regards,

Ronald

 

answered