Think of how great life would be if every component had the option to set its display state in one of three flavors based on URL parameter. Then, in many cases, you would only have to build one page and in the URL add a parameter like &Display=Edit &Display=ReadEdit &Display=ReadOnly Perhaps you should just make that default functionality for all components. If the URL parameter of Display exists in the URL, then the component respects its value. If the parameter is not there, then the component respects the setting on the component.
Idea: EDIT/Read with Edit/Read Only Set By URL parameter
+17This topic has been closed for replies.
+17Thinking 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”.
+20Hmmmm … 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
+17It 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
+17You 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.
+13Hey 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.
+20Yup. 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?
+13“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.
+20Yup. 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. 😉
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.