Mendix Intermedium Path PDF

Contenido Unlocking True Collaboration......................................................................................... 5 1. Introduction........................................................................................................... 5 Welcome................................................................................................................ 5 2. The SCRUM Methodology Applied........................................................................... 5 Learning Objectives................................................................................................ 5 Team Values........................................................................................................... 6 Team Size............................................................................................................... 6 Sprint 0................................................................................................................... 7 Scrum Events......................................................................................................... 8 Location............................................................................................................... 12 Summary.............................................................................................................. 12 Knowledge Check................................................................................................. 13 3. The App Directory................................................................................................. 14 Learning Objectives.............................................................................................. 14 Introduction......................................................................................................... 14 Locating the App Directory.................................................................................... 14 The Clean Directory Example................................................................................ 14 Create Dataset..................................................................................................... 15 The Clean Directory Example – Continued............................................................. 16 Optional Files and Folders..................................................................................... 18 Best Practices....................................................................................................... 19 Summary.............................................................................................................. 19 Knowledge Check................................................................................................. 20 4. Using Version Management.............................................................................. 22 Learning Objectives.............................................................................................. 22 Introduction......................................................................................................... 22 Upload an app to a Version-Controlled Repository................................................. 22 History................................................................................................................. 23 Including Snapshots............................................................................................. 24 Conflicts and How to Resolve Them....................................................................... 24 Opening Older Revisions....................................................................................... 25 Using Branches..................................................................................................... 25 Using Your Own Git Server..................................................................................... 27 Summary.............................................................................................................. 27 Knowledge Check................................................................................................. 28 Constrain Your Data Using XPath.................................................................................. 30 1. Introduction..................................................................................................... 30 Welcome.............................................................................................................. 30 2. XPath Basics.................................................................................................... 30 Learning Objectives.............................................................................................. 30 Why do we use XPath?.......................................................................................... 30 Using XPath for Managing Vacation Requests......................................................... 31 Where do we use XPath?....................................................................................... 31 Knowledge Check................................................................................................. 34 3. Using Simple Constraints................................................................................. 35 What is an Enumeration?...................................................................................... 35 Using Mendix System Variables............................................................................. 35 Knowledge Check................................................................................................. 36 4. Using More Complex Constraints...................................................................... 38 What is the UserRole System Variable?.................................................................. 38 What is an XPath Operator?................................................................................... 38 What is an XPath Function?................................................................................... 39 Checking for Empty Values.................................................................................... 40 Knowledge Check................................................................................................. 41 Create an App with Advanced Page Building.................................................................. 42 1. Introduction..................................................................................................... 42 Welcome.............................................................................................................. 42 2. Setting Up the Expenses App............................................................................ 42 Structuring the App Explorer.................................................................................. 42 The Domain Model................................................................................................ 43 App Security......................................................................................................... 43 Team Member Management Pages........................................................................ 43 Knowledge Check................................................................................................. 44 3. Branding.......................................................................................................... 45 Learning Objectives.............................................................................................. 45 Introduction......................................................................................................... 45 Custom Navigation Layouts.................................................................................. 46 Custom Login Page............................................................................................... 47 Knowledge Check................................................................................................. 49 4. Adding Requests.............................................................................................. 50 Learning Objectives.............................................................................................. 50 Introduction......................................................................................................... 50 The Wizard Page Template..................................................................................... 50 The Reference Set Selector................................................................................... 50 Single and Multi-Select on a Data Grid................................................................... 51 Knowledge Check................................................................................................. 52 5. Approving Requests......................................................................................... 53 Learning Objectives.............................................................................................. 53 Introduction......................................................................................................... 53 Working With Popups............................................................................................ 53 Knowledge Check................................................................................................. 55 6. Notifications.................................................................................................... 57 Learning Objectives.............................................................................................. 57 Introduction......................................................................................................... 57 Custom Navigation Menu...................................................................................... 57 Create Notifications.............................................................................................. 57 Display Notifications............................................................................................. 58 Knowledge Check................................................................................................. 59 7. Translating the App........................................................................................... 61 Learning Objectives.............................................................................................. 61 Language Settings................................................................................................ 61 Translation Tools................................................................................................... 62 Add a Language.................................................................................................... 62 Knowledge Check................................................................................................. 63 Building an Event App Using Microflows........................................................................ 65 1. Introduction..................................................................................................... 65 Welcome.............................................................................................................. 65 2. Start Building the Event App.............................................................................. 65 Learning Objectives.............................................................................................. 65 Adding a Feedback Widget.................................................................................... 65 Knowledge Check................................................................................................. 67 3. Setting up a Valid Program................................................................................ 69 Learning Objectives.............................................................................................. 69 Using Sub-Microflows........................................................................................... 69 Increasing the Maintainability of Your App.............................................................. 69 Improving Reusability............................................................................................ 70 Knowledge Check................................................................................................. 72 4. Signing up for the Event.................................................................................... 74 Learning Objectives.............................................................................................. 74 Anonymous Users, Variables, and Functions......................................................... 74 Debugging Microflows........................................................................................... 78 Knowledge Check................................................................................................. 81 5. Informing Your Guests...................................................................................... 83 Learning Objectives.............................................................................................. 83 Sending Newsletters............................................................................................. 83 Scheduled events................................................................................................. 83 Loops................................................................................................................... 83 Aggregate functions.............................................................................................. 84 Batches................................................................................................................ 84 Knowledge Check................................................................................................. 85 Expand Your Domain Modeling Skills............................................................................ 87 1. Introduction..................................................................................................... 87 Welcome.............................................................................................................. 87 Learning Objectives.............................................................................................. 87 2. Building the Base App....................................................................................... 87 Multiple Associations Between Entities................................................................. 87 Knowledge Check................................................................................................. 89 3. Keeping Scores Without Using the Database..................................................... 90 Learning Objectives.............................................................................................. 90 (Non-)Persistable Entities...................................................................................... 90 Calculated Attributes............................................................................................ 91 Knowledge Check................................................................................................. 93 4. Adding Additional Users................................................................................... 94 Learning Objectives.............................................................................................. 94 Cross-Module Associations.................................................................................. 94 System Members.................................................................................................. 95 Knowledge Check................................................................................................. 96 Unlocking True Collaboration In this learning path, we will go into the details of Collaboration and cover topics such as: SCRUM Methodology Applied, a deep dive into the events of your sprints, and take collaboration to the next level; the Project Directory, information about the structure of the Project directory and its relationship to Studio Pro; and using Version Management, the potential of a version management system and why Team Server is recommended for your Mendix projects. 1. Introduction Welcome Hi, and welcome to the Unlocking True Collaboration learning path. It’s great to have you here! Collaboration is key when you’re building apps for your company. By the end of this learning path, you will be able to: Summarize the required team values, roles, and events that are used in Scrum methodology Describe the structure and importance of a clean App Directory List the different options offered by the version management system Explain why it is recommended to use the team server for your Mendix apps 2. The SCRUM Methodology Applied Learning Objectives By the end of this module, you will be able to: Describe the five team values that contribute to agile collaboration List the roles that are involved in software development Explain the responsibilities of each role involved in software development Summarize the importance of actions taking place during Sprint 0 Describe the events that are used in SCRUM methodology Team Values In the module Collaborate with your Team in the Rapid Developer Learning Path, you learned the basic characteristics of the Agile software development methodology. Now we will go into greater detail concerning what happens during a sprint and prepare you to take collaboration to the next level. Naturally, each team needs to find its own drive, but in essence, they should focus on the following 5 values: Focus – As teams begin to multitask, the quality of their work starts to drop, and the time to completion increases. Scrum encourages team members to take on only a few things, thus giving each item the attention it deserves. By breaking the app into smaller Sprints and limiting the flow of work into those Sprints, Scrum helps to focus on each item more tightly. Courage – Because a small, cross-functional team can pool their skills, and because Scrum encourages close collaboration, the team has the courage to take on greater challenges than they would as individuals. Openness – This is one of the most important values of the Scrum framework. Scrum teams can achieve openness through regular reviews with stakeholders and regular planning and communication with their peers. Commitment – Scrum teams commit to always delivering the highest quality of work possible, always being transparent about the true status of each item with stakeholders. Also, Scrum teams commit to a specific amount of work being done in each Sprint. This commitment builds trust with the stakeholders. Respect – Respect in a Scrum team is important to enabling openness in communication, so each team member feels safe to share their impediments, and the team can help each other with these impediments. As you engage in a real project, you’ll build people knowledge, contribute to building a team spirit, deliver successful projects, making customers successful, but don’t forget to have fun and enjoy the work you do! Team Size In contrast to the Waterfall development methodology where large groups of people work on long-term projects, the Agile methodology instead requires forming a small, cross-functional team to build an app rapidly. It may surprise you that a typical Agile team capable of developing a small app consists of only three people! A team needs a Product Owner who will be translating business needs into app backlog items and prioritizing them. The actual development work can be handled by the other two developers, called Business Engineers in Mendix. At the same time, the duties of the Scrum Master will be assigned to the lead developer. Having such a small team keeps communication lines short and makes collaboration more effective. This does not mean that larger teams are not effective, just that larger teams require more coordination and very clear communication agreements. Depending on the technical challenges the team is facing in their app, it may be necessary to involve Subject Matter Experts (SMEs). Note that SMEs are not accountable for product delivery; that is solely the responsibility of the core Scrum team, specifically the Product Owner. Another situation where the team may get larger is when a company aims to start developing multiple apps. This requires more development power. Thus new rapid developers can join an already existing team to help and gain more experience. Once they’ve grown experienced, most likely they will then join a smaller team. Sprint 0 Before a Scrum team can start developing, they should familiarize themselves with the app. It is important that everyone gets an overall picture of the app, the organization, and the people involved. The team should also have an official kick- off meeting and an initial Product Backlog Refinement meeting. These are conducted to ensure that the user stories taken into the first sprint are in a ‘ready’ state, meaning that they can be executed by the developers of the Scrum team. The period of one or two weeks preceding the first sprint is called Sprint 0. It is not an official Scrum event, but is still necessary to prepare the team for development work. At this starting point, the whole team gets to know each other better. The Product Owner and other stakeholders share information about the organization and the app’s requirements. It’s important to understand the overall picture so you have enough context to understand exactly what needs to be created. Once the team composition is clear, the Scrum Master ensures that technical challenges requiring additional skills are identified, for example UX/UI, integrations, IoT, Big Data, etc. To address these challenges, the Scrum Master books the availability of necessary SMEs. Since SMEs support multiple apps, it’s important to preserve their availability for the particular sprint where they’ll be needed. The Scrum Master looks several sprints ahead and makes a forecast of required capacity and skills, including holiday and availability planning. They also make the SMEs’ contact details available to the team and reserve their availability to answer questions if needed. During sprint 0, an official kick-off meeting takes place. During this meeting, all involved parties formalize the agreements, make clear who is responsible for what, and discuss dependencies. Creating transparency and clear collaboration agreements is the prerequisite for the app’s success. Finally, make sure to conduct the Product Backlog Refinement meeting to make it clear which user stories will be accomplished during the first sprint. You will learn more about these expectations for this meeting later on in this module. Scrum Events The Agile process involves several events. Each of these events has a dedicated goal and takes place in a specific order. The main purpose of these events is to have a coordinated way of clarifying business requirements, planning their implementation, monitoring the current progress, gathering required feedback, and making improvements. The five Scrum events are: Sprint Planning Sprint Daily Stand-up Sprint Review Sprint Retrospective In addition to these events, the team also performs Product Backlog Refinement. This is not an official Scrum event, but just like other listed events, this refinement happens before the other events. This is because before working on any user stories, the team needs to know what to work on! Each of the events requires specific inputs and delivers several outputs. The example agenda below shows an outline of a typical schedule for a two week Sprint. Planning the schedule of these events in advance is helpful to ensure that all stakeholders can allocate time in their own schedules. In this planning, you see that the events occur at the beginning or end of a day. This maximizes development time and improves focus. A Sprint starts with the Sprint Planning to kick off the upcoming two weeks. Then, on a daily basis, the Scrum team gathers for a Daily Stand-up. This meeting lasts for only fifteen minutes and is planned in the morning to allow the team members to plan any collaborations during the day. At the end of the second week, the Sprint Review and Sprint Retrospective meetings are organized. They are aimed to reflect on the product as well as on the process itself. The Backlog Refinement is the only meeting that happens in the middle of the week. In case of highly volatile requirements, it might be necessary to revisit the Product Backlog on a weekly basis. This allows the Development Team to better anticipate upcoming changes. Product Backlog Refinement The meeting cadence starts with the Product Backlog Refinement meeting. The goal of this meeting is to reach a mutual understanding of user stories selected from the Product Backlog. This alignment is required because the Product Backlog can be changed by multiple people. What you want to prevent is different parties interpreting stories in different ways. During this meeting the backlog stories can be clarified and the PO will reorder the backlog if needed. While assigning priorities to backlog items, the PO also takes into account the needs and wishes of stakeholders. But most importantly, the PO focuses on the business value each user story will be leveraging. It’s important to prioritize the items from top to bottom, ensuring that top items are addressed first. Also it’s important to ensure that the team has refined the number of stories sufficient to fill up not one but two upcoming Sprints - this way, if any stories must be dropped, there are “emergency” items the team can work on so time is not lost. The product backlog refinement meetings require the attendance of the developers, the PO, and sometimes necessary SMEs. The developers may challenge the PO to clarify the technical requirements to come up with a clear overview of user stories and corresponding tasks. Remember during the RAD training when you learned to estimate the complexity of user stories by assigning Story Points? Story points are generally based on the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.) to make their differences more clear, and they represent the effort it will take to implement the user story. Note that ‘effort’ does not exclusively mean time, development hours, or money. It is a holistic evaluation of how difficult each story is compared to the others, and each story is assigned a value via discussion by the entire team. As the whole team needs to come to an agreement in regard to the story points assigned to a user story, sometimes opinions regarding the user story complexity differ. “Planning poker” is a tool that can be used to accurately get everyone’s opinion, where team members take a blind vote by revealing playing cards to avoid anchoring bias. Team members with unusually high or low scores can explain why they think a given user story is more or less challenging. Perhaps they missed a critical fact in their assessment. Perhaps they are the only one who noticed a critical fact! Maybe they’ve done this exact task before and can complete it themselves very easily. The most important thing is to come to an agreement on how challenging the story will be for the team to complete. Although the number of story points assigned is determined by the details of the user story and acceptance criteria, these weights may evolve over time. As the team becomes more experienced, the team’s velocity will increase, and certain challenges will become less difficult in the long term. At the end of the Product Backlog Refinement meeting, the team should have prepared and prioritized enough user stories for the upcoming sprint. The output of this meeting serves as the input for the Sprint Planning meeting. Sprint Planning Sprint Planning is a collaborative process involving the Scrum Master, the Product Owner, and the entire Development Team. The Scrum Master is there to facilitate the meeting and take note if any SMEs need to be engaged. The Product Owner is responsible for clarifying the details of the Product Backlog items and their respective acceptance criteria. The PO ensures that questions that were not answered during the Product Backlog Refinement meeting are addressed. The Development Team defines the work and effort necessary to meet their Sprint commitment. During sprint planning is when the Definition of Done is determined. This is an agreement between the development team and stakeholders (and anyone else involved) concerning what exactly is required for a user story to be considered ‘Done.’ In most cases this will involve deciding how much testing is required or who needs to be involved in the decision. Can the business engineer who worked on the story move it to Done as soon as they are finished? Or does the functionality need to undergo multiple rounds of regression testing and a demonstration to the stakeholders to be considered finished? Everyone should be on the same page when a story is marked Done. The Product Owner ensures that the Development Team has a clear goal during the Sprint. During the Sprint Planning, the Development Team decides which user stories will be selected for the given Sprint. By defining this scope, the Development Team commits to accomplishing the selected user stories with high quality by the end of the Sprint. The team Velocity is the factor that determines how much a team is capable of accomplishing during one Sprint. Knowing the team velocity allows the team to more precisely estimate how many user stories they can cover in the next Sprint. Changing the team composition can also impact the team velocity. Sprint Review At the end of the Sprint, the Scrum Master organizes the Sprint Review. This event is aimed to demonstrate the result of the Sprint to the Product Owner, Management, and stakeholders. When reviewing the product, the starting point is the Sprint goal, where the scope has been set to address a set of user stories. During the demo, the acceptance criteria are used to check whether the presented increment satisfies the Definition of Done. Feedback received from the PO and stakeholders may result in new user stories added in the next Sprint, or the Product Backlog may need to undergo some adjustments. The result of the sprint review is a set of potential new backlog items that are approved by the PO. Sprint Retrospective After the product increment has been reviewed by the Product Owner, it’s time for the Scrum team to hold a Retrospective. Retrospective meetings are typically held at the end of each Sprint or at the end of a major development cycle and are critical to optimizing team performance. This meeting involves just the Scrum team, not any of the stakeholders. During this meeting, facilitated by the Scrum Master, everyone gives feedback about what went well in the last sprint or what needs to be improved. Such a meeting may take up to 1.5 hours. It’s a good opportunity to reflect on the process, people, and organizational aspects of the completed Sprint. Remember the team values? This is where Respect comes into play. The Scrum Master needs to create an environment where every team member feels comfortable sharing their feedback. Every member should be able to share their honest opinion with respect to the rest of the team. There are several things that can be evaluated during this meeting: What did go well, and what should you keep doing? What did not go well, and how can it be improved? What are new things that a team member should start doing, and why? The most common pattern is that each team member lists five items per category. Then by voting, the team can decide which three improvement points will be included in the process of the new Sprint. One of the common pitfalls here is an attempt to change too much at once, which won’t lead to the desired process. Every improvement point is the responsibility of the whole team, but each must have an owner to keep an eye on this specific point. Daily Scrum In the Daily Scrum, the team members share their progress with the rest of the team. This is typically attended by the developers, but the PO is also welcomed. Every developer shares the following three things: What have I done since the last daily scrum? What am I going to do until the next daily scrum? What are things holding me back, my impediments? This meeting is sometimes called the “daily stand-up”, because holding a meeting where everyone must physically stand winds up being short, and thus must be efficient. To ensure that stand-up meetings do not exceed the dedicated 15 minutes, it’s important to address some rules for holding such a meeting. The goal of this meeting is not to report to the Scrum Master, but allow everyone an overview of what everyone else is doing. This meeting is not aimed to elaborate on solutions or to solve issues but to inform others if you need their input or help. In addition, the team will usually look at the list of items planned versus items done (usually called a burndown chart), which measures the amount of work completed versus the total required by the end of the Sprint. Location For Mendix apps, we recommend working in a single place so you have short communication lines with the team and stakeholders. Physical co-location allows for a Scrum room with a scrum whiteboard so that anyone interested can view the current status of the project. In conditions of virtual collaboration, it is the responsibility of the Scrum Master to create and update a digital Scrum board, make it accessible to all relevant stakeholders, and organize regular virtual meetings to facilitate the Scrum events. Collaboration across multiple time zones requires an offshoring approach to Scrum. Offshoring makes some things more complicated due to different native languages and time differences. When planning the availability of SMEs located in different time zones, the Scrum Master should keep an eye on potential delays. Summary In this module, you have learned about the responsibilities of roles involved in the app development. You’ve learned that you need to prepare for development by holding a sprint 0 and structuring the development process by organizing and conducting all Scrum events. Also, you’ve learned about team values, team collaboration, the optimal team size, and the preferable location of team members. Note that these are suggestions on how to organize your app based on Mendix practices. However, you may adjust it to the context of your app and team, though it’s important to keep everyone involved informed, engaged, and efficient! Knowledge Check Question 1: Which event is performed at the beginning of the sprint? Sprint review Sprint retrospective Daily scrum Sprint planning Question 2: What happens in the daily scrum? Team members chat about non-work subjects to decompress. Development progress is presented to the stakeholders. Instructions from the scrum master are delivered. Team members share their progress, plans, and issues. Question 3: What do Story Points associated with a user story indicate? The number of tasks in the user story. The difficulty of the user story. The velocity of the team. The priority of the user story. Question 4: During which of the Sprint Events does the development team determine user stories that will be finished in the sprint? Daily Scrum Sprint Review Sprint Planning Product Backlog Refinement 3. The App Directory Learning Objectives By the end of this module, you will be able to: Locate the App Directory Describe how a clean App Directory is structured Explain how the contents of the App Directory relate to the different parts of your app in Studio Pro List the best practices to keep the App Directory clean and up-to-date Introduction When you start a Mendix app from Mendix Studio Pro, you need a couple of files and folders that combined form the resources of your app. Without them, the Mendix app wouldn’t work. You may have never looked at them because Mendix generates them all for you. All you have to do is to select a location on your local hard drive where you want to keep these resources, and you are ready to start building these awesome apps. But have you ever had some questions on how this App Directory is structured? Wondered what these files are needed for? Or maybe even run into issues due to misuse of the directories? This is the time to get the first glance! Locating the App Directory Let’s start by creating a new app! Open Studio Pro 10.6.0 and create a new app. Use the Blank Web App template. Once the app has opened in Studio Pro, you can immediately find its App Directory! Even if you’ve forgotten what location you set as your app directory, Studio Pro will guide you to it. You can open the App Directory by opening the App menu and selecting the option Show App Directory in Explorer. This will open your Windows Explorer and show the files and folders belonging to this app. Now that you have found the directory, it is time to investigate and learn to understand its structure. The Clean Directory Example A ‘clean’ version, (i.e. a new app that is opened for the first time) of an App Directory looks like the image below. Javascriptsource Within the javascriptsource folder, you will find a structure that resembles the structure of your app modules, but only the modules in which actual JavaScript actions are defined for nanoflows. This helps to easily find all JavaScript sources belonging to that module and eases the reuse of this module in another app. Javasource Within the javasource folder, you will find a structure that resembles the structure of your app modules. It contains all java sources belonging to microflows. In our new app, we have 9 modules, that are reflected in the directory after the app has been run at least once. If you don’t see all of them, try running your app locally to make them appear. Note: Sometimes, you can find other folders on this same directory level with subfolders that lead to third-party java files, implementing custom code. Think of Apache libraries. If we now zoom in on one of our module folders, e.g. system, we see that we have the following structure. Actions The actions folder is the destination folder for all java actions created in that specific module. This is something you do in Studio Pro. The only file that currently should be in there is VerifyPassword.java. It is the single java action currently in the System module. See the image below or your own app for verification. Datasets If you now switch to the myfirstmodule javasource folder, you will see the following: The datasets folder is the destination folder for all data sets created in that specific module. This is also something you create from within the Studio Pro. Currently, the folder should be empty, but we could create a data set file and select Java action as its source to verify that it is also created in our directory. When selecting OQL query as its source, you will not see a file for this dataset in the directory since the OQL code is maintained in your model. Note: Our goal here is not to teach you what a data set is but just how the App Directory is structured. Explanation about data sets will be handled in another learning path. Nevertheless, we will demonstrate how to create a data set using another module as an example, as the System module is read-only. Create Dataset Let’s try creating a dataset in Studio Pro so you can experience how it’s done! 1. In the App Explorer, right click on MyFirstModule, and create a new data set. Click Add other>Data set. 2. Name it EnrolledCandidatesReport. 3. Change the Source to Java action. 4. Run the app locally to update the app directory. 5. Now you should be able to see the file in your app directory: …\javasource\myfirstmodule\datasets The Clean Directory Example – Continued Let’s elaborate further on the current App Directory folder structure in javasource\system shown below: Proxies If we now switch back to the directory of the system module and look into the content of the proxies folder, we see that we have one folder called microflows, a folder called constants, and a number of files. The proxies folder represents all the entities, persistent and non-persistent, and all enumerations. The inner microflow folder has only one file named Microflows.java that stores all microflow names of that module. This is to accommodate for java development. Resources Moving back up to the main app directory, let’s consider the resources folder. Here you should only find files, like HTML files or configuration files, that have a direct effect on the way the application works. It will be packaged together with the app model. The files in that folder can be accessed as java resources. Examples of Mendix Modules that make use of this folder are the SAML module and the Deeplink module. Theme In the theme folder, you will find files and folders that together form the source for the styling of your application. Changes in this folder require HTML/CSS/SASS knowledge. With this knowledge, you can extend or change existing design properties, or create new ones. Userlib In the userlib folder, you will find the java libraries that could be supporting your custom java functions. The content of this folder changes once you download modules like the Community Commons Function Library or Email module with templates. Please don’t make any changes to these files, unless you won’t be using the downloaded functionality anymore. When you uninstall a module, the Java libraries will not be automatically removed from this directory, so don’t forget to remove them manually. Widgets The widgets folder contains only files that have the extension.mpk. These files reflect the widgets available in Studio Pro. The number of widgets listed in your Add-on widgets grouping can differ from the number of files in your app directory. This is because a.mpk file can reflect multiple widgets. An example of that is the Charts.mpk that includes an Area chart, Bar chart, Bubble chart, and a few other charts. Again, make changes to these files only when you know your way around building widgets. This requires knowledge of the Mendix APIs and JavaScript. Files in this folder Next to the items on the highest level (root folder), your App Directory has the following files:.mpr: The.mpr file, required by Studio Pro to open the app..mpr.bak: The.mpr.bak file is a backup file for your.mpr file. The backup can be used to restore your app in case something goes wrong. The two moments when this can happen are an upgrade of the Mendix version or an update of the Team Server app..mpr.lock: The.launch file This is a file needed for Eclipse to import your app into this application. Best Practices Keeping your App Directory clean and up to date is very important! Because the content of this directory changes as the result of your actions, be aware of which modules and widgets you have added and timely remove them from the App Directory if not used anymore. 1. When you uninstall a module, make sure to remove the Java libraries manually from the userlib folder. 2. The content of the resources folder is copied to the model/resources folder in your deployment folder. Any files that cannot be added to the deployment folder can be added to this resources folder. 3. If you are using version management, which will be explained in the next module, make sure that before you commit, you update your app to check for new functionality and resolve any conflicts. Summary In this module, you have learned how the App Directory of your Mendix app is structured, how it relates to the content of your app in Studio Pro, and what actions result in the content of the App Directory being modified. Make use of this knowledge to keep your App Directory clean and well structured! Knowledge Check Question 1: Which folders contain source information tied to a specific module enabling reuse of this module in another app? Only Javasource folder Only Javascriptsource folder All folders within App Directory Javascriptsource and Javasource folders Question 2: The VerifyPassword.java file in the System module is stored in which of the JavaSource sub-folders? Root folder Datasets Proxies Actions Question 3: The Microflows.java file is stored in which sub-folder of JavaSource directory? Proxies Datasets Root folder Actions Question 4: Which of the following sources are typically stored in the Resources folder of the App Directory? Datasets Microflows and constants Proxies Configuration files, HTML and Java files Question 5: Files and folders that form the styling of your application are typically stored in which of the following folders? Theme JavaScript Resources Userlib 4. Using Version Management Learning Objectives By the end of this module, you will be able to: Upload an app to a version-controlled repository Access the history of an app and see all changes applied to the app so far Describe the different types of events you can find in your app history Share local data with your team members Resolve app conflicts Open older app revisions Prevent conflict situations Work with branches Use your own version control server Introduction In the previous module, you learned the structure of the App Directory. Understanding how version control works in Mendix is just as important! Mendix offers includes a version management tool right out of the box called Team Server. Team Server makes use of Git to handle the back end, and it allows you to keep track of all changes made to your app. Using this tool, you can share your work with team members or revert to an older version. In this module, you will learn: How to share local data with your team members How to resolve app conflicts How to prevent conflicts How and when to work with branches How to use your own version control server Upload an app to a Version-Controlled Repository When you start a new app in Mendix, the system automatically suggests creating a repository for your app. Apps, which are not under version control yet can be connected to the version-controlled repository at any time. This can happen when you reuse another app or create a copy of an existing one. In this case, Mendix offers you the option Upload to Version Control Server, which can be found under Version Control. History The history of apps allows you to view the changes applied to the app so far. Based on these changes, you can choose a point to which you want to revert your app in case you need to undo some of the newly added functionality. You can view the history from within the Mendix Portal or Studio Pro. In the Mendix Portal, from the app page, navigate to General > Team Server, and you will be able to see the following four types of events: Commits Created tags Created branch lines Deleted branch lines. Note: A tagged version is a revision that has been used to build a Mendix deployment package. Per line, you will see: A descriptive message The date and time of the event The name of the actor who has triggered the event The Studio Pro version used (For tag events, we do not show the Mendix Studio Pro version) The related user stories Within Mendix Studio Pro, if you navigate to Version Control > History…, you will be able to see the following two types of events: Commits and created branch line. Per line, you will see: The revision number A symbol, indicating the type of change The author of the event The date of the event The time of the event The message of the event The related user stories The changes in the model The changes on disk (repository) As you can see, there is a little difference between the two overviews of the history. This is because you are simply viewing the same events from different points of view. Including Snapshots Mendix has its own default database that you can use for your local deployment. In this way, you are not dependent on an external database but can use this built- in database to test and run locally. What you might not know is that you can share your database with your team, so they can also test the app using your dataset. This will save their time and will help to reproduce any behavior you encounter. To create a snapshot of your data with Mendix Studio Pro, navigate to the Version control menu: Version control > Add a snapshot of your data. This creates a snapshot of your data and adds a zip file (data-snapshot.zip) to the deployment directory of your app. The next time you will commit, the whole team can use this database by unzipping this in the designated deployment folder. Conflicts and How to Resolve Them When you are working together on an app, various types of conflicts can emerge that you have to resolve before committing new changes to the Team Server. These conflicts can be related to your model (document conflicts, e.g. pages, microflows, etc.) or to other documents that are part of your repository (app conflicts). We will now focus on the document conflicts. Within your application model, you can open changes dock, which lists changes you have made to your local working copy since the last update. Once you update your local working copy with the online version, the changes made by your team members will be downloaded to your local version. In case your team member has been working on the same document (e.g. a page or a microflow), Studio Pro will identify a conflict indicating that there is a mismatch between the downloaded and locally stored document version. You need to resolve this conflict before you can commit, as Studio Pro requires all commits be conflict-free. At first, identify the differences between the newly updated and your local app versions. Connect with the team member who made changes on the conflicted documents and decide together which version of truth should be used. To view both versions of the conflicted document, e.g., microflow, you can create a copy of your own document in Mendix Studio Pro, but choose ‘Resolve using theirs’ which will replace your original document with their version. Then you’ll have both in your app explorer to examine. Now you know that conflicts can occur and how to fix them, but how can you prevent them in the first place? Let’s first check out which type of changes can cause these conflicts. There are two main types of conflicts, a modify – modify conflict, and a modify – delete conflict. The modify – modify conflict occurs when you and another team member modified the same document. For instance, renaming the same label of an input field on a page, setting the module role access for a page, changing an activity in a microflow, or changing entity access rules for a module role in the domain model. The modify – delete conflict occurs when you are changing an element that someone has removed. For instance, renaming/deleting a column in a DataGrid, making changes to a microflow while someone else has deleted the microflow, or renaming an association that was deleted by someone else. Next to these main two, you can also get conflicts when adding the documents with identical names (pages, microflows, and other documents) or when importing the same Marketplace module. The best advice to prevent these conflicts from happening is to make agreements with your team members. Perform regular updates and commits, separate work, and agree upon a domain model foundation at every sprint. Opening Older Revisions Mendix Studio Pro keeps track of all app revisions and saves them automatically. This allows you to open an old version of the app if needed. You might want to open an older version to identify the differences between two revisions of the model or because you want to debug a revision that is published in a live environment. To open an older revision, you need to create a branch from that revision, then you can open that branch in a new Studio Pro session. Make sure to only use this branch for viewing and analyzing purposes, and don’t make changes to this branch since you already have a number of commits done after that revision. Using Branches Once your app has been deployed to a production environment, it will be useful to know how to create a branch. That will allow you to continue with development of new functionality without affecting the running production app. It is also best practice to separate hotfixes from the development of new functionality. You don’t want to push hotfixes together with features that have not been completed yet. Let’s have a look at the possibilities that come with using branches. Create a branch Creating a branch can be done in Studio Pro by going to Version Control > Manage branch lines. You have three possible ways to create branches: Revisions of the main line Revisions of another branch line Tagged versions Merge changes Port fix (only available on main line) The port fix gives you the option to move certain parts from one of your branch lines to your main line. This might be useful when moving a single feature from your branch into production. When choosing the features you need, you have the option to select one or multiple revisions. In line with Mendix best practices, this option is not often used since we advise moving only complete branches. Merge feature branch (only available on main line) This function is used to merge a complete branch into the main line and is only available on the main line. Typically, you merge a branch line into the main line when the development on the branch line has been completed. To start this merge action, open your main line in Studio Pro using Version control > Merge Changes Here. Note: Make sure to commit all your changes on your main line before merging. Select the feature branch you want to merge into your main line. Once selected, the changes applied to the branch line will be listed in the changes dock. This is to indicate the difference between the version on the Team Server and your local version. After committing these changes to the main line, you have successfully merged the branch into the main line. Advanced merge (available on main line and branch lines) The advanced merge option allows merging various revisions of the main line or branch line to the selected type of line, respectively. Reverse merge changes In some situations, you might need to go back to an older version of the app and revert the changes made. For this, you need to indicate the start version and the end version that will be used to revert the changes. You can roll back multiple commits in one go, but you can also choose to revert only a single commit by choosing the same revision for the start and end revision. Delete a branch After a branch has been merged to another branch or the main line, you may want to delete the original branch line. Cleaning up unused branches helps to stay in control over your branches. You can delete branches by selecting the branch under Manage Branch Lines and selecting Delete. Using Your Own Git Server By default, Mendix takes care of the provisioning of a version control environment when you enable Team Server. This helps you to stay in control whilst not being bothered by daily back-ups and operational handlings focused on maximized uptime. It is also possible to store your app deployment directory. In order to do this, firstly, you first need to have set up your own Git server. Secondly, in Studio Pro, you need to Enable private version control by going into Edit > Preferences > Version Control > Enable private version control with Git. Lastly, for an additional option in the Version Control menu > item Upload to Version Control Server that will become available to you, now you will be able to use the Private server option. Here you can enter the address of your repository to finalize the configuration. Summary In this module, you learned the different options offered by the version management system. Also, you have learned why it is recommended to use the team server for your Mendix apps. Knowledge Check Question 1: When working in an app with version control, which concept would you use to share your database with your team? By creating a dataset. By creating a data snapshot and adding it to the deployment directory of your app. Simply by committing the app to Team Server. By exporting a app package and sharing it with your team. Question 2: What type of conflict occurs when you and your colleague both modified the microflow implementing the delete behavior? Delete-Modify Modify-Modify Modify-Delete Delete-Delete Question 3: What is a tagged version? A revision of the main line. A revision that has been used to build a Mx deployment package. A revision of another branch line. A branch created from the current app revision. Question 4: Which function is used to merge a complete branch into the mainline and is only available on the main line? Port fix Advanced merge Merge feature branch Quick fix Question 5: Which of the below mentioned options can be used to merge revisions into and from all lines, main line or branch line? Quick fix Port fix Merge feature branch Advanced merge Constrain Your Data Using XPath 1. Introduction Welcome Welcome to the Constrain Your Data Using XPath learning path! By the end of this learning path, you will be able to: Describe the function and importance of XPath queries Constrain data by writing XPaths with attribute values and associations Retrieve and display data related to the current user and context objects Utilize operators, functions, and variables in XPath equations Compare dates and times with XPath 2. XPath Basics Learning Objectives By the end of this module, you will be able to: Explain the form and function of XPath queries Identify the locations where XPaths can be added in Mendix Studio Pro Recognize the elements that make up an Xpath Describe how Mendix can assist you when constructing XPath constraints Why do we use XPath? XPath is the language Mendix uses to navigate the domain model when interacting with data. XPaths provide a written way for developers to get specific data they would like to see. Instead of seeing all data on the screen at one time, XPaths provide a way for us to Constrain our data using entities, attributes, associations, and variables. For example, if a user has ordered products from a website, XPath can be used to access the Mendix database and retrieve information about the user’s orders and the products they ordered. This enables a Mendix page to display a list of those specific products. XPath is a written syntax that specifies relationships between data properties. Mendix uses XPath over similar syntaxes like SQL or OQL because of its database universality and ease of use. XPath meshes seamlessly with the association and attribute structure of the domain model, making queries understandable at a glance. Intelligent applications require thoughtful data presentation. As a result, XPaths are used in nearly every Mendix application. Now that you know why XPath is important, let’s see how it could be used in a specific use case. Using XPath for Managing Vacation Requests As you have seen in lecture 1.4, you will work on a use case throughout this learning path. You will create a Mendix app to manage how vacation requests are submitted, reviewed, and approved. Here is what the app needs to accomplish: Employees should be able to create vacation requests, while managers should be able to approve the requests of their direct reports. Secure data is critical, so you will have to ensure employees can only see their own requests. Managers should only be able to manage the requests of their direct reports. An Administrator should be able to see the requests of all employees and managers. They should also be responsible for assigning the manager who is responsible for approving each request. Where do we use XPath? XPaths are used throughout the Mendix platform to control the flow of data from the database. Almost every location where data is retrieved from the database can take advantage of XPath queries. In most cases, the XPaths are written in a window labeled XPath Constraint. XPaths on Pages Constraints on list widgets such as Data Grids and List Views let you define which items are shown. Note: This may look different on your Studio Pro as the default is Structure Mode. This course and all screenshots are shown using Design mode. Constraints on Reference Selectors let you define which Selectable objects are visible to the user. For example, when selecting a ‘Product’ for an ‘Order’ using a Reference Selector, you can use the XPath Constraint to ensure that only specific products appear in the list. XPaths in Microflows XPaths are used in microflows in the ‘Retrieve’ action to define the data that is returned from the database. XPaths in Security XPath constraints can be added to Entity access rules in the Domain Model security configuration. Now that you know where Mendix XPaths are used, follow the next lecture to learn how they are structured. How to structure an XPath In the previous lecture, you learned where in Mendix you can use XPath. In this lecture, you are going to learn about the elements that make up an XPath. XPath statements follow a specific syntax that must be followed for correct interpretation by the Mendix runtime. XPaths refer directly to the Domain Model and can refer directly to Entities, Attributes, and Associations. XPath constraints also feature the following structural elements, called tokens. Now that you know how to structure an XPath, let’s have a look at how Mendix can help you do so. How Can Mendix Help You? The Mendix platform can assist you when constructing XPath constraints via the auto-completion option. When typing an open bracket [ or slash /, the auto- completion functionality opens automatically. You can also access auto- completion by pressing CTRL+Space. This is especially convenient when you lose auto-completion due to mistyping or clicking elsewhere. Here are some things to keep in mind when making XPath constraints: 1. Identify the entity that you are retrieving in the Domain Model. 2. From that entity, identify the path to the attributes and/or associations you want to use to constrain your data. 3. Construct the XPath expression using the building blocks above. Tips to make your life easier: 1. Know your Domain Model. If you are not familiar with the domain model structure, it can be difficult to choose the right path. 2. Have a well-organized Domain Model. Understanding your entities, associations and attributes is key for easy XPath construction and readability. a. Entity and Attribute names should describe what they represent and not have a technical name. b. Use singular names for entities, for example, Customer instead of Customers. c. Make association names unique when you have multiple associations between the same entities. For example, VacationRequest_Account and VacationRequest_Account_2 don’t explain the difference between the associations. VacationRequest_Submitter and VacationRequest_Approver do at a glance when reading XPaths. 3. Splitting your screen with the Domain Model and XPath editor on either side can help you figure out the correct path. That’s a lot of new information! In the next section, you will see a summary of what you’ve learned before diving into the exercises. Summary In this module, you learned the basics of XPath, including its purpose, how to build a path, and where they are useful in Mendix Studio Pro. In the next module, you will apply these lessons to your vacation request application. Knowledge Check Question 1: Where in Mendix Studio Pro can you configure XPaths? Navigation List Views Text widgets Page access rules Question 2: Which Widget feature utilizes XPaths? The tab index of a Group Box Selectable data constraints on Reference Selectors Dynamic text in Labels Styling properties of Action Buttons Question 3: Where can you utilize XPaths in microflows? In the input parameter In the ‘Open page’ action In the ‘Commit’ action In the ‘Retrieve’ action 3. Using Simple Constraints What is an Enumeration? An Enumeration is an attribute with a pre-defined list of string values. They can be selected with in a dropdown or from a radio button and they make it easy to keep data consistent. On the database level, enumerations are simply strings. The Mendix platform will provide assistance when creating XPaths with enumeration values. Using Mendix System Variables In addition to auto-complete enumerations, the Mendix platform has a number of system variables that can be used in creating XPaths. These include references to the current user, their user roles, the current session, and a number of dates and times to give you greater control over your data. These variables always begin with the characters '[% and can be found using the ctrl-space auto complete menu. Two of the most useful system variables are the '[%CurrentObject%]' and '[%CurrentUser%]' variables. Note: For a complete list of the XPath variables, see the XPath Keywords and System Variables reference material. Current Object The '[%CurrentObject%]' variable represents the unique identifier of the current context object. In practice, this means for a Data Grid contained within a Data View, '[%CurrentObject%]' represents the object of the Data View. The object of the data view is known as the Context Object. If there is no context object, then this variable will not appear in the auto-complete menu. Current User Like CurrentObject, the Mendix platform provides a quick way to refer to the current user of the application. This is accomplished through the '[%CurrentUser%]' variable which can be found in the ctrl-space dropdown menu. '[%CurrentUser%]' is available in all locations where XPaths are used. This is also useful when creating security constraints, and we will take advantage of this to secure our app. Note: Do not use the '[%CurrentUser%]' variable in system processes like Scheduled Events and After Startup microflows. There will be no User at that time! Knowledge Check Question 1: How do you begin typing an XPath? < ( [ ' Question 2: If you want to open the XPath auto-complete menu, you need to press: Ctrl + Space Ctrl + O Shift+Space Ctrl + Shift Question 3: Say you are writing an XPath in a Retrieve action for the VacationRequest entity in a Microflow. If you write in the XPath window [Status = ‘Cancelled’], what will be returned? A new list of requests where the Status will not be ‘Cancelled’. A new object with Status = ‘Cancelled’. A list of all requests with the status set to ‘Cancelled’. A list of all requests except the ones that are cancelled. Question 4: Say you are writing an XPath in a Retrieve action on the VacationRequest entity in a Microflow. If you write in the XPath window [VacationRequest.VacationRequest_Submitter='[%CurrentUser%]'], what will be returned? The earliest Vacation Request that the current user has submitted. A list of all the vacation requests submitted by the current user where the status is ‘Approved’. A list of all vacation requests submitted by the current user. A list of all the vacation requests submitted by the current user that have yet to be approved. 4. Using More Complex Constraints What is the UserRole System Variable? In the previous module, you learned about the Mendix XPath variables for '[%CurrentObject%]' and '[%CurrentUser%]' tokens. You also learned about the assistance the platform can provide when constructing XPaths with enumerations. You combine both these techniques when you constrain Accounts using their User Roles. When you create a User Role in the Security document of the App Explorer, the platform will automatically create a System Variable that can be used when constructing XPaths. This variable will contain the name of a User Role such as '[%UserRole_Manager%]'. The variable will only appear in the auto-complete when the XPath ends with an association to the UserRole entity in the System module. This association is useful when constraining Account selections to a certain type of user. In the next lecture, you will use this functionality to let users pick approvers for their vacation days. What is an XPath Operator? In prior modules, you performed simple retrieves on single equivalency statements. The Mendix Platform, however, contains the ability to perform complex, multi-part statements using operators. The available operators are: = Equal to price = 9.80 true if price is 9.80, false if price is 9.90 != Not equal to price != 9.80 true if price is 9.90, false if price is 9.80 < Less than price < 9.80 true if price is 9.70, false if price is 9.80 9.80 true if price is 9.90, false if price is 9.80 >= Greater than or price >= 9.80 true if price is equal to 9.80, false if price is 9.70 or Or price = 9.80 or true if price is price = 9.70 9.80, false if price is 9.60 and And price = 9.80 and true if price is 9.80 amount = 1 and amount is 1, false if price is 9.70 and amount is 1, false if price is 9.80 and amount is 2, false if price is 9.70 and amount is 2 These constraints must always be used as part of a valid expression. The Mendix XPath editing window contains a built-in error checking mechanism that will alert users of any issues with the query as written. What is an XPath Function? The platform also contains a number of functions that allow for embedded operations within XPaths. These allow for: String manipulation with functions like contains(), string-length(), and ends-with() o Example: [contains(Description, 'emergency')] returns a list of all VacationRequests where the Description field contains the string ‘emergency’. DateTime manipulation with year-from-dateTime() and weekday-from- dateTime() o Example: [year-from-dateTime(StartDate)=2020] returns a list of all VacationRequests where the StartDate occurred in 2020. Boolean expressions for true() and false() o Example: [IsLocalUser= true()] returns a list of all Accounts where the boolean IsLocalUser is set to true. The list of these can be found in the XPath constraint function reference guide. Checking for Empty Values So far, you have created XPath constraints based on checking the values of certain fields. The situation becomes more complex when you seek out entities where values have not been assigned. You know how to retrieve all VacationRequests for the current user, but how could you retrieve all the VacationRequests that do NOT belong to the current user? The Mendix platform has helpful functions to facilitate these types of queries. empty When an attribute or association does not have a value, the platform can still check for this using the value empty. Example: //VacationManagement.VacationRequest[Status= empty] This XPath returns a list of VacationRequests that do not have any value assigned for status. not() In addition to the empty check, the platform has a mechanism to check if conditions are not met. This is the function not(). This function can be used to evaluate expressions created using operators and attributes. Example: //VacationManagement.VacationRequest[not(StartDate > '[%BeginOfCurrentDay%]')] This XPath returns a list of all VacationRequests where the Start Date is NOT after today, meaning all vacation days that occurred today or before today. This function can also be used to evaluate if associations are populated. Example: This XPath returns a list of all VacationRequest that do not have a submitter account associated with them. Example: This XPath returns a list of all the Accounts that do NOT have a vacation request that starts today. It will also return all accounts that do not have any VacationRequests at all. In this way, this query could be used to determine all the employees that ARE in the office today. Knowledge Check Question 1: Let’s assume you add a new decimal attribute to the VacationRequest entity called ‘DaysUsed’. The value represents the total amount of days used for the requested vacation. If you write a microflow with a Retrieve action, what will be the return if we use the following XPath [DaysUsed < 4.5 and not(VacationManagement.VacationRequest_Submitter/Administration.Account)] A list of all VacationRequests that have been approved and are shorter than 4.5 days A list of all VacationRequests that are longer than 4.5 days A list of all VacationRequests that are shorter than 4.5 days and do not have a Submitter assigned A list of all VacationRequests that are shorter than 4.5 days and have a Submitter assigned Question 2: If we populate a DataGrid of VacationRequest entities with the following XPath constraint, what will happen? [StartDate = empty] This XPath will throw an error in Mendix Studio Pro. DateTimes cannot be empty. The grid will show All VacationRequests where the StartDate is greater than the current date. The grid will show All VacationRequests where the StartDate is not populated. The grid will show the VacationRequest with the oldest StartDate. Create an App with Advanced Page Building 1. Introduction Welcome Welcome to the Create an App with Advanced Page Building learning path! By the end of this learning path, you will be able to: Build the basic structure of an app (App Explorer, Domain Model) Create a custom navigation layout and login page for an app Add and configure an input wizard in your app Build a process to manage and approve employee vacation requests in your app Set up a notification system for specific users Translate your app to another language 2. Setting Up the Expenses App Structuring the App Explorer Creating the foundation of the app involves structuring the App Explorer. Once you start adding documents (like pages and microflows), it is important to invest a bit of effort into doing this in an organized manner. Otherwise, the App Explorer for your application could become messy, making it harder for you to build the app quickly. The structure for your documents starts with a clear separation of folders. By using a good folder structure, you will improve the maintainability of your application. You will be able to find required documents faster and therefore will be able to develop and fix them faster. Documents can usually be grouped by folder into process-related sources and entity-related sources. Process-Related Sources Every app consists of processes. Structure your documents for these processes into folders that reflect individual processes and their steps. Entity-Related Sources Every app has documents that are needed for specific entities. Think of overview pages for maintenance, validation microflows that prevent commits, or other event triggers. These types of documents should be structured into one folder that is named after the entity. The Domain Model Just as important as having a well-structured App Explorer, it is essential to have a well-structured Domain Model! We need to think through the data needs of our application and structure the entities and associations appropriately within the Domain Model. We will also take advantage of generalization within our Domain Model. More information on this can be found in the Advanced Domain Model Skills learning path. This includes the attributes, associations, events, and other properties. For our application, we will take advantage of the Administration and System modules that are included in every Mendix application. We will create two specialized entities in our Domain Model that inherit the Account and Image entities from these modules. This will allow our application users to have the same attributes as the Account entity like full name, email address, and user name. Also, it will allow users to have a profile picture connected to their account. But why use specialized entities rather than the Account and Image entities themself? First, because the Administration module is a Marketplace module, so it’s best practice not to alter the module itself. Secondly, you can’t change the access rights of the System module, but you can change the access rights of a specialization. App Security It’s best practice to add security to your application as soon as possible. We also need security to be set up so the microflow we just created can work correctly. But more importantly, we want to get this Expenses application into the hands of our users quickly. Let’s get going! Team Member Management Pages With our Domain Model setup and Security set, we now need to build our pages. These will allow Andrea to manage her team. She specifically is looking for an overview page where she can see all of her team members. Additionally, she would like a detailed page where she can create new team members or edit existing ones. Do you remember the naming convention for pages? It is Entity_PageType. And if a page is for a particular user role, it is Entity_PageType_UserRole. Let’s put that into practice and make those pages for Andrea! Knowledge Check Question 1: What is the correct way of structuring resources within the App Explorer? By switching to Structuring mode Automatically Manually By downloading App Explorer Structure app Question 2: When structuring the App Explorer, which of the following subfolders would be the best choice to store things like Enumerations and Regular Expressions? Resources Pages Microflows Domain model Question 3: How can you connect a profile picture to the account of a team member in a way that allows the picture to be altered? Copy the Image entity from the System module to the Domain Model of your module. Directly use the Image entity of the System module in the Domain Model of your module. Create a ProfilePicture entity and configuring Image entity in the System module as its generalization. Question 4: Which widget needs to be used inside of a List View for visualizing a dynamic image? Image Dynamic Image File Uploader Image Uploader 3. Branding Learning Objectives By the end of this module, you will be able to: Explain the importance of a custom navigation layout Describe the main elements of a navigation layout Define what a Master layout is Build a custom navigation layout Compare the pros and cons between using the built-in login page or building your own Create a custom login page Enable anonymous user registration in your app Introduction Just as important as a well functioning and secure application, so is a good- looking application. By using the styling tools of Mendix, you can ensure your company’s brand is well represented and create a great user experience. While you can use several out-of-the-box styling elements, you can create your custom styling. When it comes to adding custom styling to your app, you have two options: Changing SASS variables. Mendix uses SASS (Syntactically Awesome Style Sheets) to quickly change existing styling, which is then compiled to CSS (Cascading Style Sheets). Cascading style sheets are used to format the layout of web pages or in this case your Mendix app. Adding new styling in a custom layer. It is also possible to create completely new styling using SASS or CSS. For this, you need to write this code yourself, which is why it’s considered an Expert feature. In the previous module, you built the foundations of the Expenses app, being able to manage team members as an Administrator. Andrea now wants users within the App the ability to sign out of the App as well and register for the App if they currently do not have an account in the system. To do this we need the following: Andrea wants the app to be built according to the branding of the company. You will now adjust the app to reflect the company’s branding with the following tools: Update the app’s theme to match the corporate branding by changing SASS variables and compiling those into CSS. Build a custom navigation layout that shows the normal navigation menu and allows users to sign out in the top bar and a dynamic header that displays important information. Create a custom login page that will allow users to either create a new account or log in with an existing account. Custom Navigation Layouts Layouts specify what goes where on a page. They provide you with greater flexibility and reusability in application design. Each page is based on a layout. The layout contains widgets and structures that repeat on every page based on that layout. For example, if you placed it into a layout, your application logo will show the application logo on any page that uses that specific layout. Layouts are used to structure the user interface of your application, helping to quickly create familiarity with consistent layouts, and maintainability through the reuse of them. Familiarity breeds the less head-scratching, the more familiar we are with something, the less we must think to figure out how to respond. It’s for this reason that we know what to do when we encounter a door – we instinctively reach for the doorknob instead of kicking down the door. This is a basic human trait to seek the easiest path, the one with the least resistance. Each layout you create has the potential to be used thousands of times, reducing the maintenances of your design, as one change made in your layout subsequently can be applied to all pages that used that layout. For instance, if ten pages use the same layout and you want to add a left sidebar, instead of making that in ten places, you make it in one place to the layout, thus saving you valuable time and effort in making engaging and beautiful user experiences. Atlas UI by default offers three navigation layouts: Atlas Default (featuring the navigation menu in a sidebar) Atlas Topbar (featuring the navigation menu in a topbar) Popup (a popup page instead of a full-width page) If you want an app that has both a sidebar and a topbar, for example, you will need to create a custom navigation layout. The Basics of a Navigation Layout A layout consists of the following important components: Scroll containers Scroll containers are used to divide the layout into individual regions e.g., header, sidebar and footer regions, and set the scrolling behavior for those regions. A scroll container must be the only top-level widget which means that you’ll always need to start with it when structuring your layout. Aside from that, they can only be placed directly into another scroll container. Contents The contents cover everything that should be present in every page that uses the layout, from navigation bars to sign out buttons. Placeholders These are the empty areas that form the canvas for any pages that make use of the layout. When we create a page based on a layout, the layout’s content remains the same while the placeholder areas cover what is unique to the page. Note that Mendix dictates that at least one placeholder is named ‘Main’. Master Layout A layout can be based on other layouts, in which case the parent layout is referred to as the master layout. If a layout has a master, it can use the placeholders defined in the master to create a more specialized configuration. If a page is based on this specialized layout, you can only make use of the placeholders defined in this new layout, not the ones of the master layout. Master layouts provide even more reuse in the design of your applications and lead to better maintenance in your project. By utilizing reuse through Master Layouts, you incorporate the principle of DRY (Don’t Repeat Yourself) into your project, reducing duplication of elements you’ve already created. Enabling you to stay in control of your design and its maintainability. For example, if your master layout only defines a header and the derived layout (which uses your master layout) adds a side bar, pages can then be either based on your master layout or the derived layout, with changes made to master layout being reflected on any page which uses one of these layouts. This chain of layouts can be as long as is necessary, although in keeping with UX design practices and the value of simplicity (an important value in UX and UI Design), we advise a maximum of 3. Custom Login Page Every Mendix app has a default login page, that looks like this: Now, let’s say you want a different login page. Either because you want a different design or because you want a page where people can also create an account if they don’t have one yet. There are two ways to change the login page: Create a custom login.html file Use the built-in custom login page Let’s look at how this works and what the pros and cons of the two options are. Custom login.html One way to create a custom login page is to create a custom login.html file, which replaces the default login page. This is considered an Expert feature because this requires you to write HTML. You will not use this approach in this learning path, but here is an overview of the pros and cons as a reference: Pros You don’t need to allow anonymous users, making this a very safe option The Mendix app is loaded after logging in, which again adds to the security of the app Cons You need to be able to write HTML to build this page Built-in custom login page The second way to create a custom login page is to use the built-in custom login page. This feature is available to you out-of-the-box in your Mendix app. It’s easier to use than the custom login.html solution, but as you can see in the following list of pros and cons, you must be more careful with your security. This is because you need to allow anonymous users access to the app. Pros Easy to use You don’t need to know how to write HTML Cons You need to allow anonymous users The entire Mendix app is loaded before logging in In this learning path, you will learn how to build a custom login page using the built-in option. You will also learn how to allow anonymous users access to your app without giving them access to your data. Knowledge Check Question 1: Which of the following options is used for featuring the navigation menu in a sidebar? Atlas Sidebar Popup Atlas Default Atlas Topbar Question 2: Which of the following terms refers to the empty areas that form the canvas for any pages that make use of the layout? Scroll containers Layout grid Placeholders Contents Question 3: When a layout is based on another layout, which of the mentioned option refers to the parent layout? Template layout Master layout Placeholder layout Main layout Question 4: Which of the principles needs to be utilized to reduce duplication of already created elements? BUY TRY FLY DRY 4. Adding Requests Learning Objectives By the end of this module, you will be able to: Set up a request wizard using one of the Mendix wizard page templates Configure a Reference Set Selector Set up single and multi-select on a data grid Configure a page to check a request prior to final submission Make your custom navigation layout dynamic Introduction In the previous module, you made sure that the Expenses app matches the branding of North Sea Shipbuilders. Now, it’s time to build the first major feature of the app: Allowing regular employees to add requests for materials and tools in the system. They will add these requests via a wizard, where: On the first page, they can select an existing project (a ship being built) or create a new project. If the request is for a tool that will be used in multiple building projects, they should be able to select multiple projects. On the second page, add one or more material/tool requests. On the third page, they can check their request before sending it out. The Wizard Page Template Time to create the request wizard! For this, you are going to use one of the Mendix Wizard page templates. For each step in the wizard, you will need to create a separate page using the same page template. You can configure the progress bar at the top of the page to show the user on which step they currently are. The wizard Andrea asked for contains three steps: Selecting the project Adding request lines Checking the request before sending it out. In the following lectures, you will build the three basic pages of the wizard and add the specific functionalities to each individual page. The Reference Set Selector Now, you’ve laid out the basics of the Request Wizard, it’s time to complete step 1 of the wizard. This is the page where the employees will select the location that they need the supplies for (Boston or Rotterdam), and the project(s) the request belongs to. They should be able to select multiple projects for the request and create new projects on the spot if necessary. Selecting multiple projects can be done with the reference set selector widget. The reference set selector is the widget you use in Mendix to select associated objects. You can use this option when multiple select is possible. In other words, with a * - * association. You can configure the widget to show the options in a dropdown or in a select page. If the list of objects to choose from is very big, it’s best to show them in a select page. This allows the list to be loaded later, making the initial page load faster. Also, it’s a more user-friendly approach, because they don’t have to scroll through a giant dropdown list. Single and Multi-Select on a Data Grid Time to finish the second page of the wizard. On this page, the Requestors will be able to add one or more request lines to the request. They should also be able to edit existing request lines (one at a time). Last but not least, they should be able to delete existing request lines (multiple at once). To build this functionality, you will need to add a data grid with buttons that support single (edit) and/or multi-select (delete). With a data grid that supports multi- selection, the default Edit and Delete buttons don’t work. They only work with data grids with a single select modus. To still have the edit and delete functionalities, you will need to add two action buttons that trigger microflows. Continue to the next exercise to learn how to build these microflows! Knowledge Check Question 1: You want to re-use a header on multiple pages, which of the following options can you use to ensure that the content of the header throughout the app automatically changes after you modify its content? Snippet Widget Template Building block Question 2: Which of the following widgets can be used to select associated objects, when multiple select is possible? Drop-down Check boxes Reference set selector Reference selector Question 3: From the buttons on a Data Grid widget that work with single select mode, which ones need to be configured with multi-select mode? New, Edit New, Delete Edit, Delete New, Edit, Delete Question 4: Where should you configure that only selected roles are allowed to see a container on a page? In the Conditional visibility property of the container. In the User tab of the Project security. In the Page Access tab of the Module Security. In the Navigation visibility property of the Page. 5. Approving Requests Learning Objectives By the end of this module, you will be able to: Build a process to manage and approve requests Build pop up pages Introduction In the previous module, you built the wizard that allows employees to create requests. In this module, you will build the next functionality of the Expenses app: the approval process. The finance employee will need an overview of all outstanding requests and be able to view their details. Next to that, they should also be able to approve one or more requests at a time. The finance employees can already see all requests on the homepage. On this page, however, it’s impossible to add search fields, so they can filter out the new requests. This is because of the data source microflow that populates the list view with data. Let’s start by building the finance employees a page with tabs, where they can see all New Approved and Rejected requests separately. Working With Popups Now that you have built the overview page for the Approver, let’s focus on allowing them to approve or reject requests. They should be able to see the details of each request in a popup window. In the footer of this window, they will have a button to either approve or reject the request or exit the approval process by clicking cancel. Resizable popups By default, popup windows in Mendix are resizable and the size of the popup is determined automatically. It is also possible to give popup windows a fixed size. This is done in the properties of the page. You can give the popup window a fixed width, fixed height and set the resizable property to no. That way you create a popup window that is always exactly the size that you specified. Popup footer By default, popup windows in Mendix are generated with a layout grid as the most outer layer of the page. This will make the entire page scrollable, meaning the buttons in the footer will also be in the scrollable area. They won’t be directly visible in popup windows that are relatively long. With a larger page, or with popup windows with a fixed size, it can be useful to always have the buttons in the footer visible, because they contain important functionalities. By removing the outer layout grid, the footer of the popup window becomes “sticky”, in other words: always visible. Knowledge Check Question 1: How is the size of popup windows set to fixed? By manually setting the size of page columns. By selecting Atlas_Fixed layout. Automatically. By setting the resizable property of the page to No. Question 2: How can you ensure that the buttons in the footer area of the relatively long and scrollable pop-up page are always visible? By setting floating property of the footer to No. By removing the outer layout grid. By removing a scroll container. By fixing the size of the scroll container. Question 3: What constraint can you use to show the most recently created items at the top of the page? dateCreated (descending) createdDescend (date created) createdAscend (descending) createdDate (descending) Question 4: What are the default Mendix options for the popups? Resizable with size determined automatically, with layout grid as the most inner layer of the page. Resizable with size determined automatically, with layout grid as the most outer layer of the page. Fixed size determined automatically, with layout grid as the most outer layer of the page. Fixed size determined automatically, with layout grid as the most inner layer of the page. Question 5: How to make the popup window always visible? Choose a different popup style. Add a button to “glue” them. Remove the outer layer grid. Change the layer grid. 6. Notifications Learning Objectives By the end of this module, you will be able to: Add a notifications module in your app and set up its security and access rights Build the functionality to create, approve and reject notifications in your app Build the functionality to display notifications in your app Introduction In the previous module, you made sure that the finance employees could approve or reject requests made by other employees. At this point though, both employee groups have to check various pages in the app regularly to see if there are any updates or new requests. In this module, you will build a notification system so that the employees can directly see wh

Mendix Intermedium Path PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue