Multiple Edit Pages for the same Object differentiated by Ty

Hi Murali,

I look forward to the enhancement in 2017.

In the meantime, can I "intercept with code" the standard Edit function (in Lists and on View pages) to navigate to a different page of my choice (using the template token)?

I have disabled the default Actions and included my own "Actions" column (using a Template Text field) which gets me a step closer. However I can't see an easy way to invoke the standard Delete record dialog... I would also like to include a Clone icon but can't see (in any documentation) what to call...

I also can't see an easy way to change the default View Page from the record name (link) in a List view. This would also help differentiate records with UI until "Record Types" are implemented.

Your thoughts?

Regards,

Peter

My suggestion doesn't need for you to disable the standard new, edit, and view pages, in fact I actually use them all in the process. I posted this at another place but it might help you out as you have almost the same inquiry:

Try using client-side script to redirect to the correct new, edit, and view page depending on the "type" of record.

- Create multiple new, edit, and view pages.

- Remove everything from the "base" new, edit, and view pages before anything else

- On your "base" new page >> Add a picklist (or identifier) field.

- onchange of the field, redirect the user to page 1 or page 2 depending on the "record type", sample script below:

var x = rbf_getPicklistCode('picklist');

if (x == "1") window.location.href = "{!page1#URL}";

else if (x == "2") window.location.href = "{!page2#URL}";

//you can get the URL tokens in helpers, near the bottom of the 2nd helper picklist

- This would mean that the "base" page would be your jump page towards the correct pages that a user needs to land on.

- The same logic will be used on View Pages and Edit Pages with the slight modification of exchanging the getPicklistCode() with your identifier token (e.g. var x = "{!picklist#code}"). For view and Edit, you don't really need anything on the page except the script.

The process of it is that you would always have a jump page for each type of transaction (new,view,edit) to lead the user to the correct landing pages depending on the "record type".

Hope this helps you out.

I'm also waiting for the said 2017 enhancement to roll-in so that we can have a no-code record type solution.

Cheers!

Thanks for this. The problem with the "Add" with a picklist (or any other UI control) is you get a "Do you want to leave this site? Changes you made may not be saved" dialog box. Answering "Leave" works (and goes to the appropriate page) but is counterintuitive to the process.

Any further thoughts?

I see what you mean. I don't think it's that much of a bother though as for me it is logical to ask the user if he is done creating or editing a record. As per the script, at the very least you'll be sure to always land on the right pages. It might be a minor nuisance at first but I think you'll see its value in the long run when users try to close their browser.

Is my understanding right or do you mean that when the onchange fires on the picklist you already get the dialog? If this is the case, instead of using window.location.href, use window.location.replace()

Hope that helps

The onchange is the problem. Tried the window,location.replace() without success.

The issue is RB thinks you are leaving a "New" record without committing it, and wants to warn you. We need to find a more native (to RB) solution.

Further thoughts?

I just tried this on a test object with a test picklist and page on the New UI - non-vertical layout:

<script>//bound to the onchange event of the picklist in object definition

function test() {

 window.location.replace("{!#LINK.Record_Type_Test#13423456}");

}

</script>

It worked as expected. Didn't prompt me.

May I see a snippet of your code? If it persists, I think there is a simple solution of overriding the window.onunload property of the page.

Hope this helps.

You could probably try something like:

$( window ).unload(function(event) {

 event.preventDefault();

 return;

});

and

try {

 window.onbeforeunload=function(){

   return;

 };

} catch(e){}

try {

 window.onunload = function () {

   return;

 }

} catch(e) {}

the try catch blocks are used just in case the browser doesn't support the function. Jquery usually supports browsers well so I don't see the need to add try-catch there.

Hope that helps you out.

With Rollbase NUI, we have moved presentation logic to client-side and have developed a client-side SDK.

Leveraging these client-side frameworks which are already used to construct UI screens and now available as part of an SDK, amplifies scope of extending & customizing Rollbase UI.

If on NewUI, for the above discussed set of client-side solutions, you may want to consider the following provisions in Rollbase:

1. Remove dirty page notifier for a form page

var pageContext = rbf_getPageContext();

pageContext && pageContext.removeDirtyPageNotifier();

2. To query record details for the current page (eg. deduce recordType/Object DefID)

var pageContext = rbf_getPageContext();

//valid only for those page types which have a specific data record in context (i.e. View, Edit, Status...)

var recordDetails = (pageContext && pageContext.getObjectRecord()) || null;

//returns JSON object with top level record details like recordId, objDefId

3. Ajax Page Update for Navigation

With NUI, to navigate between application pages we do an Ajax page update to refresh only the page canvas. The following API is available for the same:

// supports navigation only within the current application context

rb.newui.util.loadApplicationPage(tabId,pageId,additionalParams)

additionaParams argument will take a JSON object with additional context details like record ID if navigating to a page like view/edit/status which has as single record context

Eg: rb.newui.util.loadApplicationPage(123,456,{id: 60456});

Note: One limitation with this API is that it does not support originalId's. You will need to use tokens to resolve tab and page id's which are to be used as arguments to this function.

Retreive current Page Tab (Application Tab/Menu) ID:

var pageContext = rbf_getPageContext();

var tabId = pageContext && pageContext.getPageTabId();

Note: These provisions are suggested to asssist with client-side solution for the requirement of deciding on PageID's dynamically. As Murali stated earlier, this requirement will be more comprehensively addressed later as an in-built product feature.

This should be enough to work with the solution proposed:

1. Remove dirty page notifier for a form page

var pageContext = rbf_getPageContext();

pageContext && pageContext.removeDirtyPageNotifier();

Everything else stated is already dynamic so we really don't need to make it more complicated with no.2 imo.

No.3 should be by user preference, ajax load or not. I've experienced in the past that AJAX-based loading would sometimes not make the onload/onready functions on the page run which is why I don't use it personally.

Hope this helps everyone viewing this thread.

Cheers!

I do wish Record Types truly become part of the platform.

Another set of suggestions would be:

1. Object has many record types

2. Record Types each have a set of pages

3. Record Type Pages can be cloned and can be set per role (like the non-record type pages we have now).

This way we can:

a. have an object with record type logic

b. construct multiple pages for record types

c. construct multiple variations of the pages for each record type and subsequently each role

Thank you all for your contribution to these issues. Including rb.newui.page.PageContext.removeDirtyPageNotifier(); solves the problem of the annoying notification dialog when wanting to navigate under programmatic control. I agree with mpiscoso that point 2 may complicate things given the ability to determine the object's type from built in functionality.

I think there is a ground swell of positive thought towards the record type model, as it allows an object to behave in a more "object-oriented" (abstract class) way.

Cheers, Peter