Help with optional text.

[JohnG]

Me again. New question: I have a pretty large document with lots of optional text (probably 50 separate sections). Plus, within each optional text section there may be other options.

Most of the clauses are used regularly. Many are rarely used.

When I try to get it all working right, there is just a lot of 'stuff' on the screen. Any tips on how to clean it up?

Second question: Is there a way to test my work without 'destroying' it? (When I use the 'process' button, it asks me all the questions about keeping or deleting the optional text sections. When I answer the question, it removes the <<*Optional*>> frames. I end up with what I should, but the document no longer shows my 'setup' work.

Thanks,  John

[forum_admin]

    Great questions. Let me start the answer with a brief explanation of how Pathagoras is different from the other programs out there. We try to do everything in plain text. Not with hidden fields and not with hidden coding. All of the document assembly instructions are 'facial' to the document. That means that you can look at the document and see what each section and block is supposed to do.

    Yes it makes long documents even longer. If you have lots of nested <<*Options/Optional*>> blocks, the document could look quite busy.

    But the opposite (hidden fields, hidden coding, ancillary documents) is what the other ‘guys’ do. We have intentionally chosen this contrary path.

    However, we do recognize that there is a limit to the amount of ‘stuff’ that the eye and brain can process. When things get too busy, it is time to break up your documents into manageable sections. We therefore strongly encourage you to take advantage of ‘paragraph based’ assembly. (Pathagoras is unique in this approach.) See Document Disassembly discussion in the Manual.

    So instead of trying to put every possible option into a huge ‘template’ form, break the document into its separate components. Then use the Document Assembly button (the 2nd button from the right in the Pathagoras toolbar) to build the ‘perfect’ document for your customer or client instead of starting from an overbuilt document and pulling irrelevant pieces away. The result is the same, but we feel the road to getting there is a lot easier and ultimatley easier on your staff.

    Here are some concepts to keep in mind with regard to paragraph assembly:

• When you have a new clause you want to add to the system, you would just type the clause and save it out with the rest of the clauses instead of having to ‘work it in’ to the template.
• You can still embed <<*Options/Optional*>> text within any individual clause.
• You can still have boiler-plate type documents. Just create a Clause-set. (A Clause-set is like a complete document, but in fact it is just a table that points to the individual clauses that will make up a complete document.) The advantage of this is that if there needs to be a change in your future documents to reflect a statutory amendment, a company change of address, or a price or model number change, you need only change the text of a single  clause. All future ‘Clause-sets’ that build documents based on that clause will reflect the newest language. (Sure beats opening and modifying dozens of ‘whole’ documents.)
• If you have a good base document, but find that you need to add a clause or two from your collection of clauses, it is a piece of cake to do so. Just click it in from a DropDown List.

    Here is a list of other advantages of paragraph assembly.

Testing: The other part of your question dealt with testing your document to make sure it meets Pathagoras' construction rules. We recommend that you test by copying the entire source document, or that section of the source that you want to test, over to a separate document and test from there. It’s just a lot easier.