Symphony.

Ok guys, it's been a while since I wrote here but I have a good one for all of you. Ever played with the great Publish Tabs extensions from Nick Dunn? It's really great to separate data in a big section.

We use it for another reason too: Templating.

Let's say you have a Product section. Some fields are mandatory, some are not. In some cases, some fields should be mandatory BASED on another field's value, let's say the Product Type. The way we do it right now is make all the fields optional, and build Tabs than will contains infos that are mandatory in some cases. We really loose a lot of time in support because people forget to input the semi-mandatory data, and I hate this.

So, we wonder if we could build an extension for this purpose. The way we see it, we could extends Publish Tabs. We could add a template fields, which the user will use to "unlock" some tabs. So you are creating a new Shoe, all those Tabs contains values that are mandatory! You are creating creating a Book? Oh boy, you must input all the tabs. You see where am I getting at ?

I wanted to have feedbacks from the community before thinking about the code. Thanks !

That sounds like a fairly common use case, I usually create redundant sections, but it's not that useable. Thinking about your approach, are all the tabs visible when you haven't unlocked anything yet? Or tabs are just a way to categorize fields and the system would just show the Book tab instead of showing them all?

That's a very common use case imo, pops up almost every project I do.

I quite often use the backend javascriptr extension and write my own JS to show/hide fields based on other fields values.

I'm not sure I agree with using the Publish Tabs extension. It's a damn good extension that I use everyday, but from a UI standpoint, if I was making fields appear I would want them obvious and located below or beside the field that determines it's show/hide state. I think having another tab appear could be a little subtle, and then the related content is broken up/separated.

A new extension to somehow chain fields together could work. An interface that allows you to connect fields to a parent field and show based on a value. Does anything along those lines exist? I think it would become a very popular extension if it does exist/is created.

Maybe a slight modification to the subsection manager to load a different section into the subsection editor based on values of the parent field?

To be able to hide publish tabs would be a nice feature, but I don't think this is the best solution if you need to create a section that will need to have lots of hidden field all the time.

Thinking about your products example, a cleaner setup would be to create a products section with only essencial product info and then link this product with a sbl. Then, you would be able to create different types of products without having those unused fields.

The problem is that the product creation would be in two steps. It would be confusing for clients to create two entries for just one product.

If a tab could hold a section like Henry says, it would be great!

Sorry to all for the late reply, but I did forgot that I posted that in here!

Thinking about your approach, are all the tabs visible when you haven't unlocked anything yet?

@alpacaaa: No. Everything will be hidden until the user chooses a value. BUT, you could set a default value. Then, only the related fields would be visible.

If I was making fields appear I would want them obvious and located below or beside the field that determines it's show/hide state

@touchstone: I understand that. This would be good for a couple of fields, but would not scale up to 20 fields...

A new extension to somehow chain fields together could work. An interface that allows you to connect fields to a parent field and show based on a value.

@touchstone: I already though about that. The major problem is, that this would require ALL fields to be modify in order to let them have a particular input for this. This why I want to use the Publish Tabs field, which is already responsible for "grouping" the fields, without modifying them.

As far as your relationship mechanism goes, maybe this discussion should be submitted to @designermonkey, which is working on relationships. See https://github.com/symphonycms/symphony-2/wiki/Relationships%3A-Terminology

Maybe a slight modification to the subsection manager to load a different section into the subsection editor based on values of the parent field?

@Henry: Did not though about this. Great idea, but since the SSM is deprecated (see http://getsymphony.com/discuss/thread/83270/7/#position-121), I do not think it is feasable.

Thinking about your products example, a cleaner setup would be to create a products section with only essencial product info and then link this product with a sbl The problem is that the product creation would be in two steps. It would be confusing for clients to create two entries for just one product.

@renan_santos: Absolutely! If they can't remember which field are for which product type, they can't handle the 2 step process.

I really don't mind having lots of empty fields. Since each field instance have it's own data table in the DB, they will just be empty. SQL queries against empty table are FAST!

I understand your concern though. Having a section for all "details" data could be nice. Playing with section with 30+ fields is not really nice and fun.

Would you consider having a "tab" for each related section ? There would be the "main" tab, which is the current entry's data. Then you could add more tabs to this section and "link" them to another "sub-section". The extension would then display all the normal UI of each section when you browse through the tabs.

On the data point, the "main" section would hold a reference to the entries in other section. All of those ids will be our new global id for this relationship: id-of-main;id-of-child-1;id-of-child-2;...

The problem with this approach is you technically can "mix up" the data. The relation I want to create is a weird one: 1 to "1 and only 1 of [a,b,c,d,...]". Main or master entry could live without child: 1 to "0 or 1 of [a,b,c,d,...]". Symphony can't force that. This is why the one big section comes in the picture as a good solution.

I really think we should buzz @designermonkey on this...

---

Thank you so much for your input. It gave me views on the problem I was not able to get. Hopefully we, as a community, will found a good solution on that problem. Feels nice to see that I am not the only one facing this problem.