Keith > Well, yes. We haven’t found it too much of a problem hand craftign the entities ourselves. I agree it will be a nice solution and we are part way there so it will come in a future release.

Another improvement is to automatically make properties that represent documents or attachments into entities as well. Kentico just stores a guid for those, so in our Build Provider we generate classes with properties of type Attachment or Document.

KP > We opted to keep things simple with the Guid. You can load an Attachment, optionally including the binary via the AttachmentRepository. This is consistent with us not attempting to have object properties at all as that leads into more complexity than we are able to handle at this time. For example Kentico doesn’t really support the notion of foreign keys or many to many doc types explicitly. We tend to just store the ids and then if we really want to, we create extra methods on the specific entity’s repository to return the objects or collections that we need. Obviously something like Linq for SQL/Entities would do this automatically, but we haven’t found the need as yet.

Regarding open sourcing this library. I don’t think there is such a strong community of Kentico developers. But if you do release it on Codeplex or something like that, I would be willing to devote some of my time to a Build Provider (but no guarantees, it would depend of time being available).

KP > We’ll probably release it with the next major version which will have code generation capabilities.

Has Kentico shown any interest in adopting the library?

KP > Nope. I originally shared it with them and they said that most kentico users/developers would not find the need for somethign so advanced. I think Martin the CTO liked some of the approaches and i genuinely hope it informs how they tackle things in 5.5 and beyond

Keith > Well, yes. We haven’t found it too much of a problem hand craftign the entities ourselves. I agree it will be a nice solution and we are part way there so it will come in a future release.

Another improvement is to automatically make properties that represent documents or attachments into entities as well. Kentico just stores a guid for those, so in our Build Provider we generate classes with properties of type Attachment or Document.

KP > We opted to keep things simple with the Guid. You can load an Attachment, optionally including the binary via the AttachmentRepository. This is consistent with us not attempting to have object properties at all as that leads into more complexity than we are able to handle at this time. For example Kentico doesn’t really support the notion of foreign keys or many to many doc types explicitly. We tend to just store the ids and then if we really want to, we create extra methods on the specific entity’s repository to return the objects or collections that we need. Obviously something like Linq for SQL/Entities would do this automatically, but we haven’t found the need as yet.

Regarding open sourcing this library. I don’t think there is such a strong community of Kentico developers. But if you do release it on Codeplex or something like that, I would be willing to devote some of my time to a Build Provider (but no guarantees, it would depend of time being available).

KP > We’ll probably release it with the next major version which will have code generation capabilities.

Has Kentico shown any interest in adopting the library?

KP > Nope. I originally shared it with them and they said that most kentico users/developers would not find the need for somethign so advanced. I think Martin the CTO liked some of the approaches and i genuinely hope it informs how they tackle things in 5.5 and beyond

Another improvement is to automatically make properties that represent documents or attachments into entities as well. Kentico just stores a guid for those, so in our Build Provider we generate classes with properties of type Attachment or Document. So given a document type with a field that stores attachments, we can write code like this:

for(Attachment a in Document.Model.Downloads) {
// a.Url
// a.Filename
// a.Size
}

Where Attachment is a custom class that encapsulates an attachment in Kentico, Document.Model is a property on our custom TemplatePage class (derives from System.Web.UI.Page) and its Downloads property would be automatically generated to be of type List based on the field definition of the document type in Kentico. As you can see we separate Document (base properties that all documents have) and the Model (extra fields defined by the document type). I saw it as a 1-to-1 relationship between those two, not necessarily as a single type.

But what we have is read-only, just in order to ease template development. It’s also limited to stronly typed access to the current document for a template, with no repository to find other objects.

Regarding open sourcing this library. I don’t think there is such a strong community of Kentico developers. But if you do release it on Codeplex or something like that, I would be willing to devote some of my time to a Build Provider (but no guarantees, it would depend of time being available).

Has Kentico shown any interest in adopting the library?

Thanks again for sharing, great job!

Our testing has so far been rather limited to using aspx pages against each method of the repositories. It is definitely something we would like some help with if we decided to open source.

Would you be interested in looking at the code? Perhaps if you like the repository apprach etc. you could maybe integrate your build provider and we could get code generation added in?

Thanks for the feedback