I have a db with a template view and a template form. A setup doc must automatically create a new view and form based on the templates.
For the view, it works 100% with CreateView
But I can’t find anything similar that will so the same for the form?
Any suggestions?
Thanks
Brad
Subject: Create form from template? Like CreateView?
Why are you using code to create what sounds like copies of a view and form? Why not make the db holding the ‘template form and view’ into a template (ntf) and just create a working db from the template - the new db will have both the form and view. You can write code to make new dbs from defined templates.
If there is something more complex going on here, can you define what you’re trying to do? (not how you’re going at it but what is the requirement - what are you trying to achieve and why).
HTH
Doug
Subject: RE: Create form from template? Like CreateView?
Yes, it is more complex than that.But, your post got me thinking…
I definitely need to be able to create multiple views in the same db based on a view template. That’s ok, because I’ve got code that can do that.
But I’ve done some clever stuff with the selection formulas that allow me to use one form.
In the end, in terms of the complexity of my db, the logic for this function is actually quite simple.
Thanks for changing my chain of thought!!!
Subject: After the tease - ya gonna show anything?
Clever stuff?
Share Share…
Tis the season for giving so give it up!
Please…
Doug
Subject: RE: After the tease - ya gonna show anything?
Well, it’s pretty complex, but it’s going to make my life much easier if I can get it right.
Most of the development I do is workflow based. So a form goes through various levels of approval / signoff. It’s not difficult to code this workflow, but it is rather tedious. Especially with action buttons, hide/when, and all that good stuff. It’s fine when there are only a few levels that the form goes through, but when you get to 20 levels it becomes a problem.
The logic is similar between all these forms, so I’m trying to create a “template type” db that will accomodate any number of levels automatically without me having to re-code each form. Basically, I have a doc for each level required, which includes all the possible options when it comes to routing.
This includes things like, authoriser name, must it email, who must it email, who must it go to next, time limits, etc etc etc. As you’d know, there are lots of variables built into workflow, and I’m including all of these in my “levels” doc. I’m also including all the action buttons and fields that would be needed so I don’t even have to add those when I’m designing a new app.
Essentially, I’m cutting out all the workflow development time for each of my apps if I get this right. Then I just focus on the actual information required in the app. Like I said, when it gets to 20 levels, an automatic system will make life much easier! Another bonus is that I can run through the levels set up with the people involved in the process. It forces them to identify the correct workflow. Nothing worse that setting up a complex workflow, only to find that they forgot something! It will also allow for a “responsible” person to make modifications to workflow with me having to program it - I think that’s quite powerful.
Hope it makes sense! It’s a pretty big job, and I’m looking forward to testing it. You’ll probably turn around and tell me that thousands of people have already done it and it’s nothing new to you! But that’s ok.
Hope I haven’t disappointed! I’d be interested to receive any comments.
Cheers
Brad
Subject: RE: After the tease - ya gonna show anything?
OK, that makes a bit more sense.
There are 3rd party workflow tools that automate most of what you’re trying to do. If your company does cost/benefit type analysis, this may be one of those places where buying is cheaper than building.
Most of my apps include workflows. Most of the apps are fundimentally different so I need to build each workflow independently.
The closest I’ve come is an app with two main paths through the system, each with a set of mandatory forms. In this system, I associate each form with a workflow (or workflows), then initiate the workflow by filling in a request form where the workflow is selected. The process then creates a set of docs based on the workflow and pre-fills any static information into each doc. The workflow is finished when all docs are signed. A new workflow would get new forms.
Form Parent - all workflows
Form 1 - workflow 1
Form 2 - workflow 1, workflow 2
Form 3 - workflow 2
Request workflow 1, get docs based on Form Parent, Form 1 and Form 2
Request workflow 2, get docs based on Form Parent, Form 2 and Form 3
Docs based on Form Parent can’t be signed/closed until all subsidiary forms are signed/closed.
Now I’ll try and really confuse you.
The app is based on the idea that each ‘step’ in the process is fundimentally identical to every other step except in the details. Each step as a name, an inidividual assigned to manage the step, due dates, completion dates, and maybe some free text.
Since each step is the same, there is really only one form.
There is a method to create a name for a step, define which fields are displayed when that name is used, and change the boilerplate text next to a field.
SimplifiedEX:
On this form are three fields
Field ‘stepName’ - there is a view listing all possible steps. Let’s say we build a doc with ‘stepName’ = “Vacation - manager approval”
Field ‘displayApproverTitle’ - cfd, derived from the view listing each possible step and the defaults for those steps. For the step ‘Vacation - manager approval’, this field would display ‘Manager’.
Field ‘Approved’ - maybe a checkmark.
If I create a second doc where ‘stepName’ = ‘Vacation - director approval’, the ‘displayApproverTitle’ would now say ‘Director’.
You fill in a top level parent doc with some demographic data and a way to define the specific workflow, then run a process to spawn child docs for that workflow. The docs are all copies of a single form, one for each defined step in the workflow, each with apparently unique form fields, but actually all the same under the hood. You can show/hide fields, make some mandatory for specific steps, whatever, all by just managing the definitions for each ‘step’.
Fully implemented, the developer isn’t even involved. The owners of the system just create the defaults for a workflow and the right set of child docs is spawned for each workflow. In actuality, setting up the defaults is complex enough that I keep getting dragged in, but I’m building docs, not changing design so the process is much easier to manage.
If this sounded interesting but not terribly understandable, let me know and contact me off-line (email at my profile link). I’m out of the office until 2.Jan so don’t expect an immediate response but I will get back to you.
Doug