Field Dependencies

[kongondo]

It seems like very few of us are going to get some sleep tonight (after watching this)...that feeling you get after watching Avatar...   the surreal bit (not the sorrow!)

[isellsoap]

This is truly magical. Wow.

[David Noble]

Yup, in awe, just like everyone else! A great addition to a great CMS.

[Marty Walker]

Once again, mind blown!

[MarcC]

Wow, I actually said stuff while I watched this video but it came out like "aaaaaah" and "ohhhhhh" rather than "I've felt the need for this on several occasions! Bravo Ryan!" Thanks for sharing it with us.

[purwa]

wow this is great.

[Pete]

Great addition, thanks ryan or building it and Antti/Avoine for sponsoring it!

It can make several of my more complicated forms on some projects a whole lot shorter and more legible now

And like many others, I marvel at how well ryan's initial versions of amazing features just seem to be so polished!

[Raymond Geerts]

This is amazing. Can think of so many situations that this will come in handy.

[Jarno]

Nice work, we'll use it often

[ryan]

Thanks guys, glad that you like how this is looking. Though you are giving me more credit here than I deserve. I didn't realize there would be so much interest in it, otherwise I'd have worked on it sooner! It's been on the to-do list for awhile (with a million other things), but didn't become urgent till I remembered/found out it was needed by the end of August. So figured I better get busy!  

I used Gravity Forms a couple of times. While it is build for front-end forms I really like the way the depencies are build there with multiple conditions aka conditional logic.

I like the way they define them there too. Longer term, I'd like to make a new Selectors inputfield that lets you build selectors this way, because it's a little more friendly in some ways, even if less flexible in others. But it's a good option to provide in addition to text input of selectors. However, I'll build that Inputfield later as something separate from field dependencies, so that it can be used elsewhere and by other modules, etc. 

Watching this I think the "required" need to be more visible or red (asteriks). It can be missed too easily.

I agree, especially in the context of the video. Though I also think subtlety is important so that required labels don't become a distraction (especially for common required fields like 'title'). If a field is required, and the user missed the visual que, they will still find out about it when they save. 

The field dependencies just add (or remove) the "required" class to the .Inputfield container, so the actual look of required fields is dependent upon the admin theme. But I think the field dependencies could do a quick fade-out/fade-in to indicate that something has changed about the field's state. 

It's weird how stuff Ryan puts out there always seems to be pretty much rock solid from the beginning. Awesome stuff.

I appreciate the compliment. But this is just not true. There are always bugs to fix, and I'm sure there will be several to find and fix with field dependencies, just like anything else (perhaps more so, given some of the complexity in it). So when those of you on the dev branch start using this, don't expect everything to work perfectly. Instead, experiment, test and tell me when you find something that doesn't work quite right.

There are so many scenarios that could happen with field dependencies that it may take a few iterations till we've covered them all. There are also some fieldtypes that may not be compatible with field dependencies. For instance, we don't currently have a way of polling the value from the rich text editors, since they don't update the related <textarea> elements on the fly. We could do it by accessing the TinyMCE and/or CKEditor API functions, but I'm not sure that I want to bundle TinyMCE or CKEditor-specific code into the field dependencies–that's the type of dependency you usually want to avoid in code. So you'll be able to show/hide rich text fields based on the values from other fields, but not based on the values in a rich text field. To be honest, I'm not sure that's a problem though, as I don't see rich text fields as being likely sources of dependencies anyway. 

how are the variable widths controlled? There have to be many different situations for those fields on one row. When d  they get a new dedicated row if there too many popping up in one row (like the checkbox example with "Pool" and "Children welcome")?

Those 3 fields are configured in the template for 33%, 34%, 33% width. Without field dependencies they would all fit on one row. When a field is removed from the mix as a result of a dependency, it simply expands the width of the last remaining field to fill out the row. The concept is really simple. It came about because I didn't like the look of the uneven rows when I started dynamically removing fields as a result of dependencies. While the concept is simple, the implementation proved to be a challenge... it's one of those things I thought would take 30 mins, and it ended taking much longer. Though a good part of that is just that I don't use Javascript every day (I'm definitely not an expert at it), so it can take me awhile to get things right. 

[apeisa]

For instance, we don't currently have a way of polling the value from the rich text editors, since they don't update the related <textarea> elements on the fly. We could do it by accessing the TinyMCE and/or CKEditor API functions, but I'm not sure that I want to bundle TinyMCE or CKEditor-specific code into the field dependencies–that's the type of dependency you usually want to avoid in code. So you'll be able to show/hide rich text fields based on the values from other fields, but not based on the values in a rich text field. To be honest, I'm not sure that's a problem though, as I don't see rich text fields as being likely sources of dependencies anyway.  

I don't remember a single case where we would have that kind of need. 99% times it is always radiobutton, select or checkbox which changes the requirements/visibility for other fields.

[MarcC]

So you'll be able to show/hide rich text fields based on the values from other fields, but not based on the values in a rich text field. To be honest, I'm not sure that's a problem though, as I don't see rich text fields as being likely sources of dependencies anyway. 

Did the admin use bold, all-caps text in the body field of the home page? If so, show the "site-wide alert" field. ...nah

[ryanscherler]

This is great! Looking forward to this Ryan!

[Pete]

Thanks guys, glad that you like how this is looking. Though you are giving me more credit here than I deserve. I didn't realize there would be so much interest in it, otherwise I'd have worked on it sooner! It's been on the to-do list for awhile (with a million other things), but didn't become urgent till I remembered/found out it was needed by the end of August. So figured I better get busy!

I think it's more that so many of us hadn't thought about this before but can instantly see the benefits ryan, not that we've necessarily all been waiting for it before now. I think that's testament to how well it's been implemented.

[Raymond Geerts]

Would this also work with fieldsets? That displaying a fieldsets is depended on a choice from lets say a checkbox or dropdown

[onjegolders]

This looks fantastic Ryan, a real great addition to the backend and a huge thank you to Antti also for sponsoring this project.

I think we need more sponsors if this is the end result!

[arjen]

I wonder what this company could sponsor!

[diogo]

[onjegolders]

I wonder what this company could sponsor!

Probably not a lot at this point! But very soon

Any ideas on what would be next in line? I guess it has to be something Ryan wants to do too!

[Martijn Geerts]

But I thought about http://www.kickstarter.com/ for processwire modules.

Maybe Ryan can choose some privileged developers that are capable of building quality modules.

If There's enough interest (money wise) a module can be build.

I will start a new Topic !

Edited August 29, 2013 by Martijn Geerts

[Macrura]

right, why not do a kickstarter or indiegogo campaign for some modules.....

[Pete]

ryan - just a thought, but would it be possible to make it so that fields can be shown depending on whether a user has a certain role, or even ID?

Certainly roles would take you one step closer to a system I used to use where there was an editing flow with a website's content - someone would work on content, then their manager would fill out some other fields on the same page, sometimes in another tab in the editor, before finally publishing a page.

It's not something that everyone needs, but to my untrained eye it also doesn't look like it would be too difficult to add (*ducks for cover*), would make it even more powerful and could be useful in many different scenarios.

I guess the selector for that would be something like user.role=editor|manager as well as user.id=41 maybe for scenarios where the main admin user wants to test some stuff or have hidden fields that other superusers can't see (though that's silly as other superusers could give themselves access anyway - just thinking of odd scenarios!).

Can anyone else think of uses for this?

[kongondo]

@Pete, I think that's a great suggestion. So, I guess that would mean an override of some sort or &&?  if a field is required and the user !== editor, then show field. Now that would take this to another level certainly...So would it still be called a required field? Yeah, maybe...required but only for certain roles...hmm...just thinking out loud (and sleepily )

[Pete]

Hmm yes, I hadn't thought of required fields (I was more thinking about field dependency in that if the user has a role then show that field) - required fields make it a bit trickier as all required fields should be shown of course regardless of the user's role or the page won't save.

That might be a useful thing to have in the future though for editing workflow - I guess a simple way of doing it might be something like this:

• The editor edits the pages they have access to - before the page can be saved, they fill out their fields.
• If the manager role can see other fields and one or more is required, when the editor saves the page in the step above it simply cannot be published, but it can be saved.
• When the manager finishes filling out the other required fields then the page can finally be saved.

Something like that might get around the issue.

[kongondo]

OK...going by your explanation, are you suggesting two separate dependencies here? One for required fields (as per Ryan's post) and the other for Access? Isn't the latter somewhat related to Ryan's module Page Edit Field Permission?