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
**********************************************************************

Reply via email to