Using a composite template - docusignapi

I'm trying to figure out when I need to set a sequence order# for a server template and whether I need to do the same for a composite template. Here is the problem I'm trying to address: my envelopes will have 3 or 4 documents, each document will have its own template. I will have inline templates for each document, it will be the same signer roles on each document. If I have multiple document/template pairs in an envelope, does that mean I have to use a composite template? If I am using multiple server templates for a doc, for example, is that when the sequence order is important? I just need to understand these composite templates more.

If I have multiple document/template pairs in an envelope, does that mean I have to use a composite template?
Yes.
If I am using multiple server templates for a doc, for example, is that when the sequence order is important?
Sorry I'm not an expert on this yet. There are several StackOverflow questions about Compositing Templates, check them out.
Also, what's best is to try out a test envelope. If it doesn't work the way you expect, then ask a new, specific, question about your code.

You must use composite templates. The sequence of the documents in the envelope will follow the structural sequence of your compositeTemplate elements.
Each compositeTemplate element has one or more serverTemplates and/or inlineTemplates. Each template element of those arrays has a sequence element with an integer value. These values should form a sequence within that composite, and determines the order in which a document is derived for the composite and the order of overwriting that takes place for other envelope elements.
The document contributed to the envelope by a single composite is either explicitly provided via the composite::document node, or if not present, by the first (lowest sequence value) template within the composite that can contribute a document, such as a serverTemplate document or an inlineTemplate::documents node.
Overwriting envelope elements follows the "last in gets final overwrite" approach. Thus the value specified in the last (highest) sequence template overrides all previously set values.

Related

Reusing a custom ContentPart in the same ContentType

I'm trying to figure out the best way to handle a requirement I have for an Orchard module I'm building.
I have a ContentPart that has a few fields. One field is a ContentPicker that allows for multiple items to be associated to the part. The rest are descriptive information.
The issue I have is that I actually need to be able to include more than one of this ContentPart into a ContentType. I need to create a ContentType that has exactly 3 of this part.
Should I be making this into a field instead of a part? Is it even possible to have a ContentField that has other fields in it?
Or, should I somehow use all the same models and data structures, but somehow define it as 3 distinct parts?
Just wondering what the best practice to do something like this would be.
You can only have one part of each kind on a given type. You can't have fields that have other fields in it (instead - take an existing field and extend it with custom stuff).
As I understand, the actual problem is "how to make groups of fields with some metadata for each group", right? If so, there are a few approaches to solve the problem:
Create a custom field based on Content Picker (basically - take existing Content Picker and extend it with your metadata) and use this without the need for a separate part
Create one part to hold only the metadata for each field attached to it and attach 1 or more fields to it
Create 3 distinct parts. Parts should be thought of as extensions that add some unique features to an item. If you think it's logically ok to have 3 parts then go for it.

Sharepoint Extenal List and Custom Field Types

I have an odd issue.
I have client that wants a sharepoint list what is populated from a WCFService. That part is working quite well.
I have a bdcmodel that is mapping the WCF data and I can create an external list from the bdcmodel as well so that is working fine.
The issue I have is that one of the properties in the model is actually a collection of entities called Attributes. The objects in this collection simply have 2 properties Name and Value so really they are just a key value pair.
The client wants to see the list of attributes of the parent entity in the external list. So there would be an Attributes column and within that column would be the list of attributes for each parent object.
Is there even a way to do this? I am looking into Custom Field Types, but it seems like these are really intended to be singular values.
How would I create a list within and external list?
Any help anyone can give would be great even if its just to tell me that there really isn't a stable way to do this so I can go back to the client and tell them we will need to build a custom list to support this because the OOB external list and custom fields and custom field types won't support this kind of nested listing.
I decided to set up the custom field as a string and when I get my collection in from the BdcModel I am serializing it to JSON and then passing it to the field. When the field is viewed in display, edit or new I have overridden the FieldRenderingControl and I am tiling the collection out that way.

Tagging schema for CouchDB. Would this work?

I am wondering if the following scenario would be amenable to CouchDB? I am building a web-based flashcard application. Users can create flashcards (question on one side, answer on the other). Flashcard authors and other users can tag flashcards with keywords/phrases. Users can retrieve/generate virtual stacks of cards based on tags including support for boolean search (tagA AND tagB NOT tagC OR tagD). The DB will store cards (obviously) but also “documents” for users, tags and potentially virtual stacks of cards. I have read other SO questions concerning tagging within CouchDB but am wondering if the following would work or be to write intensive … (1) Card documents contain JSON array of tag strings assigned to that card, (2) Tag documents contain JSON array of cards using the tag, (3) tag documents also have element to store count of cards using that tag, (4) whenever a new card is created or tag is added to a card, the associated card identifier is also added to the tag document and the tag document's CardCount element is incremented. (5) Permanent views of cards indexed by card ID and of tags indexed by tag string are generated. If I know the card ID I can find the document quickly and can quickly get a list of associated tags. If I am given a tag string I can quickly find the tag document and then get a list of card IDs using the tag. For more elaborate boolean search I can retrieve a list of card IDs for each tag in the boolean search and then figure out the union/intersection/etc of these sets on the client. Does this seem reasonable? I am aware of the fulltext indexing option using Lucene but would like to avoid this if possible. Thanks.
I don't see a good reason to make things that complicated - just create a document per card and add tags to these documents as you go along. Create a few stored views to count/show tags and their usage number when you need it.
this way you'll only need:
card document:
question
answer
tags[]
views:
show card info
show (perhaps most popular) tags
show cards per tag
As long as your documents are properly structured, you won't need full text search to handle everything.

Given an XSD is it possible to list a hierarchy of elements and their attributes?

Lets pretend I have an XSD document and I want to produce a list of all elements along with their attributes and the children of the elements. I could also approach this by asking if you are to implement code completion based on an xsd document, and you want to list the children of the element and an elements attributes, how would you approach this problem?
Since XSD is valid XML document it just a matter of selecting XML parsing library of your choice. For example XLinq (.NET FW 3+) will do the job.
You can just walk through complexType, sequence and other elements to find out a list of possible values.

How to find related items by tags in Lucene.NET

My indexed documents have a field containing a pipe-delimited set of ids:
a845497737704e8ab439dd410e7f1328|
0a2d7192f75148cca89b6df58fcf2e54|
204fce58c936434598f7bd7eccf11771
(ignore line breaks)
This field represents a list of tags. The list may contain 0 to n tag Ids.
When users of my site view a particular document, I want to display a list of related documents.
This list of related document must be determined by tags:
Only documents with at least one matching tag should appear in the "related documents" list.
Document with the most matching tags should appear at the top of the "related documents" list.
I was thinking of using a WildcardQuery for this but queries starting with '*' are not allowed.
Any suggestions?
Setting aside for a minute the possible uses of Lucene for this task (which I am not overly familiar with) - consider checking out the LinkDatabase.
Sitecore will, behind the scenes, track all your references to and from items. And since your multiple tags are indeed (I assume) selected from a meta hierarchy of tags represented as Sitecore Items somewhere - the LinkDatabase would be able to tell you all items referencing it.
In some sort of pseudo code mockup, this would then become
for each ID in tags
get all documents referencing this tag
for each document found
if master-list contains document; increase usage-count
else; add document to master list
sort master-list by usage-count descending
Forgive me that I am not more precise, but am unavailable to mock up a fully working example right at this stage.
You can find an article about the LinkDatabase here http://larsnielsen.blogspirit.com/tag/XSLT. Be aware that if you're tagging documents using a TreeListEx field, there is a known flaw in earlier versions of Sitecore. Documented here: http://www.cassidy.dk/blog/sitecore/2008/12/treelistex-not-registering-links-in.html
Your pipe-delimited set of ids should really have been separated into individual fields when the documents were indexed. This way, you could simply do a query for the desired tag, sorting by relevance descending.
You can have the same field multiple times in a document. In this case, you would add multiple "tag" fields at index time by splitting on |. Then, when you search, you just have to search on the "tag" field.
Try this query on the tag field.
+(tag1 OR tag2 OR ... tagN)
where tag1, .. tagN are the tags of a document.
This query will return documents with at least one tag match. The scoring automatically will take care to bring up the documents with highest number of matches as the final score is sum of individual scores.
Also, you need to realizes that if you want to find documents similar to tags of Doc1, you will find Doc1 coming at the top of the search results. So, handle this case accordingly.

Resources