Creating a Module

Posted by Community Admin on 04-Aug-2018 19:43

Creating a Module

All Replies

Posted by Community Admin on 15-Jun-2011 00:00

I hope that this is a good place to discuss the JobsModule example.

Item 5 in the step 'Creating the model' includes a number of attributes.

[DataContract]
Namespace. Am I right in thinking that the Namespace item in the DataContract attribute can take any form? Or should it, more properly, reflect a path in to my application?

[ManagerType]
The values here in the docs are "Jobs.JobManager, Jobs". Let's mark it as 0.1, 2.
0 represents? Up to now "Jobs" has been the name of the solution and the name of the project. So I'm assuming that 0 represents the model class's namespace, yes?
1 is the name of the manager, I see that.
2 represents?

Apologies if this is noddy stuff, but, I just doen't know it.

-- 
Stuart

Posted by Community Admin on 15-Jun-2011 00:00

When creating the model, how does the process differ if my model/application has multiple tables?

-- 
Stuart

Posted by Community Admin on 22-Jun-2011 00:00

Hello Stuart Hemming,

Let me go through your questions one by one.

  1. Yes, you can use any value for Namespace inside of the DataContract attribute. This value is used by WCF when serializing the requests to the service, so it should be unique for each class in your application.
  2. ManagerType is what manager is going to be used with this persistent item. The value is a more or less standard way of representing types in .NET as strings. The part before the comma is the full type name, including the namespace. The part after the comma is the name of the assembly containing this type. 0 and 1 in this specific case correspond to the namespace and type name of the JobsManager. Here is where they come from (this is the implementation of the JobsManager.cs).

    The part after the comma (2) is the name of the assembly. It is the same as the name of the project in visual studio.

  3. The process with multiple tables depends on the relationships between those tables. If they are separate data entities, then just repeat the process as for JobApplication. If they have some relation, you should map this in the mappings. You can see an example of this in the Products module - there we have ProductItem and ProductItemUrlData - two persistent classes with a relationship between them. Take a look at the mappings there for more info.

Regards,
Slavo
the Telerik team

Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

This thread is closed