So I have created a page type, for content entry. The first part, 24 fields, sets up some headings and boolean fields that tell whether certain information and or buttons will be displayed on the page. This works fine and I can customize the input form just the way we want it. But the issue is how to now link in some one to many relationships. For instance alternate redirect urls, multiple content paragraphs. The idea is to have the same entry form for products as the users are currently using, the one to many escapes me. I am using the MVC dev end. I have created custom modules and associated web controls, but cannot figure how to add them to the page type layout.
Thanks in advance.
For the module tables to link to page types you need a cross-reference table. This table would hold say a GUID from the page type as well as a GUID from the module table. How you link the page type and module record could be done on the page type (while this would be harder) OR you could create a custom UI module which would allow users to view the linking table and add or remove records. This would be a listing of all the module table records and then allow you to select one module record and see or add many links to it.
Then in your page display, you simply do a custom query to that cross-reference table and join in the module table to get the data you need.
There are many approaches with pros and cons for each.
You can use Related Pages to relate to other pages that contain your content (such as a Page that contains paragraph information). My Relationships Extended Module can help with that.
You can use the content tree to store relationships, putting multiple items below the page and using the NodeAliasPath to find children of your certain page types (DocumentHelper.GetDocuments("My.PageType").Path(YourParent.NodeAliasPath+"/%"))
You can also use a multiple-selector, storing a guid or codename in a comma separated list on a single field (not greatest but it can get it done).
You can also create your own custom binding classes through the Modules, although you will need to make sure to configure things properly with the ObjectTypeInfo so it is handled properly in Kentico. Again the Relationships Extended module can aid in creating interfaces to maintain that.
See RelationshipsExtended
And also My Blog on this topic
And a presentation on different data modeling with pros and cons.
Related
I have a custom page type for employees, and one of the fields is Location. I want to show/filter only employees in "San Jose" or "San Francisco" and used this WHERE condition below but it didn't work. Apparently, I missed something very basic. Could you help?
Location LIKE '%San%';
I did another test, where instead of page type, I used custom table with the exact field names and was able to filter using the same statement. On a related note, I'm new to Kentico and exploring which is more suitable for creating/maintaining a list of about 100 employees - Page Types or Custom Tables - with the ability to filter by department, location etc. Appreciated your input here as well. Best!
If you're adding the WHERE condition into a standard Kentico repeater or other data source, the syntax looks right except you do not need the semicolon ";".
You'll also want to double check the field name, and if you are limiting your query to certain columns (as is best practice especially for larger data sets) and be sure the field you are filtering on is being selected.
Regarding the management of your employee list, either method you've described will work. In that scenario it typically depends on who will be editing the content, and how frequently. It is more editor-friendly, in my opinion, to add those documents into the content tree. This also gives you quicker control over the order, and keeps it similar to how other content on the site is maintained. I also like to set up folders or other parent page types as categories if needed, so the documents can be dragged and dropped between them and it sets up a visual taxonomy that isn't possible if it's all stored in a table. Storing items in the tree also allows for workflow and versioning, as well as more granular control over permissions/access, if this is important to you.
It's awesome that you are thinking about how to best store your data in advance. There many factors to consider such as overall number of records, number of columns, the fact whether you need to use workflow, versioning, preview etc..
The best source of information regarding this would be this article which summarizes all options you have and gives clear explanations of which to use in which scenario.
And to your original question - What components are you using to display the data? Is the repeater? If so, can you make sure to set the Page types property to match the page type you are displaying? If the page types is not configured, Kentico will not load any custom fields because it doesn't know from which table it should load the data from.
Additionally make sure to either include the "Location" field in the Columns property or leave the columns blank (not recommended because then Kentico loads all columns which is like 200. when you count all from CMS_Document, CMS_Tree etc..)
Below is the framework that I use to debug whenever I wish to add a repeater and is facing some problem.
First get all the columns instead of accessing limited columns. Fetching all columns will make sure that I don't have any problem retrieving data.
If I am missing any particular column information name, then I would double check the column name.
I verify this by firing up SQL server management studio and access data from page type table or custom table.
If access to SQL server is not available(generally in Azure hosted solutions with restrictive access to DB), I would enable SQL debug from the settings and see what query repeater is generating to see if it is correct.
I am using Visual Studio 2010, SharePoint 2010 with custom document content types and forms. And plan to also use jquery to build the document add/edit/view forms.
I am developing a solution where I want to have a document library where each document uploaded also has a number of external data elements added as metadata.
The tricky part I'm trying to figure out is I want the user to be able to specify and add a multiple number of those same external data elements.
I'm trying to figure out how I represent the data internally in SharePoint. My initial thought is to programmaticly add hidden external fields as the users adds those external selections. But then I also think of simply storing those external elements as non-external text fields but have my own code which performs the external data lookup and validation.
I'm not adverse to significant custom coding, as I'm probably going to need to do a lot anyway since even the user interface is going to be a jquery tabbed form to enable all the external data the user will be able to associate with each SP document.
I've made an attempt to hopefully further explain what I'm trying to do and included that image. Essentially I'm wanting to add 1+ external data relationships to each document, as desired by the user.
It uses just example data. I'll actually have 4-7 different complex relationships much like the example. And the user is permitted to drilldown and select 1, 2 or all 3 of the dropdowns.
Think of it as similar to how here on Experts-Exchange we can add multiple zones to a question.
An example illustration is here: http://flic.kr/p/aFUSJn
Could you simply add a multi-line text column and have the user input the metadata with comma's, then use your code to seperate the data and do what you want with it?
You said you were not adverse to significant custom coding :)
One solution is to use SharePoint content types. The trick is that not all items in a list need to have the same content type.
Therefore, you can do the following:
As the user is selecting the fields he wants to use you generate or select a content type that matchs those fields.
You then add your document to the document list using the content template
You then have all your information strongly typed in SharePoint lists.
We have previously built a system where we generate content types based on xsd files, this worked very well.
I have a SharePoint list that has MANY columns in it. The default AddForm and EditForm rendering is very cumbersome for the users. Most of these fields hold simple Number (integer) values. The default rendering for those two forms (using the ListFieldIterator I suppose) render the columns one by one vertically down the page. My thought was to design an input form with three basic "zones" (left/middle/right) and use a Custom Field for all of these "Number" fields. The Custom Field would contain two custom variable properties "Zone" and "Order". (Zone could contain middle/right and order would be the "order" in that zone the field would appear, the "left" zone would be for the fields that are not these "Number" fields, things like Date, Customer, etc. etc.) I would design the page with an HTML table and 6 Columns (1 for the "label" and one for the "TextBox" for each of the three "zones"). Then I could put a control (something similar to the "ListFieldIterator"). The control in the first zone would render the "static" fields, the zones in the other two zones would render the appropriate Custom Fields (based on the Custom Variable Property "Zone" and "Order").
Does this make sense? For the life of me, I can't figure out how to do this. I had thought about "giving up" and just using my ASP .Net skillset and creating FormViews and GridViews bound to the proper (ListView) DataSources. That has even proved challenging.
Does anyone have any ideas on how I could accomplish this? (InfoPath isn't an option and I want to stay with the "Custom Field" idea so the fields aren't laid out statically and can be moved around or even new ones added by the "administrator" of the Application (SharePoint List).
Any guidance is MUCH appreciated. I have been working on this all week and just seem "stuck".
Thanks,
Shayne
------ A Better explanation of my "application" and what I want to do-----
I have a SharePoint List that has about 60 fields in it. If I pushed this application out using the default Add/Edit SharePoint List Forms (and Rendering Templates), the users would hate it. The default forms use a rendering template that basically lays out all the list fields, one per (HTML) Row. Within that Row there are two (HTML) columns. The first one contains the "Label" for the field, and the second (HTML) column is the actual editor for the "FormField" (Text Box or whatever). Because of the number of fields in the list, the user would have to scroll several pages just to get to the bottom.
This list has about 10 "static fields" that I want to lay out on the left side of the page and then about 50 that are simply "task" fields. These store an integer and track "how many of these tasks did I do today". (This is a "port" of an MS Access application.) Depending on the "Add" page the user selects (I have a "parent" content type that contains every field and then a "child" content type for each "group" of users that will be using this form that contains just the fields/tasks that group tracks) the proper fields are rendered on the page. The problem is they are all rendered vertically and there is too much scrolling. These users (and admins) will NOT have access to SharePoint Designer or InfoPath. So, the "layout" for these fields must be iterator/repeater style (the users shouldn't have to get Development involved just to add a new "task" field to their application!).
The solution I had come up with is to use a Custom Field Type with two Custom Property Variables for each of these "task" fields. The Custom Property Variables (Zone and Order) would allow the administrators of the "application" to control where they want these fields to appear on the Add and Edit forms. The Zone Property can contain one of two values: "1st Task Column" (middle of the form) or "2nd Task Column" (right part of the form). (The "left" column of the forms would be used for those 10 or so "static" fields that all groups/depts/content types share.)The Order would just contain the order to sort the fields in, within their "zone". Obviously, the "zone" would indicate where on the form the field would appear (middle or right). I thought I might be able to use three Divs and render the appropriate List Columns in the appropriate DIVS. Or, following the default rendering template, instad of DIVs I could possibly use 6 (HTML) Columns instead of 2.
I quickly figured out how to make a new Field Type with Custom Properties (I used the Property Schema element in the XML definition, even though Microsoft says NOT to use that in SharePoint 2010, it was just so easy and I couldn't figure out how to add them otherwise. Now I know how to add them the "right" way, I just don't know if it is worth changing them.)
For the last few days, I have tried to figure out how to actually render these "zones". Remember, I want the users of this application to be able to add new fields dynamically, so I can't put any static field references in these forms. I have read about the Rendering Templates and the ListFieldIterator (and the new Content Iterator), but I can't seem to pull it all together and create an actual solution. The part that is throwing me off is how to query and render three different "sets" of fields at once (since the rendering is going to happen from "top to bottom").
Any help is very much appreciated!
Shayne
If InfoPath it out and you want to stay within the SharePoint infrastructure for forms, then the term you need to search for is DataFormWebPart. You may have heard of DataViewWebPart before, well this is the form equivalent. Just like the DVWP, this does lots and lots of XSLT to make its magic happen.
The trick is can you implement your grid/zone idea within the context of the DFWP's XSL. That I can't tell you but hopefully this is a starting point.
Defiantly Info Path is the solution here are some tutorials:
Video: http://channel9.msdn.com/blogs/laurhar/infopath-2010-customize-a-sharepoint-list-form
http://p2p.wrox.com/content/articles/customizing-sharepoint-2010-list-forms-infopath-2010
http://blog.libinuko.com/2010/03/21/sharepoint-2010-howto-start-customize-list-form-neweditview-using-infopath-designer-2010/
if you don't want to use InfoPath I would recomment JavaScript/jQuery you have just to modify (Edit) the page then inject some jQuery code to do what you want. Here are some articles about similar topics:
http://akanoongo.blogspot.com/2008/04/how-to-hide-fields-in-sharepoint-list.html
http://spground0.blogspot.com/2011/03/sharepoint-2010-custom-list-form-issues.html
http://ghamson.wordpress.com/2011/01/19/using-jquery-to-attach-regular-expression-validation-to-a-sharepoint-list-form-field-sp2010-ps2010-projectserver-in/
The only way you can achieve this type of custom form designing within the SharePoint framework is to apply it through post-rendering techniques using client-side code. And solutions like this tend to add considerably to page-load.
Simply changing the render template is not enough if you want it to be a dynamic and codeless experience for end users to author.
I can think of only one solution which comes close to fitting all criteria. It's "free", can be password protected, and also allows tab groups, rules and many other settings.
Dynamic Forms For SharePoint - http://spjsblog.com/dffs
Lets say for example, I have a list of products that each have it's own page... in what way can I create a single page that will list each product as it's contents as a list (with hyperlinks)? Not really sure how to do this directly in Orchard - or will I need to create a custom page / widget? Thanks for any help... new to Orchard and not sure how to tackle this.
You have a couple options. I believe the Orchard gallery at orchardproject.net has a module called Simple Commerce that may solve your problem. (it's simple so it might not)
(In the following section, I've tried to boldface the terminology words that are 1) are crucial to understanding how to use Orchard and 2) helpful in finding your way around the dashboard)
Another option may be first creating a Content Type--probably one named Product with some Fields describing an individual product. Price, SKU and description come to mind, but you'll be better able to describe your own products. Each Content Type in Orchard can be associated with any combination of Parts. You may have to research which ones you actually want for an individual product, but I'd recommend:
Body (this could replace the Description I suggested above) You could include any amount of HTML/script in this section to make your individual product pages look fancy!
Common (this has to be added when Containable is used)
Containable (this will allow the items to be listed)
Route (so you can link to a specific product)
This gives each product its own slug (URL)
Tags (to allow products to be categorized)
Now, you need to create a new List from the dashboard so you can display the products together (and inherit other features like pagination, etc). Be sure to select the Product Content Type in the Contains drop down list.
Then, you can start creating your Content (your Products) one by one. In the dashboard, click the new Product item and describe each new piece of Content.
Finally, you can link directly to this new List using the Products List's *slug*. You could (and might want to) add the Products List to your main navigation menu. Clicking the Products List and checking the "Show on main menu" box will automagically add a navigation button directly to this page. You could, of course, link to this List from anywhere using the slug (also found on the list's edit page)
This page, from the Orchard documentation pages describes more things you can do with a list of content like modifying the layout of the list, placing content fields in different places and even converting your products to widgets which you could use to display some promotional product offering in a special spot on your site.
I highly recommend reading through at least the documentation provided on the Orchard site to get a good grasp of what this CMS can do out of the box and what you would need to write custom code to accomplish (which you could do in this case, but Orchard can handle it out of the box)
Hope this helps!
Two ways to do this:
http://orchardproject.net/docs/Creating-lists.ashx and http://orchardproject.net/gallery/List/Modules/Orchard.Module.Contrib.Taxonomies
I've got a custom list with a custom content type. I'm aware that when you create a new item you can see a drop down for the different content types on that list which I assume all have their own NewForm.aspx somewhere. I can specify in the content type definition which columns are shown on the New form and that I can replace the new form with a custom one of my own design.
What I'm trying to achieve is to have multiple New forms but for the same content type listed on the New drop down. I would like each new form to expose different fields of the content type. Additionally I'd like to make particular New forms only visable by users with particular permissions although this isn't critical.
Scenario:
I've got a content type with all the fields I need for a risk assessment. When a new item is created it only exposes fields to enter contact details. Once this is created a workflow with infopath forms then drives the gathering of the rest of the risk assessment information through booking, the inspection itself and approval of the data. I want the ability to have a second option to easily enter all this information on a different new form for an inspection that's already been done and needs logging in the system.
You could customize the NewForm.aspx (e.g. via SharePoint Designer) for the initial submission case. Obviously, all of the required fields will need to be populated in some fashion.
The EditForm.aspx is the out-of-box page for updating existing list items. You may be able to customize this to meet your update an existing risk assessment case. From the post above it's not entirely clear to me whether this distinction between these pages is fully understood.
In both of these cases, you can add code-behind to the .aspx pages. However, it's usually best to start as simply as possible, keep it as simple as possible and only add complexity as necessary.
Hope this makes sense and helps. Good luck!
Dan,
Per your scenario, I have done something similar by creating one content type per actor/stage. Consider using a simple SharePoint Designer workflow to change your content types onChanged (simply by setting the Content Type) column so that the perspective actors only see the columns you want them to see in the edit/newforms. As long as the proper content type is set, your users will only see the fields you want them to see. Furthermore, with creative use of views and audience targetting of pages you can somewhat prevent these users from seeing columns.
Also, you can prevent users from seeing the different content types (under the new button) in the advanced content type page.