Thread

Personally I would use multiple channels, “books” as one, “comments” as the other, then use related entries to connect your comments to the appropriate books.

Moving to the CodeShare Corner.

Yes, that’s the way I have it.  As Clive said, a text area custom field needs to be in the book channel. So can you explain which channel should have the related field? If the comment channel should house both fields, then I’m completely lost because that’s what I have done, and, as I said, it hasn’t worked for me.  Can someone give me answer to that question? Thanks.

Hi fin, and yes, much as Ingmar says is how I would recommend also. There is one more ability that needs to be mentioned, so that this will work as you expect.

You want to be able to have more than one comment per book, correct? That’s why you would put the comments in a Comments channel, so each comment is an entry there, and you can have as many as you like, each related to a book.

Thus the Comments channel fields would include a relationship field which points to the Books channel. This allows identifying which book the comment is for. You can either have the comment writer choose the book, or with some code in a form, fill in the relationship field automatically when the reader sees on screen that he’s asking to comment on the book whose description s/he’s viewing.

Now, how do you get the comments to all show for a given book?  That’s where the other half of the picture comes. You need what’s called a display of Reverse Related entries. That just means you want to see all the Comments entries related to the current Books entry.

EE provides you with a very easy way to do this, the Reverse Related Entries tag, which you use within your Books display template. It’s documented here, with example code just like you’d use for this problem: Reverse Related Entries Tag.

This is much easier to do than to talk about 😉. 

In fact, diagramming on a piece of paper will be helpful—database professionals even have a special way to do this, but you just need to draw the one book with a few lines from it pointing to comments. Then the comments each have to identify which book (the Comments relation field), and the book wants to be able to find all the comments for it (the reverse relationship listing within the Book display template).

When you have this on paper, try some simple code, with quick dummy data, and you’ll get the feel of it. Mockups like this really help. They let you clarify a concept before you start designing pages with it.

Regards,
Clive

fin, we crossed messages, so let us how this explanation works for you.

C.

Thanks Clive, yes, that’s what I’d like to do with the comments channel: multiple comments focused on individual books. I think this will be very helpful. I’ll sketch it out and let you know how it goes. Thanks.

As Clive suggested, I’ve sketched out the relationship. In my situation it seems that the book channel operates as the parent for the comments channel. The reverse related entries was indeed the piece which was missing.

fin, good to hear.

Indeed, the book is the parent. That’s one of the insights that the later versions of Playa use to get internal advantage, when there are many books and comments, parents and children.

What you have should work for you. Later, you could convert to Playa if you reach a scale where it’s needed, for efficiency or for the visual ease of use with large numbers of entries.

The other thought which came over the weekend was whether you could just use the ordinary EE entries and comments. The key would be if there are any extra information fields you have in mind for the comments.

Those fields and their potential capabilities,or other channel capabilities like categories, are factors that would suggest this parent-child channel approach.

Good job to have gone into this, fin. You’ll really know what you have, this way.

Regards,
Clive

Hey Clive, I still don’t have it working, but I think I’m getting close.  This is my code to date.

{exp:channel:entries channel="comment" disable="pagination|member_data" limit="1"}
            <dl class="entry">
        {related_entries id="book-comment" limit="3" status="featured comment|open"}
        <dt>{title}</dt>
            <dd><span class="by">by</span> {author}: <span class="comment-date">{entry_date format="%F %d, %Y"}</span></dd>
            <dd>(comment-body}</dd>
            </dl>
              {/related_entries}
          {reverse_related_entries channel="comment" status="open" orderby="title"}
            <dl class="entry">
        <dt>{title}</dt>
            <dd><span class="by">by</span> {author}: <span class="comment-date">{entry_date format="%F %d, %Y"}</span></dd>
            <dd>(comment-body}</dd>
         </dl>
         {/reverse_related_entries}
        {/exp:channel:entries}

I’ve made a comments template, and the test comments show up there when I link to that template; however, they still fail to show up for the book to which the comments have been related.  Thanks again for the help on this.

Hi fin,

Well, yes, you are getting close. But this is kind of a precise business, and it won’t seem simple until you can see the overall picture, so that the order of things becomes clear.

What I felt might do best is to give a worked-out example, especially since describing gets wordy.

See if this works for you, and then it may be useful for others also.

Code is below, for basis of the two templates needed to look from the view of books, or of comments. The formatting I used is very rudimentary, to keep things simple—you are on a nice track there, and I will leave you to it as you make the pages look as nicely as desired.

I’m attaching pictures of EE screens for my custom fields, and (partial) example images of the output, with these templates and their simple formatting, on example entries.

Note that both {related_entries} and {reverse_related_entries} are smart where they need to be, so that the {title} within them is from the related entry, not the entry itself. They have to be smart this way, because {title} is a fixed field, the same on any EE channel.

Note also that you use reverse_related_entries from the book point of view, and related_entries from the comment point of view—only one at a time. Also, be careful that your custom field names have underscores or hyphens, but not spaces.

Let us know if this solves the case, or where you are, fin.

Best regards,
Clive

books view template:

<h2>The books:</h2>

<p><br />
{exp:channel:entries channel="book" status="open|featured_book" limit="5"}</p>

<h3>Title:</h3>

<p>  <strong>{title}</strong>, by {book-author}</p>

<h3>Description:</h3>

<p>  {book-description}</p>

<h3>Comments:</h3>

<p>  {reverse_related_entries channel="comment" status="open" orderby="title" limit="5"}</p>

<p>    {if no_reverse_related_entries} <br />
       No comments yet…<br />
    {/if}</p>

<p>    <strong>{title}</strong>, by {comment-author}<br />
    <i>{comment-text}</i></p>

<p>  {/reverse_related_entries}</p>

<p>  </p>

<p><br />
{/exp:channel:entries}

comments view template:

<h2>Here are comments, each referencing a book</h2>

<p><br />
{exp:channel:entries channel="comment" status="open"}</p>

<p>  <strong>{title}</strong>, by {comment-author}, <br />
    </br>  on {related_entries id="comment-book"}<i>{title}</i>, by {book-author}{/related_entries}</p>

<p>  <i>{comment-text}</i></p>

<p>  </p>

<p>{/exp:channel:entries}

Clive, I appreciate this detailed explanation. It has helped a great deal. I now see how the templates and the related_entries and reverse_related_entries work together.

In my comments template group, I have the standard index page. If I only had comments about books, I’d only need that index page for my related_entries? If, however, I have comments for original articles, then I’ll need to make two more templates: books and articles. Those templates will have the related_entries ids for books and articles respectively?  For example, this related_entries tag should be on a template called articles under the template group comments or is there a better way?

{exp:channel:entries channel="comment" status="open" orderby="title" limit="5"}
                    <h4>{related_entries id="comment-article"}<a href="http://{title_permalink=comments/reader-response/}"><span>{title}</span></a>{/related_entries}</h4>
<p>{/exp:channel:entries}

Thanks again.

Hmm. fin, it depends on what you want to accomplish.

- I’m a little surprised from a use point of view, that the focus is about ‘comments’ pages, rather than the book or article page, which also lists relevant comments. Do you really want a long list of comments, as your contributors grow, each of which refers to a book or article? Only you can answer that.

- In the way I originally set this up, based on the other supposition, I had the index page be the code to show books, each with their comments. The ‘comments view’ access was on a template in the books template group called comments. But again, you can do it your original way if it suits you.

- The key to how you need to set up alternate variations of the book example is the EE relationship field. It can only handle one relationship; comments for books as an example. To have comments for articles, you will need another specific field to handle that relationship.

- The simplest way I can think of to set this up is to just have two completely separate pairs of channels, with their own individual pair of entry and comment field groups. This suits the EE way of looking at things, which avoids conditional programming as much as possible.

- Then your forest of questions is answered, I think, because what you already understand works for the articles case too.

- I can’t quite be sure from what you say, but I don’t think you want to show a mixed listing of comments, referring back to either books or articles. If you do, then I would design an approach which uses conditional logic, so that there is only one channel for sources (books and articles), and one channel for comments, which might be for either.

You would then use a selector field in sources, to say if the source were a book or an article. Then you would use conditions (if statements) to alter the formatting to suit labels for a book or an article.

- I am smiling for all the other possibilities, and hoping these are answers enough so you can get on with your intended design, fin.

- the thing I can suggest, so that you can get your own head clearer, and assure that EE will operate in a way you would like, is to make a simple working model each time, to try it out.

In fact, I did another in ten minutes, before answering you here, and it is a very standard professional practice. It avoids trying to make a logic that can’t be untangled or implemented; and at the same time it will bring you to understanding much better than only disconnected (abstract) thought.

There is something called tacit knowledge which is very important in all practice this way, and again, it’s something professionals do discuss about, somewhat the result of working with your hands. Albert Einstein also said as much.

You can think of the working model as the next stage of the paper sketch, as painters make. Then they bring together the complete composition, once they’ve seen what will work in the areas of detail.

Hoping it all helps, fin 😉

Regards,
Clive

Fin, I’ve come back to the case this evening, because it’s bothering me that for all the people helping here, we can’t quite understand what you may want. It feels a bit like someone ordering a custom kitchen, and wanting it to be a ‘really special’ kitchen, yet not quite knowing what they want to be in that kitchen.

Who you call for in that case is an architect, and I’m going to play one in a very simple way here, for a moment only.

What I’ve done is the equivalent of what a building architect would do: take a walk around the site (read all your past discussion), think about the underlying natures evident of your story, and then place some ideas which come out of a background of many similar stories, seen through experience.

At the beginning, you say this is for a book club. You don’t want to use ordinary comments, because, well, that would be too ordinary—and with some sense, yes, would limit a bit on future possibilities if you wanted to get complicated with them.

Ordinary comments, as Marcus Neto suggests, have their advantages in terms of built-in easy abilities for avatars, self photos, etc., which people in a community like. But, yes, you could implement those in another more complicated way, by using the Member module. Let’s presume that would all work out for you.

Now, let’s settle this business of books and articles. I think what you mean, going by your original story that this is a book club, is that books and articles are kind of equal contributors to club activity initiation, are used in the same way on the site. In other words, you or someone else in the role of a leader might begin an intended conversation by writing a book review. Or, they might equally begin a conversation by writing what you call an article—a piece, for example, that formally compares several books, drawing out a theme that becomes a timely point of focus for the club.

Then, I think your story says that the participation from the non-leading members of the club come in the form of comments. Those comments are about either a reviewed (discussed, possibly assigned) book; or, the comments may be about one of those intriguing articles.

As far as comments go, they can get arbitrarily rich in their surroundings—photos, signatures, etc., etc., even (here we go again) related blocks of information like a short list of recent posts by that person. Still, a comment is a comment, looks about the same. A comment has a primary need to be related to the subject it is commenting on.

This telling of your story is I hope reasonably accurate, and what it would suggest is the second model I proposed this afternoon, where you would have just one ‘source’ channel.

Let’s imagine that ‘source’ channel would carry in fact three different kinds of postings. There could be books with description, book reviews, and equally, the ‘articles’. Any of those sources requires much the same information, as far having a title, having a body of text, probably having a posting author, and possibly having an image or two, such as the cover, the book author, the posting author, etc.. The main ways they are likely to differ are in formatting - backgrounds, details, labels, etc.; and there can also be differences in just which information fields are appropriate and included for each ‘source’ type.

You would handle the differences in content and formatting by having a select field, which specifies if a given ‘source’ entry is a book listing, a review or an article. This type field would then be used in ‘if’ statements to show or hide parts or variations of the template.

If you did such a channel of ‘sources’, then you could have a single channel of ‘comments’ which can relate to any of the source types. That would be set up just as in the example I worked out for you, taking just the one relationship field.

Now you have the capability to have at least two primary types of template sets which fit your book club story. The first would center on the sources: perhaps two templates, one to just list books, reviews and articles with a teaser excerpt, the other to open up the details for individual postings, and show their list of comments.

The second template view could be a stream of ‘activity’ - this is what I interpret as the alternate concept you keep raising. In this stream, the member activity shows something as if on Twitter, and again, a detail template from a click-on link could bring out the full context and substance of each comment entry, on its own single page.

What would you gain from such an architecture, compared to the more normal article feed and EE comments? Two things:

—you gain the ability to have the stream of ‘activity’
—you gain the ability to put arbitrary complexity into your ‘comment’ entries, through further use of relationship fields. This could include such items as lists of other recent ocmments for the commenter,  or a cover/title/author block automatically showing next to the comment about that book.

Truly, it can get as complicated as you may feel is to advantage. I would suggest looking at devot-ee.com, the EE add-on site, to get a feeling for how related entries can be used in such a fashion. There is a lot going on there, and from learning about related entries your eyes will be more attuned to recognising where these techniques are used.

fin, it’s late. I hope this has been appropriate, and will give you some frameworks to think with, beyond detail answers to technical questions.

I see the ‘going viral’ thoughts, and the lack of budget in your story. Well, we should each dream, surely. The best is if we can in fact start pretty simply, while leaving the road open enough to expand.  If you can make this sources-comments structure work, then you have open abilities compared to using standard commented entries. I won’t kid you that it will be complicated. But if you want it, EE ability is there. Simple tries to sketch realities, the best.

C.

Clive, I really appreciate your patience on this issue. Sorry about the morass of questions in my last post. I should have thought out the question a bit more before asking it. Essentially, I was still trying to fully understand how the related_entries work with the templates although I thought I had it. As you said in your other post, it depends on how I want to do it. Your last posts has given me a lot to consider.
Yes, I could have been clearer about this in the original post too. I should have mentioned that this site would have original articles from writers and/or editors. I also agree with you and Marcus that comments are comments, and form comments have advantages. Now, I have a better understanding when one tool is better for a specific job.

You’re also right that I did want to give those writers and editors a different way via the back end to comment on the book readings and articles. I hadn’t realized all the advantages that this method has. Thanks. I guess this project (or the kitchen) has gotten more complicated than I originally intended. It had been personal project, a blog. I also intended to stretch my knowledge of ee: mission accomplished. Now I have friends who want to contribute. Ultimately, I think it will be a better site for those contributions.  That being said, this thread has been a tremendous help to me for this and future projects. I’m going over your suggestions now.

Ok, fin, and I think you’ve surfaced another essential element of your actual tale here, that an architect would need to know about—even as that architect is you.

You’re also right that I did want to give those writers and editors a different way via the back end to comment on the book readings and articles.

So, there is another key item that is all about appearances—as most is in a website—which would explain one good reason why authors and editors need special access to the site.

What I want to do now is move from where we’ve been discussing, and put you on what I feel will be a strong track.

Relationships are indeed an important topic for full understanding about data systems, but mostly, EE is designed in its automatic handling to free you from having to concern about them. The EE way of allowing explicit relationships on the surface is intended to be useful for small added touches, and when things of that kind get deeper, well, that is why you have add-on developers like Pixel&Tonic;, to make abilities that are robust and easy to use.

In your case, I think we can imagine everything done with standard channels and the standard comment module, which is itself very strong in abilities you are going to want to have—and don’t really want to implement yourself. I think there’s more than enough flexibility in what I am going to propose; and if in an especially successful future you want more, well, you’ll then be able to afford the help to do that right, and to do any data transfers that will need as a small and normal part of such a job.

Here are the key points:

- use the first part of yesterday’s proposed design: have a ‘sources’ channel which handles book releases, book reviews, and articles—and you could add other types as they might occur to you. Again, the custom channel fields data are to be set up broad enough to cover all types, while formatting and presentation of individual fields is turned on and off to match the individual posting type.

- use the EE standard comment ability. This is strong enough to handle all kinds of things you think of now or may become desirable in the future, with abilities able to be amplified where needed via Custom Member Fields. Using it will avoid all kinds of tears, and also get you running quickly.

You would like that author and editor comments carry a unique appearance, which may include unique content. You would accomplish this just as in the different appearances of ‘source’ channel postings: alter the individual comment formatting and presence of available fields according to a key.

That key is probably the member group the commenter belongs to, which will make things easy for your plan: authors and editors would naturally belong to their own member groups, for the primary reason of allowing their privileges. That same group identity can also then determine what their comment entries look like.

By staying with the EE comment system, you pick up all the integrated comment—and commenter—handling and safety features which are in the EE editorial control panel (CP). I think you and any editors will want all of them.

It’s a big enough point on its own, I believe, that by using the EE commenting you’ll avoid having to provide a special and secure entry arrangement which the general public would have to be allowed to use—and you’ll be able to take (or not take) non-member comments as easily as those of members, which can be pretty desirable on such a site.

You also get a robust underlying system which will handle and page as many comments as may come on a hot topic. It will equally be easier to transfer your comments if you later want to go to an external commenting arrangement like Disqus, for its pluses and minuses (i.e. no integration).

- These two angles of approach will leave matters open for you to build other abilities in future, at the level that EE allows you to work, rather than in most cases needing to go to a programming level. You can take advantage as appropriate of the increasingly wide range of add-ons, which are most often built to bring in the latest popular abilities - just the ones you are most likely to wish.

Overall, fin, I think this approach will get you a very capable system, and one that you can easily discuss with other EE developers and support persons, which is a considerable advantage in itself.

It will free you by its nature to expend most of your energy on site appearance and presentation, which has always been the great leveraging ability that EE was designed for—and the reason why it has become so popular with designers.

I’ve wanted here, among intents, to respect your interest in how things actually work, and that interest which other readers here will share. It’s always a strength, to build understanding in such areas.

I would kind of suggest to think about what I’ve said about sitting down and constructing small example ‘episodes’ towards your intended design, seeing what you have by doing small works with it. There’s a lot you are likely to gain in relaxed insight as well as fluency by doing this.

Good fortune, fin, and let us see what you’ve made. You can see by my examples that I’ve got an interest in stories.

Regards,
Clive

p.s. I meant to mention, that using EE build-in comments, I think you can also pull a ‘stream’ of comments on its own template, if that’s desired, and even do do across different channels.

This means you could choose to run the book announcements, reviews, and articles on separate channels if desired, back to the original model.

Doing so would mean you didn’t have to use if statements to decide inclusion or formatting. However, plus or minus, it would also mean that you had the announcements, reviews, and articles in separate locations as the participant would see them, rather than as a stream of different kinds of postings all on one page.

Either way can can have its attractions and feel of style or environment. It will be your choice, as all design is. Here again, quick models, as EE makes easy, would let you get the feel of what efforts and results would be for alternatives of path.

You might resolve the issue of separateness, for example, by providing a gateway front page which has a few pulled items from each of the posting types, if you turn out to like keeping the channels separate. Alternatively, you can still do a topical gateway if you combine into the one ‘sources’ channel: here you would do the individual gateway pulls by limiting on the source type, via the search= entries parameter.

Here’s an arts site I ran across in the forums just this morning, which takes a gateway front-page approach. It might give you some ideas, if it’s about visual art rather than books; and knowing that you can have it however you choose to internally structure your postings.

http://www.stretcher.org/

Enough, then, on flexibility. The bottom line today, fin, among all the useful excursions, is the suggestion to use that EE comments ability as one of your foundations.

C.