2024 Feb 21 1:03 PM - edited 2024 Mar 05 4:14 PM
If you missed week 1, you could find all the details: here
If you missed week 2, you could find all the details: here
Now that the challenge is complete: here is my sample solution: jung-thomas/dev-challenge-feb-2024: Developer Challenge February 2024 (github.com)
For this week's challenge we are going to mix things up. Week 1 and week 2 both focused on extending the protocol or version of service endpoints. This week we will use a plugin that has a completely different purpose. We are going use the Change Tracking plugin. This plugin both extends the data model and the Fiori UI automatically. It stores change history information, exposes it within our service and adds a Change History UI element to our Fiori application; all with extremely minimal effort on your part!
The Change Tracking plugin provides out-of-the box support for automated capturing, storing, and viewing of the change records of modeled entities. All we need is to add @changelog annotations to your models to indicate which entities and elements should be change-tracked.
https://github.com/cap-js/change-tracking
Your task is to add change tracking to the Books entity and the Title attribute in your application.
To complete the challenge, post a screenshot of the Fiori UI for managing Books with the Change History with a change entry displayed.
Bonus 1: Add change tracking to the Books.Author association. However, don't display the unique ID when the association is changed. Instead, the change log should record and display the Author Name.
2024 Feb 21 5:01 PM
2024 Feb 21 6:00 PM - edited 2024 Feb 21 6:01 PM
here is my submission
I changed the stock and price.
2024 Feb 21 10:16 PM
2024 Feb 22 12:38 AM
2024 Feb 22 1:57 AM
This is because the admin service requires an admin user.
You can just remove this or create a mock user with an admin role.
2024 Feb 22 10:12 AM
2024 Feb 22 10:41 AM
Or you can use the built in mock user of ‘Alice’ - no password. https://cap.cloud.sap/docs/node.js/authentication#mock-users
2024 Feb 22 12:56 AM
Here's mine:
2024 Feb 22 6:41 AM
2024 Feb 22 8:42 AM
2024 Feb 22 11:25 AM
2024 Feb 22 12:13 PM
Main task: showing change tracking of the Books entity's title element:
Bonus: showing change tracking of the Books entity's author element, but ensuring that the value of the name element from the Association to Authors is shown, rather than just the ID from the managed association's foreign key field (author_ID):
2024 Feb 22 12:18 PM
OK folks, so how many of you here went for the beautiful approach that CAP offers, moreover _encourages_, which is the ability to separate concerns?
In other words, who annotated the definitions in `db/schema.cds` directly, and who created a separate new CDS file and used the `annotate` directive (https://cap.cloud.sap/docs/cds/cdl#the-annotate-directive)? @thomas_jung @ajmaradiaga and I would love to know!
2024 Feb 22 1:27 PM
100% in a separate srv/change-tracking.cds
2024 Feb 22 5:44 PM
2024 Feb 23 4:41 AM
2024 Feb 23 2:03 PM
I actually did it in the same file. While I follow the concept of the separation of concerns, I don't do it as strictly has some do. I don't immediately put all annotations in a separate file. If the annotation impacts the data model; I actually like it to be as close to the data model definition as possible. Now, clearly UI annotations I always separate out.
With one exception; the annotation for value help. I feel like those belong in the data model although they certainly impact the UI. It's also about reuse and inheritance. Putting annotations like the value help into the data model ensures that they are available even if there are multiple different UIs built via annotations on that same model. This also might be my ABAP background where value help definitions are data dictionary objects and often tied in via the database table or structure.
I did have to stop and think about this particular annotation because it impacts both data model and UI. But ultimately, I thought in the future I'd more likely want to see which fields are marked for change tracking when I'm working with the data model itself.
I love the flexibility that CAP provides to allow for these different use cases and how one development group or company might adjust their own rules for what works best for them.
On a side note, this approach with separate files for annotations isn't just about separation of concerns of different layers but can also support reuse (as mentioned) and target platform specific logic. For instance, when you need HANA specific features you can have build rules that include only certain folders. But perhaps that's a topic for another day or another challenge.
2024 Feb 22 4:23 PM
2024 Feb 22 8:32 PM
2024 Feb 22 8:50 PM
2024 Feb 23 1:46 PM
Cool plug-in. These developer challege series are always fun to do and new learnings.
Week 3 & Bonus
I added the annotations in a separate cds file, as per the help documentation.
Thanks
Bonus
2024 Feb 23 6:54 PM
Bonus part:
2024 Feb 24 6:31 PM
2024 Feb 24 7:39 PM
2024 Feb 25 5:18 PM
Hi
bonus
2024 Feb 26 2:19 AM
My submission for this week's challenge and bonus
2024 Feb 26 7:27 AM
2024 Feb 26 8:28 AM
Hello,
Here is the task and bonus:
2024 Feb 26 9:41 AM
2024 Feb 26 1:12 PM
2024 Feb 26 6:09 PM
2024 Feb 28 7:24 PM
2024 Feb 29 12:38 PM
Finally catching up till week 3.
With Regards,
Ramesh Shrestha
2024 Feb 29 9:17 PM
Task & Bonus. Played around with @title and @Common.Label as well for fun.
2024 Mar 02 10:15 AM
2024 Mar 04 1:04 PM
2024 Mar 04 2:23 PM
2024 Mar 05 5:28 PM
2024 Mar 11 11:16 AM
3rd Week result