Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
This time we take a short look into some xForm functionality! Why? Well, because they are still part of the platform and usable for a solution although they might not look that ‘sexy’ for the UX as we know today.
It also triggers me a song:
Wish we could turn back time, to the good old days...When our 'xForm' ruled as our form but don't get stressed out!
It’s a lyric update from ‘twenty one pilots: Stressed Out’…Just because it’s a nice Friday today! 😎
I got triggered for this post because a reading session in the administration guide had a direct connection to the last post where we did some task handling for our end-users. What part of the admin guide? Well, the part about ‘Embedding Inbox as a URL’ where we include an .CAF file URL in our solution!
This immediately raised another question that I would like to investigate: “What other xForm can be embedded!?”
Let get right into it…
Spin up your machine where we continue our exploration on the tasks from last post…So, hopefully you didn’t clean up the mess from last post, and you have that ‘case’ entity still available! Within runtime some instances, and some triggered tasks in the inbox? If you don’t have it, make sure you have it in place. If you don’t want to follow the last post for this to happen you just create a small lifecycle with one or more states and in every state an activity. When you leave it un-assigned it will land in the inbox of the current user!
Just a simple lifecycle like this should be fine for this post:
All in place?…Time for some xForm diving!
The documentation I was reading is talking about a ‘secret’ URL that looks like this: http://192.168.56.107:8080/cordys/com/cordys/notification/workflow/worklistinbox.caf
OK…Let’s type it in our browser and just check the result!?
Let’s compare that with the ‘sexy’ UI…
Hmmm…nice to see what ‘sexy’ can do on a platform! 😜
But how nice would it be to show that URL somewhere in our own solution!?
Check the next section…
For this ‘homepage’ we first create a nice folder in our project with the name ‘homepages’ and in there we create a new ‘Homepage Layout’ document. Give a nice name like for example ‘Task comparator’:
Hit that ‘Configure’ button to build up are homepage with some panels…
First we’ll drag & drop a ‘Lists’ panel…That will show us the ‘normal’ inbox with the default lists that are created like we see on the default homepage layout.
Next we’ll add a ‘Results’ panel that is linked to the ‘Lists’ panel. So, when we click on an item in the ‘Lists’ panel we also see something happening.
And third, we’ll add a ‘Web Content’ panel where we use our URL as input
Why not use the ‘XForm’ panel?? Good question! Works perfectly; Only you need to use this path as input:
When done…Save that homepage and do a publication to runtime!
If you are connected as a ‘simple’ OTDS user like I am with a user account ‘user01@awt’ you need to apply some extra security on the homepage. With a developer role user you should already be fine, but it’s always a good way testing with a ‘simple’ user account!
Just do a right-click and click the ‘Define Runtime Security’ action
I need to add the ‘Identity User’ role with ‘View’ permission on the homepage.
Extra note: In earlier versions of the platform you could make this security permission in the
/app/adminpanel, but in later versions of the platform you see these security settings moving to design-time!
In runtime we should see the new homepage:
And when we open the thing we’ll see something nice like this:
My opinion: “That xForm doesn’t look that bad at all with those nice icons!”
At the moment I’m just playing a bit with the ‘Claim’ and ‘Revoke’ buttons on both panels and then you start to see that the xForm is not really ‘Single Page Application’ compatible. Also, when you make your screen smaller you’ll see that the top list is responsible and will adapt based on the screen size. The xForm gets a scrollbar and keeps its layout as it should be. So, both have their pros and cons!?
Also, what I see in the xForm panel is that you have some extra options I can’t find in the other panel…Actions like ‘Tagging’, ‘Reminder’, ‘Attachment’ and ‘Memo’…I tried some of them, but it looks as they are not really compatible anymore with the ‘new’ and ‘sexy’ way of handling tasks (or maybe I need to configure something for that in design time? That’s not for now!)
Now we know how to use that .caf URL as input I’m curious what else we can use as input. So, where are those CAF files saved?
A quick search on the server give me zero results:
sudo find /opt -type f -name '*.caf'
Well, .caf files are XML files and should then be available in the XML store!
And if we talk about the XML store we also talk about the ‘XML Store Explorer’ artifact…
Let’s open it and double check this path
Ohw yeah….You see the trick?
Others to try out…
We’re not diving into to creation of a new xForm with this post, but you can trust me that those self-created xForms are also accessible like this! We’ll dive into this in another post…it’s on my backlog!
Let’s open a simple one (I guess!)…
Let’s clean up some overhead, so we see the skeleton of an xForm file:
Well, looks just like HTML or maybe better XHTML! With a header, body, and some scripting…
Lucky for us that the platform provides us with an xForm designer where we dive into once we start to build our own xForm! Hint: we played already a bit with it in this post
That’s it for some basic knowledge about the xForms provided by the platform. It’s a “DONE” where we learned more about calling xForms from our UI. We also saw how an xForm file skeleton looks like and where they are saved! Now it’s up to you how these .CAF files can improve your solution. Have a great week-end and I see you in the next on…