Thanks Nate, that’s exactly the kind of experience I was looking for.
Do you have any examples of the list comprehensions that you use? A pointer to the file on GitHub would work. That sounds like an elegant functional way to do it.
From: Nate Vogel [mailto:nathan.c.vogel@gmail.com]
Sent: Friday, September 22, 2017 11:56 AM
To: Steenhuis, Quinten ; docassemble@python.org
Subject: Re: [Docassemble] When to define a custom class
Hi,
I don't have a very technical answer, but my experience with this question might be helpful. I did make a couple custom classes for an interview I worked on for a while, and ultimately I realized it was more trouble than it was worth.
The custom classes became impossible to maintain. I couldn't unit test them in the Playground. When I was developing the interview locally and re-installing it after every change, it didn't make sense to clutter up my interview package with unit tests that couldn't run in docassemble. So I had my classes in a separate directory, and then I needed to copy them (yeesh) from where I was testing them into my docassemble package. And then I needed compress and upload the package, which is time consuming too. It was a very painful workflow.
Eventually I gave up and figured out how to just use DAObjects and DAListObjects to define my objects with whatever properties I wanted them to have, and all the logic for manipulating them stayed in the interview. I use a lot of list comprehensions now. And I actually think the code is a lot easier to read.
So the lesson I drew was that I'll try very hard not to attempt custom classes for future docassemble projects.
On Fri, Sep 22, 2017 at 11:22 AM Steenhuis, Quinten mailto:QSteenhuis@gbls.org> wrote:
I’m thinking about defining a few classes for the interview I’m working on.
1) DiscoveryRequest
2) Interrogatory – inherits from Discovery
3) InterrogatoryList?
4) DocumentRequest – inherits from Discovery
5) DocumentRequestList?
The objects should have a few properties: “Checked” to indicate if it should be shown in the template, “Name”, and “Description” to be used in the interview when showing a summary of the discovery that the system recommends the user to select. For Interrogatorys, they should each have a Priority. There should be a method for the InterrogatoryList class that displays only the 30 highest priority interrogatories to comply with discovery limits.
In the interview, I’d like to pre-define the 85 discovery requests with the name and description (I think as a source file?). I’ll also have a list that links each discovery request to a true/false interview variable. There can be a many-to-many relationship between the claims and the discovery request that’s relevant to the claim. I’m building the table with two columns right now in Google Sheets, but my plan was to convert it to a format usable in DocAssemble.
The example on the website for a custom object doesn’t define any properties, only the methods. I looked at the classes you’ve already defined in /docassemble_base/docassemble/base/util.py and it looks like again, mostly it’s just the methods you’ve defined. I only have a thought for one method so far. Is there any real benefit for me to define a new class for this example use? Would it make more sense to just use the built-in DAObject and specify the properties as I go along?
Quinten Steenhuis
Senior Attorney
Network Administrator
Greater Boston Legal Services
197 Friend St
Boston, MA 02114
(617) 603-1553tel:(617)%20603-1553
F: (617) 371-1222tel:(617)%20371-1222
Qsteenhuis@GBLS.orgmailto:Qsteenhuis@GBLS.org
_______________________________________________
Docassemble mailing list
docassemble@python.orgmailto:docassemble@python.org
https://mail.python.org/mm3/mailman3/lists/docassemble.python.org/
