This is the final post in this series. In part 3 and 3.5 of this series we went over the AddOnLoad function calls which really is the heart and soul of the Drag-n-Drop functionality. Today we'll be going over the QuerySaveDocument and PostSaveDocument events that fire when the Layout is saved.
Since QuerySaveDocument fires first we'll go over that. This code makes the Left & RightSidebarContains fields contain multiple values instead of a single comma delimited string. I got this code from here. I'm not quite sure I understand why we have to do this but it's the only way I could get the fields to be true multi-value fields.
Now for the PostSaveDocument event. The main purpose here is to setup all the sidebar and page document fields to contain proper values, mainly the "Publish" (sidebar and page), "Container" and "SortOrder" (sidebar only). Currently we're really not using the "Container" field but this is being updated in the sidebar documents for future use. The container field just contains which sidebar area (right or left) this particular sidebar item is contained within. Also the purpose here is to enable the layoutbuilder to determine what was done if these documents are setup manually. We all know that people find ways to use our applications that we never thought of.
First off here, we get the values of the Right & LeftSideBarContains fields and convert that value into an array. We also get the value of the ContentContains field. Since this field only contains a single value theres no need to convert it into an array. We then loop through the sidebar arrays and get the appropriate sidebar document by the UNID and update the "Publish" field to "Yes". We also add that UNID to a temporary array so that when we're setting the sidebar documents that weren't used to "No" we know what we've already enabled. Now I'm sure there is a better way of doing this but at the moment this was all I could think of. Looking back it would probably be better to loop through the sidebar documents and look for the UNID in either of the two arrays, if found then set "Publish" to Yes, else set it to No. Lastly if the ContentContains value is not one of our generic lables for content we get the page whose UNID is in that field and set the "Publish" field to "Yes".
And that's it. We now have a drag-n-drop layout builder that updates our backend documents based on what was dragged and where it was placed. None of the code here is all that complicated, it's just that there is a lot of it. Looking back on this, I saw a tutorial that Jeremy Hodge done on the Notes In Nine video cast about using Java to manipulate the values of fields as they're changed. I think this would have been a better way to manage all of this as it would be more transparent to the end user and would allow more options when it comes to updating the other backend documents. But below is a screen cast of the end result. I'll also include a sample database with all this so you can better decipher my ramblings, but it may be a day or so before the sample db is available.
A code snippet Jeremy Hodge sent to me on how he updates backend documents via an agent (while I didn't use his idea, it did contribute to other ideas that I wouldn't have had without his help). Thanks Jeremy!
Here's that video. The errors that pop up when the layout type is changed, they're trying to update a table I moved so please disregard. Also, while making the screen cast, the avatars for what was being dragged didn't seem to function very well also, when the recording wasn't going on the avatars worked perfectly. To better see what's going on, watch the video full screen.
Mobile First Development
Fri, May 10th 2013 9:06a Keith Strickland At Red Pill Development, Peter Presnell has encouraged our development efforts to use a "Mobile First" approach. The process is that you design your mobile interface first, get everything working properly and then move on from there to Tablet and then Web Browser interfaces re-using as much as possible from the previously working mobile implementation. This approach has several advantages:
It forces you to research, gather requirements and only display and write code for the things you [read] Keywords: application
Announcing redpill Mobile
Wed, May 8th 2013 2:48p Keith Strickland Have you ever had a dream that you were so sure was real? Well today is the first step in realizing that dream.
A few months ago I made a post about being one of the co-founders for a new company called Red Pill Development. This company was founded on the controversial belief that modernizing Notes applications one at a time by reproducing all of the existing functionality is a loosing strategy. In order to turn a profit modernizing applications, you have to do so en-masse and only include [read] Keywords: lotus
Dojo Mobile ScrollablePane implementation
Sun, Apr 21st 2013 3:06p Keith Strickland At Red Pill Development we're pushing the envelope a bit on XPages Mobile, we're certainly pushing the mobile controls to their limits. Because of this sometimes we need to take matters into our own hands and override the XPages Mobile controls and kind-of take over how they operate or create our own.
One of the things you're going to encounter when you delve into XPages Mobile development is trying to put a Tab Bar at the bottom of the screen that actually stays at the bottom of [read] Keywords: domino
XPages and Dojo Mobile Events
Tue, Apr 2nd 2013 12:02p Keith Strickland Here lately, I've been working on getting events to fire within a mobile application in XPages. For example when a page first loads (i.e. is navigated to but not "transitioned" to) or when a transition/navigation to another page within the single page application. No events are published or made available via the domino designer IDE but we still need to be able to do something when a navigation/transition event happens. So, how do we do this and what are the event names? Well the dojo even [read] Keywords: domino