On Tue, Nov 8, 2016 at 3:43 PM, John DeSoi <de...@pgedit.com> wrote: > > > I often get this question (should I move my object method to the form > method), > > my answer is always "no", it is simply bad design. > > Well, it is also bad design to if you have hundreds of boolean fields and > you have to add a script to every single one just to determine if a user > changed the value. And if I forget to add the object method, now I have a > bug. Every object that has data to change should support On Data Change. >
This is the sort of case where I think it makes a lot of sense to have a project method in the object. First you only need to code one object and then duplicate that object n times - manually or by code. Second you can logically group the objects by the name assigned to them to enable/disable entire groups with a single statement. Third is you only have a single method to debug for the n objects. The naming aspect is really a benefit for me. Imagining the form you describe with many checkboxes and assuming they all represent a boolean field. One approach is to put each of these fields on a form. Another is to put a single checkbox variable on the form with a project method. On load you duplicate the object n times naming it something useful. This could be the field name, for instance, or it could be some other naming scheme that allows you to know the referenced field but take advantage of things like enabling or disabling groups if you needed that. By knowing the name of the object in project method you can check, uncheck, error check and save the user choice. -- Kirk Brooks San Francisco, CA ======================= ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************