Develop Reference

Kofax Export Connector - get value from IndexField

I created a mapping for my Kofax Export Connector. This connector interacts with an external application using webservices.
I want to connect the indexfield values to field IDs of the external application. Currently I have a dictionary containing the ID of the external application and the index field ID.
Dictionary<double, double?> // external fieldID <-> indexfieldID
The key is nullable because a field might not be assigned. Instead of passing the indexfieldID to the external application I want to pass in the value of this indexfield.
Currently I have this
releaseSetupData.CustomProperties.Add("MetaFieldID", "IndexFieldID");
and the desired result would be
releaseSetupData.CustomProperties.Add("MetaFieldID", "IndexFieldValue");
How do I get the value of the index field? The indexfield itself has no "value" property and the Kofax user is able to setup a custom field with a custom dataType. So how would a value look like?
I don't get it from the Kofax Capture Export Type Library API Reference Guide

Generally speaking, Kofax organizes any kind of mapped data as so-called Links. However, it does not take care of mapping anything on its own, that is our job (for some reason). You will find two different objects at your disposal:
Your setup script will contain a reference to a ReleaseSetupData object, usually named SetupData.
Your release script has another reference to a ReleaseData object, namely DocumentData.
Now, all links established during setup time will become available during release time. Said links can contain different kinds of data, for example index fields, batch fields, Kofax values, or custom properties. Now, let's say you have the index field "FirstName" on your document class, and you do want to access its value during release time - here's what you need to do.
Setup Script
setupData.Links.Add(
setupData.IndexFields["FirstName"].Name,
KfxLinkSourceType.KFX_REL_INDEXFIELD,
setupData.IndexFields["FirstName"].Name);
setupData.Apply();
Please keep in mind that those links are similar to dictionary entries, so you can't link the same item twice. I usually like removing all links when my setup script loads, and add them again when it unloads again (and note that you can safely loop over the setupData.Indefields collection to add all fields instead of just a single one).
Release (Run) Time
During release, all links are then made available in the DocumentData.Values collection. To access your index field and its value, here's what you need to do. The following assumes you already set up a Dictionary<string, string> named IndexFields, and it further shows you how to access all other kinds of links (batch fields, custom properties, et cetera):
foreach (Value v in DocumentData.Values)
{
switch (v.SourceType)
{
case KfxLinkSourceType.KFX_REL_BATCHFIELD:
BatchFields.Add(v.SourceName, v.Value);
break;
case KfxLinkSourceType.KFX_REL_DOCUMENTID:
break;
case KfxLinkSourceType.KFX_REL_INDEXFIELD:
// index fields may also contain table fields
if (v.TableName == "")
{
// this is a regular index field
IndexFields.Add(v.SourceName, v.Value);
}
else
{
// this is a table field!
}
break;
case KfxLinkSourceType.KFX_REL_TEXTCONSTANT:
TextConstants.Add(v.SourceName, v.Value);
break;
case KfxLinkSourceType.KFX_REL_UNDEFINED_LINK:
break;
case KfxLinkSourceType.KFX_REL_VARIABLE:
break;
}
}
If you wanted to map Kofax Index Fields to some external ID, you could safely do so using Custom Properties. Example: you can assign the id 42 to FirstName during setup (just create a property grid with a custom class), add the Custom Property during setup time, and then access its value during release. That way you could maintain ids via the setup form without the need to ever rebuild your solution.

Sitecore - Programatically modify the source field of a template

Currently, all the templates that we have created have source fields whose path is a string.
e.g. :
"sitecore/content/Test"
Now if I want to move the Test folder to
sitecore/content/Shared/Tags/Test
the links are broken.
If i manually change this to use the GUID (Using the build option), I get :
datasource={62CF8494-B148-4B2E-9D36-52EC4CD75E13}&database=master
If i now move the test folder around, my links remain as is.
I wanted to write a routine that runs through the tree and updates all the source fields for my templates (in a particular folder only), to contain the GUID and db name.
Is this possible?
I tried doing this in the Process method of a class that inherits from PublishItemProcessor and added the appropriate entry in the web.config. This method is called, but the Source property of the field is read only and cannpt be modified.
Any ideas?
Thanks in advance.

The best/most efficient option here would be to use Sitecore Powershell Extensions to modify the items.
This is a good reference point: https://sitecorepowershell.gitbooks.io/sitecore-powershell-extensions/content/working-with-items.html
You could also do this in code.
You need to write a routine (code or SPE) that starts with the /sitecore/templates/user defined or whatever your root folder is.
Recurse thru the tree and get all items that have the template: Template Field. Then you can check value of the the Source field. If it is the one you want to change, update the value and save the item.
Remember to publish the templates tree after updating all the values.

Dynamic column datagrid in wpf

I have a case where in the columns of Datagrid are not fixed . i.e it has to be generated depending on some conditions.
How can i store the values in the DB and display the datagrid with them using MVVM pattern.
P.S : I have a main grid and a sub grid and depending on the value he chooses in the main grid i need to form the below grid. My concern also in storing it in the DB, since there can be 5 columns or sometimes 20.
Any similar links or references will also be useful.

This can be totally done in an MVVM compliant way, but isn't necessarily trivial for a beginner, and isn't appropriate for simple applications.
One approach I like to use is to keep a collection of column descriptors serialised in the database1. The column descriptors are simply my own custom DTO data classes and contain properties related to a column, i.e. width, column type, whether it is visible, whether it's visibility can be toggled, it's ordinal, etc. This is all done using simple structs and or primitive .Net types, but specifically doesn't have any UI related data types in it at all2.
This list of ColumnDescriptors can then be serialiased to and from XML, and stored in the database either in an nvarchar or XML column. Especially on SQL Server an XML column is better as you can natively query deep into the XML structures stored in the database column.
As it is a UI layout thing, it is up to the view to query the right set of column descriptors from the database, I then pump that collection through a static GridColumnFactory class which iterates the descriptor objects and creates me the appropriate grid columns and assigns the appropriate values to them. Once the factory returns that collection the view can then add them to the DataGrid's columns collection.
The benefits of this approach:
If I swap out the DataGrid that is used (i.e. swap from one vendor to another, say DevExpress to ComponentOne or native WPF), I can simply change the types of columns returned from the factory class
If I swap anything in the UI then I don't need to touch the column descriptors that are stored.
Serialising to and from XML means that if I do add/remove properties from the descriptors then older stored copies can still be accommodated, they aren't instantly broken the moment I release an update
One of the best features of all is that I can change the stored column layouts with a simple SQL statement, I don't have to also release compiled code
One last thing - using column descriptors makes it trivial to implement a user specified layout, i.e. when you let them drag columns around and then want to save the layout for next time
If I want to get really funky, the column descriptors can be returned from a webservice
1 For a website these could also be stored in a loose XML file which is then read in and kept in cache.
2 For this approach you should always avoid using specialised or vendor specific data types, as they don't necessarily serialise well (if at all), and will become a weak point in the future - these will be the most likely things you have to change, and if these change you break any stored descriptors you've already got.

asp.net mvc ways for generating dynamic form fields at runtime

this is the more or less the schema i want to generate my dynamic form on based on the fields above. i am going to add the direction , max size, default value and like wise some more fields in it. i am looking for recommended ways and methods in asp.net mvc for generating dynamic fields at runtime.
1) if i design my own engine for it then how? i am interested on that also but this is the last thing i am looking at. method to apply validation is very important in my scenario
2) any framework that may lessen the working time? or anything else?

I'll describe the generic approach, I don't want to code it for you.
Create meta class to describe each field (type, name, maxlength, null value handling, data source for combos, etc.)
Load the data from database and preprocess it
Populate the ViewBag with sanitized values
Create helper that will generated the control specific code
Html.ControlFor("Name", metadata);
Loop in view over the metadata collection.
which will generate textbox, combobox, etc.
Remeber that MVC form handling works over list of key-values, it's the Binder feature that converts it to objects. Saving data won't be difficult (dynamically created INSERT, UPDATE statement, ...).

Storing list of parameters in database

I want to store list of parameters (that will define how document is going to be generated on the web page) in data base.
There is a number of item (or document) types, each type has a different set of parameters that vary (each type has it's own parameters).
Is it a good idea to store all parameters (key-value) as JSON in table's column?
Otherwise I would have to create Parameter Table for every Type and column for every parameter (10-30 params for every type).
A note: I am not going to search by parameters or something like that.
I will load the the JSON string (if I'll choose JSON), serialize it to Object and apply them on document as usual.

Since you have no requirement of searching by parameters, To me Json seems to be more robust because you will have Object ready with information when you Deserialize it. where as if you store it in columns and table you will have to initialize class members yourself. It will also have performance benifit as there will be only one column to fetch based on your document type.
Conclusion go with Json data in Database

Sounds like you should have a look at http://sisodb.com. However, it does support querying, but that is something you could turn-off and only rely on GetById.