Hi Marie, no, I am not aware of a mechanism to make some properties only visible in edit mode but not view mode. I believe I understand your use case, yet I always found if weird to have properties appear only in certain modes.
I guess the real fix you're after would be something else, e.g. making the table editable or some other mechanism for editing that would bypass the normal editing widgets. If you can narrow down this use case with details, feel free to submit them as feature suggestions to our ProductBoard. Keep in mind that we are getting closer to code freeze for the upcoming 8.0 release, so any suggestions at this time will likely have a longer runway. Holger > On 1 Mar 2024, at 4:02 pm, Marie Valadez <mevalade...@gmail.com> wrote: > > Following up on this. Was there a property introduced to hide certain > properties in view mode but not in edit mode? We have a viewer populating > data so that it is in table form (which is not able to be edited with EDG) so > we also have the property connections that define what is displayed in the > table. We would want to hide those direct connections in view mode but be > able to edit and add additional connections that would be displayed in the > viewer. > > On Tuesday, March 12, 2019 at 5:13:01 PM UTC-6 Holger Knublauch wrote: >> To reiterate Irene's point, I would encourage you to play with using >> multiple shapes. Shapes act as "views" on your data, and these views may >> consist of selected properties only, or include inferred statements. For >> example, you could define a shape ex:SimpleLabel that only has sh:property >> constraints on the properties that you want to expose*. I think it would be >> unusual to have certain properties only show up only in edit mode, but not >> view mode. It sounds like you probably just want to distinguish between >> those users that can edit and those that cannot. Switching between modes >> should IMHO not cause different properties to appear. In retrospect the >> hideInModes flag was probably a hack, that we primarily introduced for the >> search forms, because searching for some fields was too expensive. I would >> prefer to collect more evidence about its continued need before >> reintroducing them in the future. Each such feature carries cognitive and >> implementation workload. >> >> * Note that the role-specific views/shapes require the "new" forms to be >> activated. These are optional in 6.1 but are the default in 6.2. You can see >> a widget "default view for role" on the form for any sh:NodeShape >> >> >> >> Holger >> >> >> >> On 12/03/2019 6:19 pm, Eva Ibarra Sicilia wrote: >>> Hello Irene and Holger, >>> Thank you for your answers. I would like to hide certain properties in view >>> mode to customize what users can see and make it more attractive to them. >>> For example, I don't like to have the type 'Label' for all the SKOS-XL >>> Labels that appear as blank nodes. Same with other properties. Also, I was >>> hiding some properties in edit mode so users don't mess up the whole model, >>> and they only edit what they really want. I was relying before in the 'hide >>> in modes' functionality and I would like to have it back in SHACL or to >>> have something similar. I think the solution that Irene suggests would >>> solve the problem, but I was not able to test it myself in version 6.1.1. I >>> guess this would be available in version 6.2 which has not been released >>> yet? Thank you again for your support! >>> Regards, >>> Eva >>> >>> El mar., 12 mar. 2019 a las 0:19, Irene Polikoff (<ir...@topquadrant.com >>> <>>) escribió: >>>> I wanted to mention that with respect to view and edit, a possible >>>> solution available today is to use role-specific views/shapes. You could >>>> create multiple node shapes targeting the same class and selectively >>>> include only desired property shapes in them. You would then see a >>>> selection of different views in the drop down. >>>> >>>> >>>> >>>> The default view will continue to be the node shape that is also a class. >>>> However, you can make one of the other node shapes to default view for >>>> some role. Than users in that role would see it as a default. >>>> >>>>> On Mar 11, 2019, at 7:09 PM, Holger Knublauch <hol...@topquadrant.com <>> >>>>> wrote: >>>>> >>>>> Hi Eva, >>>>> >>>>> we have not yet added a SHACL-based replacement for arg:hideInModes that >>>>> was supported on SWA forms. I wasn't sure whether people would still need >>>>> it and didn't want to overburden the data model. >>>>> >>>>> With 6.2 onwards, the "search" mode has been completely migrated to the >>>>> new tabular search component (that has the column selection and filters >>>>> on top), so I guess we only need to talk about "view" and "edit" here. >>>>> >>>>> In what mode would you like to hide a property, and why? Would it help to >>>>> have certain properties as "read-only", i.e. still have them show up in >>>>> edit mode but not visible? >>>>> >>>>> This would help me estimate how a solution could look like. >>>>> >>>>> Thanks, >>>>> Holger >>>>> >>>>> >>>>> >>>>> >>>>> On 12/03/2019 12:29 am, Eva Ibarra Sicilia wrote: >>>>>> Hello, >>>>>> I would like to know if there is any way I can hide a property in a >>>>>> specific mode (view, edit or search) using SHACL constraints, as it was >>>>>> before with SWA forms. So far I couldn't find the way. >>>>>> Thank you! >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "TopBraid Suite Users" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to topbraid-user...@googlegroups.com <>. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "TopBraid Suite Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send an >>>>> email to topbraid-user...@googlegroups.com <>. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "TopBraid Suite Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to topbraid-user...@googlegroups.com <>. >>>> For more options, visit https://groups.google.com/d/optout. >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "TopBraid Suite Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to topbraid-user...@googlegroups.com <>. >>> For more options, visit https://groups.google.com/d/optout. > > > -- > The topics of this mailing list include TopBraid EDG and related technologies > such as SHACL. > To post to this group, send email to topbraid-users@googlegroups.com > --- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to topbraid-users+unsubscr...@googlegroups.com > <mailto:topbraid-users+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/1116e925-25af-4b1c-b50a-ae120c0ea8d2n%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/1116e925-25af-4b1c-b50a-ae120c0ea8d2n%40googlegroups.com?utm_medium=email&utm_source=footer>. -- The topics of this mailing list include TopBraid EDG and related technologies such as SHACL. To post to this group, send email to topbraid-users@googlegroups.com --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/DF6CC652-754F-4486-9CF8-DDDBF43AB41E%40topquadrant.com.
