The last few days at work I’ve been creating page layouts for some new websites. Given these were from scratch, rather than the recent swathe of updates to sites I have been doing I thought it was a good chance to apply some flexbox css. I have used it before a little in Angular applications, using Angular Flex-Layout, but hadn’t really used it natively.
Good old mate css-tricks has a nice little guide about what the settings are, but I was having a hard time remembering all the options and which one did what etc. I just couldn’t picture it. So I decided I would make a little tool for both visualising what each setting would do, and for then being able to copy and paste those css atributes straight into my work. I based what I was doing off the excellent Angular Flex-Layout demo here.
I got married a few weeks ago, and my main task in the preparation and planning for the wedding was to create a website. It was to server two purposes: provide all the details necessary for guests, and be the mechanism for RSVPs.
I made the website using Angular and Firebase, which was my first project with those two technologies. I really liked the component style of Angular (of course it is not unique to that), but the whole CLI made getting up and running and making changes very fast and easy. Firebase is fairly well documented, but not as completely as I would like. The same goes for AngularFire, though it did make a number of things easier. One of the best resources that I found was a channel on YouTube, Angular Firebase.
This is a website I made to showcase my photography. For about a year I was shooting concerts for Amnplify and needed somewhere to upload galleries for my own use, that I could share with the artists. This site is built on a LAMP stack, and hasn’t been updated in a while (having a baby really cuts back on your concert going!) I am currently in the process of re-building this site as a FAN stack app (Firebase, Angular, and node.js).
If you’ve ever used the OOTB publishing approval workflow, you will know that it’s pretty good and easy. But, if you’ve ever had some slightly niche requirements, then you may have had an absolute nightmare trying to figure out how to implement it!
If you want to do some customisation, like route the approval task to different groups for different items, then you will need to make a new workflow. So you can copy the OOTB one and add in a lookup of some kind to set the Approver field. Great, that was easy! Sure was easy, and that shouldn’t really affect anything should it? You give it a test and discover that approving your task didn’t affect the actual list item’s approval status. Huh. Oh well that makes sense, because you normally set that when creating the workflow…but that is on the site. There must be a setting in Designer. Oh. There isn’t. Never fear! We can add in some steps to the workflow to set it. Take that Designer, I have bested you! You test again and it works like a charm. But then you think, what if you just approve the item from within the list, rather than the task you have been assigned? You guessed it, it doesn’t stop the workflow. WHAT?! Argh!
Eventually, you land at the solution. I will have my custom workflow, but I will control it through event receivers. I will start it and end it, I will set the approval status, it will all happen through event receivers. That is kind of annoying to set up, let’s not kid ourselves, but unless someone else can shed some amazing insight onto this, that is the way to do it.
There is one other thing to note about custom workflows. They are necessary when you want to refer to a custom field in a list. So if you thought you could be clever and use the OOTB workflow and have a field on the item that is the Approver group to route to, then you are sadly mistaken. I haven’t tried it, but apparently you can limit a workflow to a content type and so could put the field you want in a content type and then have your list inherit that. In theory that should allow the OOTB workflow.
So here is a gotcha that was discovered at work in the last week…it appears that content types don’t just inherit, they also pass properties back up to their parents! Essentially, I had a content type that was being used for a list. The content type inherited from built-in property types, you know the deal Document from Item type thing. Anyway, there was a request to update the compulsory Title field in the list to be ‘Surname’ instead. Simple enough you would think. Well, it is and it isn’t. If you try to be a good little developer and think that you will update the content type because you might use it again and you will want it to be ‘Surname’ there too, well, you would be wrong. This is what was done, but then ‘Surname’ was popping up all over the place! It turns out that it had sent that edit of the field name back up it’s inheritance and sent them all through the site. The correct way to apply the change is on the List Settings for the specific list where you want to change the Title display name.