Just to chime in with my Belizean penny worth… (less than a Canadian penny)
We have several forms that are used as the form for all tables. There are full suites of buttons on these project forms. For these buttons they all call a Project method. Within these are a case of statement that calls the appropriate method for the method. This creates a very standardized forms, and behavior for the user. I agree that if the same code block is going to be used more than once, it should be placed into a project method. I would hate to have a hard and fast rule for an object to never have code specific to it in it. That just makes for harder work on our part. In our form methods and object methods we will call project methods for blocks of code that we use often. This means that those methods get called a lot. We know they work. When we read through a form or object method we recognize these often called methods and breeze right on by. We understand what they do. Being able to quickly read through a method and understand what it is doing (hopefully description in the comments at the top too), makes making enhancements and bug fixes much easier. Sometimes a project method we call might have some sophisticated code in it. Having that block of text in every form method would be horrible. Of course in my hobbyist opinion… Jody > On Apr 25, 2019, at 8:22 AM, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Chris B made the below statement about project methods. > > from a 'classic' 4D pogromming view, IMHO - which may mean nothing :), > this is not the approach I use or advocate. > > I do use object methods - but - only to call project methods which do > all of the actual work. > ex: accept button script > // accept button script <[table].form.object> > tablename_entry_accept > // end accept button script <[table].form.object> > > the project method tablename_entry_accept will do data entry > validation, messaging about entry failures, related record existence, > calculations that need to be done etc. and usually an ACCEPT > > > Why? > Deduplication of code. Code should NOT be repeated. In the above > example, the code to accept the form maybe reusable or be made more > generic (with parameters). If the code for this accept button was > placed in the object script - I might end up re-creating/repeating the > code elsewhere (even to the point of copy/paste). > > At some point in the future I might need to change the logic/code. Then > I would need to find all instances of the code through out the system, > to make the change. If the system is NOT one I wrote, or it has been a > long time (3 days?) since I worked on that section I would/might not > know where all instances of the duplicated code are. > > If the code is in a project method, I can make the changes needed in > one place, done. > Also - code in scripts is harder to find/maintain. > > Some people in the past have advocated for removal of all object > scripts, placing the code instead into the form method (or better the > project method called by the form method). I do not personally do this, > as I looked at it once and, to me, the resulting code was too long and > not clear -- of course maybe I was not implementing the idea correctly > or completely :) > > just my 2 cents > > Chip > > > On Wed, 24 Apr 2019 22:37:51 -0600, Chris Belanger via 4D_Tech wrote: >> >> Another use for it that I have not explored yet is to have a chunk of >> code that gets run under several different circumstances, but which I >> don’t want to make a dedicated Project Method for it. >> I prefer to reduce the number of Project Methods while, of course, >> creating ones that make logical sense (as they can be called in >> several places in my code). But you understand that as a programmer. > --------------- > Gas is for washing parts > Alcohol is for drinkin' > Nitromethane is for racing > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
