In Orchard database, there is tables name ending with 'Record' and other with 'PartRecord'.
What is the logic behind that?
The tables for a part record should end in "PartRecord". If a table ends in "Record" without "Part" in front, it shouldn't map to a part record. For example, "ContentItemRecord" is a record, but not a part record. ContentItem is not a part.
Content part records are record classes that store content part data in the database.
While its not mandatory to have a part and a part record, it is a good practice to split the real data model (the record) from the model you are going to manipulate and/or read (the part).
The naming of the tables are all up to the module developers, but usually they are postfixed with PartRecord.
Looking at my Orchard database, I do not see any tables ending with Part. My guess is that with your application they are custom modules or third party modules, where the developer chose to postfix it with just Part.
Related
I'm trying to create a content part in Orchard that will perform a request to a web server and display the results of the request. The problem I'm running into is that my part requires no user input and thus I have left the part and part record classes empty. I have a Migrations.cs file that adds a description to the part and makes it attachable as well as creates a content item with the part attached to it. When I go to create a new instance of my content type it tries writing to the database and fails. How do you create a content part in orchard that doesn't try to save to the database? Thank you.
The actual error I receive is:
null id in Orchard.ContentManagement.Records.ContentTypeRecord
I'm pretty sure you don't need to create new table since there are many parts which don't have any in Orchard. Try to remove MyCustomPartRecord.cs and change MyCustomPart.cs
public class MyCustomPart : ContentPart<MyCustomPartRecord>
to
public class MyCustomPart : ContentPart
Then just add driver and view and you should be good without extra tables ... In theory :D
The answer to my problem is even when your part ins't actually saving anything in the database you still need to include a table for the part so it can store the id. I just added the following to my Migrations.cs file and it fixed the problem.
SchemaBuilder.CreateTable("MyCustomPartRecord",
table => table
.ContentPartRecord()
);
I created a basic OOTB document library to store Word and PDF files. I have been tasked to also create a few columns to store some basic metadata about the uploaded documents, for example: AuthorFirstName, AuthorLastName, and a column that lists "topics" discussed in the document.
While I am generally familiar with most Document Library settings, and creating columns, I am seeking information on what column datatype might work best for "topics". In most situations, one uploaded document would have 1-4 topics.
I would rather the datatype not be a single line of text datatype, as I would rather not ask the user to separate the different values (topics) using a delimiter such as a comma or semicolon. I would like to offer users the option to sort or filter in the SharePoint views.
There also seem to be some limitations with the Choice datatype.
While Choice fields seem to support Fill-In Values, when a choice is not pre-populated, they only seem to allow 1 fill-in. I would like the user to able to use a repeating-table-like interface to add a topic, and click an "add" button, and repeat, and so on.
I think in your scenario the best approach would be using managed metadata feature (http://office.microsoft.com/en-us/sharepoint-help/introduction-to-managed-metadata-HA102832521.aspx). It allows you to sort/filter library items, allows users to add new terms into metadata storage, etc.
Using a Lookup field to a custom List is something worth considering. The main advantage is that your data choices are stored separately from the main list and are easier to track and manage. The disadvantage is that you cannot easily have the user add a fill-in option as you desire. You would have to have a link from the library or the upload form to the options list where they would enter a new option separately from tagging it on the document.
Managed metadata is certainly an option as well, but it requires more overhead and sorting/filtering on that is a little trickier. Using a Lookup column is simple, although it does not meet all of your needs.
I am trying to write an application which accesses Notes databases through the C API, this works so far as I can get the list (summary info) of the notes in a view or folder with NIFOpenCollection() and NIFReadEntries().
However, this will return the notes in a seemingly arbitrary order. How can I retrieve all notes in a view or folder, sorted by a specific column? NIFSetCollation() doesn't seem to help with that, as it only allows to specify a collation/order which is already defined in the template(?).
The collation has to have been previously defined in the design of the NSF file that you are accessing. I.e., NIFSetCollation should work, but you have to have laid the groundwork for it first. Normally, one would do this by using Domino Designer to set up the column sorting for the views that your code is accessing. It would be far more ambitious to try to actually write code to set up the collation in the view from scratch.
(BTW: A template is a separate file, usually an NTF, from which an NSF can inherit design elements, including column sorting for views. But this is not a runtime relationship as far as your code will be concerned. Templates are not relevant here.)
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.
I am designing an application that will display dynamically-generated forms to the user who will then enter values into the form fields and submit those values for persistence. The form represents an employee evaluation.
One use case allows an administrator (from HR) to define the form fields. They should be able to create a new form, add/remove fields from a form and mark a form as 'deleted'.
The second use case is when a manager views the form and enters values into the form fields for a specific employee. They should be able to save the values at any time and recall the saved values when viewing the form again for the same employee.
Finally, when the manager is satisfied with the values they've entered for that employee, they can 'submit' the form data which persists the flattened data into the data warehouse for reporting purposes. When this is done, the 'working' copy of the data is removed so the form will display empty the next time they view it for that employee.
I am not concerned with the front-end at this point and working on the back-end service application that sits between the client and the data store. The application must provide a course-grained interface for all of the behavior required.
My question is how many aggregate roots do I actually have (and from that, how many repositories, etc)? Do I separate the form definition from the form data even though I need both when displaying the form to the user?
I see two main entities, 'EmployeeEvaluationSchema' and 'EmployeeEvaluation'. The 'EmployeeEvaluationSchema' entity would have a collection of 'FieldDefinition' value objects which would contain the properties that define a field, the most basic being the name of the field. The 'EmployeeEvaluation' entity would have a collection of 'FieldValue' value objects which contain the values for each field from the definition. In the simplest case, it would have a field name and value property. Next, the 'EmployeeEvaluation' could have a reference to 'EmployeeEvaluationSchema' to specify which definition the particular evaluation is based on. This can also be used to enforce the form definition in each evaluation. You would have two repositories - one for each entity. If you were to use an ORM such as NHibernate, then when you retrieve a 'EmployeeEvaluation' entity, the associated 'EmployeeEvaluationSchema' would also be retrieved even though there is a dedicated repository for it.
From your description it sounds like your objects don't have any behavior and are simple DTOs. If that is the case maybe you should not bother doing DDD. Can you imagine your entities without having getters? There are better ways to do CRUDish application than DDD. Again this is only valid if your "domain" does not have relevant behavior.