This project is read-only.

Inextensibility with Comments

Topics: Core, Customizing Orchard
Oct 23, 2011 at 5:19 PM

It seems that the editors of the Comments module are hard-coded, so there is no easy way to add parts to comments. Am I missing something? If not, is this by design, or the module was not updated to build an editor (and display) on the fly?

Oct 24, 2011 at 3:00 AM

It's just that comments predate shapes by quite a few months.

Oct 24, 2011 at 10:30 AM

I see. Are there any plans to rewrite it to use shapes?

Oct 24, 2011 at 4:09 PM

It would be interesting to create an issue to explain what would be expected and how it should be refactored.


Another remark : I tested the latest version of Orchard.Projections and it seems really promising.

I hope that in the future, it will be possible to display easily the last comments ordered by date published desc thanks to that kind of refactoring because for the moment only the informations of the Metadata part are displayed.

Oct 25, 2011 at 9:28 AM

Features are implemented basically when somebody needs them hard enough to take the plunge and do them... ;)

Oct 25, 2011 at 10:16 AM

I've created an issue then to collect ideas, to make plans and to see if anybody is interested in making comments dynamic besides me :-).

Oct 26, 2011 at 5:37 PM

It implies creating a dynamic Comment editor in the front-end (which can therefore interact with drivers as normal) and passing in the content id the comment should attach to. Currently that's hard to do because the content manager methods don't let you include any arbitrary data.

However, it's something I can fairly easily do with the Science modules (since I reimplemented most of content manager with an extra parameter to pass in a context), and most likely will at some point if it doesn't happen otherwise!

Oct 26, 2011 at 5:45 PM

What do you mean by "Currently that's hard to do because the content manager methods don't let you include any arbitrary data."? AFAIK you can inject any data stored in parts (e.g. with "casting" by As<>()).

Oct 26, 2011 at 6:13 PM

Hmm ... well I was talking about the ContentManager.BuildEditor and ContentManager.UpdateEditor methods (not drivers or anything else) - with those methods you can only pass in the IContent, you can't pass in any data external to the item. This has implications in certain scenarios - but yes, in this situation you could actually populate the content item prior to calling those methods, so you could pass in the item Id to the comment part. I didn't think of that before. I'm sure there was a thread before where someone was having a similar problem.

Oct 31, 2011 at 11:39 AM

I've added to the issue mentioned above how Comments could benefit from a conversion to include the comment text in a BodyPart instead in the custom text field.

Oct 31, 2011 at 5:50 PM

Well, a Part can't have another part attached. But using shapes is totally possible.

Nov 1, 2011 at 7:34 PM
Edited Nov 2, 2011 at 12:47 AM

I didn't mean CommentPart should have BodyPart attached, I've meant to change CommentText to BodyPart, since this way the text editor of comments would be as flexible as with any type using BodyPart. But this inherently means the rewriting of Comments to have a dynamic editor and display building.

Nov 4, 2011 at 11:43 AM

I've started to refactor Comments in this fork.