Skip to main content

The idea is rather simple but very useful. Consider the detail page for any record. Often when creating a page for new records, a separate page is built even though all the same fields are desired in the page.

It would be great if the mode could be conditionally set. Such as having a Field Editor be in edit mode if row is a new record and Read w/ inline-edit for existing record.

I agree.  This would help from having to make multiple layouts.


+1


That would be a very nice time saver.


Hello All -

This actually can be done.  See https://community.skuid.com/t/edit-mode-button?topic-reply-list%5Bsettings%5D%5Bfilte… for more details and make sure to read the posts that follow this post.  You can also then use conditional rendering to hide/show fields based on the row state (new, existing, cloned, etc.).

In the app I’m building, I have a single page for everything - View, Edit, New & Clone.  During page initialization, I have a custom component that sits on top of a framework that I’ve built that detects what type of page ‘mode’ it should be - New, Edit, View & Clone mode.  From there, it flips certain components to the desired mode.  As you guys mention above, having a single page is a huge time saver on both development & maintenance.

All that said, having this be a stock feature of Skuid would be awesome and avoid a lot of javascript that is required to properly support the functionality.


Yup. Exactly why I wrote the post. It’s a lot of javascript I don’t want to copy and paste from org to org and page to page and tweak here and there.

No thank you Sam-I-Am.


Agreed.  In the meantime, here’s one way of making it a little simpler:

1) Create a custom component that has a “model” property.  For example, a property called “Primary Model” which is a picklist of models on the page where the page builder identifies which “model” controls new/edit/etc.
2) In the component add a document.ready block that grabs the model identified in the property and checks to see if the row is new/existing/cloned/etc.  and based on that, uses a css class selector to “flip” the mode based on the javascript in the community post from JD but including the css class selector to “find” the components that should be flipped.
3) Place the component at the top of your page and set the model property.
4) Put the css class selector on each component that you want dynamically flipped
5) Conditionally render fields in components based on row state (new/existing/etc.)

A stock feature would definately be preferrable, but the above only requires that you install your component pack in the orgs and then throw in the component at the top of each page you want to be “dynamic.”


Just wanted to add my support to this idea. It has countless use-cases that would help to avoid having to create multiple pages.

My use-case at the moment is needing to have a set of Field Editors conditionally be in “Edit Mode” or “Read w/ inline-edit” by default, depending on the UserId or ProfileId of the Running User.


This reply was created from a merged topic originally titled Conditional Rendering “Component Mode” & “Field Editability” condition. Would like to see the following enhancements to conditional rendering:

1) Ability to write a conditional rendering rule based on the “mode” of the component (e.g. edit, read, readonly)

2) Ability to write a conditional rendering rule based on the “editability” of the field (e.g. field.editable)

This would go a long way towards being able to make components that support view/edit/new simultaneously.

In the past, there was discussion of adding a “call snippet” feature to conditional rendering.  This would allow a conditional rendering rule to be written in anyway that one could imagine.  The snippet would return true/false and could even not allow promises (to avoid long waiting async calls).  Having this added would be my personal nirvana 🙂

Thanks!


^^^ bump ^^^

Is this in Millau?!!?! Pretty please.