Thinking a little more… make it a default function with specified parameter names and values. Then have a checkbox on each component for “Allow display mode to be set by URL Parameter”.

Hmmmm … really like the idea. How would we control the “Edit” mode once it is saved? We’d want it to switch to “ReadEdit”. As an example, create a new record w/ “Edit” mode to start and then switch to “ReadEdit” after saving. Let’s expand “Mode” control to be just like Conditional Rendering. ie. if row is new or URL Param “Display”=Edit

You could have the save button redirect to the same page but with the param Display=Read/Edit…

It would make mode buttons easy to make too. If you are on a ReadEdit, you could render a button labeled “edit” that simply redirects to the Edit version and visa versa

You could add “mode” rendering option too. For example, only System admins can access Edit or ReadEdit modes. That would stop a user from URL hacking their way into edit mode.

Hey guys -

I’ve actually done something like this.  In the last app I worked on, our pages were so complicated that having a different one for "read’ and “edit” would have been a maintenance nightmare (they were already difficult to manage).  

In short, I created a framework layer on top of skuid that allowed initial component state (read/readonly/edit) to be controlled and changed as needed.  It worked out really well actually.  For example, if the user had clicked “edit record” from a tab, the corresponding components started out in “edit” mode.  Then, after save, it didn’t even need to go to the “View” page - instead, it just flipped the state on the components.  There were ways to have components respect the “flip” or always appear a certain way.  Instead of having a “AccountEdit” and “AccountView” Skuid page, I had an Account_VENC (View/Edit/New/Clone) - yep, a single page handled all 4 situations

I think I posted an idea a year or two ago asking for something like this.  Would be a great feature to see added to Skuid.

Yup. I remember. Very Slick indeed. I remember the sneak peak you gave me back then. Is this something that could be easily OOB by Skuid?

“Easy” is relative.  I think it would be relatively straightforward for Skuid to implement within the core product.  Way easier than it was for me to put together as a layer on top, that’s for sure  

I would estimate that the amount of code within the core product vs what I had to do would likely be about 25%.  I wrote a lot of code (runtime & test) and spent a lot of time doing functional testing in order to make it all work.  In the end, it saved hundreds of hours of page building (for 4 versions of essentially the same page) plus eliminated all the risk of maintenance because with 4 pages, if you make a change to one, you need to change all the others exactly the same way.  

Yup. I think your work in Skuid has always pushed the boundaries and solidified its integrity. One of few others outside Skuid I consider stronger than i in Skuid.