Comments and Attachments

Ruby Apps Radiant CMS
1

I don’t mean to beat attachments and comments with a dead horse. These
are two features that I need (and most others from the sounds of it).
There really hasn’t been a consensus on how they should be done. So I
thought I would re-open the issue to see if we can come to a consensus.
Please critique my designs:

Attachments: First of all do we need attachments? What if we had
asset tab as a top navigation item in the admin console? Basically the
“Asset Manager” would be a tree hierarchy of all the assets for the
website. The assets would be stored on the file system with some
metadata stored in the database. Then radiant tags would be used to
either display links to the assets or to include the assets inline.
With this approach we may not need to actually associate attachments
with pages. Once an asset has been uploaded, it would simply require a
radiant tag in a page part to display the asset.

Maybe people would like attachments for pages. One reason I can think
of is for work flow processes. If someone is creating a page in which
they want to add an image, instead of going to the assets tab it would
be nice to add the image during the page creation process. If this is
the case then we could have a “specialized” page part that allows the
user to add attachments. In reality the attachments would really do the
same thing as if the user uploaded the asset via the assets tab.

Comments: Comments fall into three areas:

  1. Infrastructure–The storage of comments. Probably a table(s) right
    off the pages table.

  2. Presentation–Radiant tags to draw the comment form as well as
    display comments. I would not make it a behavior, which in my opinion
    should be for “one-off” situations. Since most pages will have comments
    in a blog you wouldn’t want every page to have a “comments” behavior.
    Instead there can be core Radiant tags to render comments.

  3. Admin–Not needed in the first cut of comments. Probably a plugin
    to the admin console to admin comments.

John–Since you are the father of the Radiant CMS. Please let us know
how you have envisioned these components. I am very happy to work on
either comments or attachments, but I don’t want to go down a path and
later find out that another approach will be the official version.

I’m eagerly awaiting everyones input

cheers,

scott

What’s an Intel chip doing in a Mac? A whole lor more that it’s ever
done in a PC.

My Digital Life - http://scottwalter.com/blog
Pro:Blog - http://scottwalter.com/problog
Snippets - http://snippets.scottwalter.com

2

Scott W. wrote:

Attachments: First of all do we need attachments? What if we had asset tab as a top navigation item in the admin console? Basically the “Asset Manager” would be a tree hierarchy of all the assets for the website. The assets would be stored on the file system with some metadata stored in the database. Then radiant tags would be used to either display links to the assets or to include the assets inline. With this approach we may not need to actually associate attachments with pages. Once an asset has been uploaded, it would simply require a radiant tag in a page part to display the asset.

I’m pretty keen on the idea of attachments instead of regular asset
management. Matt McCray and Xavier had agreed to work on this, but I’m
not sure what the status is. I’d suggest that your team up with them,
or, if you prefer, work on an asset manager plugin. There seems to be a
great desire for something of this nature and perhaps it could be a stop
gap measure until attachments are fully implemented.

Maybe people would like attachments for pages. One reason I can think of is for work flow processes. If someone is creating a page in which they want to add an image, instead of going to the assets tab it would be nice to add the image during the page creation process.

Workflow is a big part of the reason I like attachments.

Comments: Comments fall into three areas:

  1. Infrastructure–The storage of comments. Probably a table(s) right off the pages table.

Right. They should be a full fledge model object.

  1. Presentation–Radiant tags to draw the comment form as well as display comments. I would not make it a behavior, which in my opinion should be for “one-off” situations. Since most pages will have comments in a blog you wouldn’t want every page to have a “comments” behavior. Instead there can be core Radiant tags to render comments.

Agreed.

  1. Admin–Not needed in the first cut of comments. Probably a plugin to the admin console to admin comments.

Good idea. Though I suspect we will need some SPAM controls fairly
quickly.

Bruce W. (http://codefluency.com) wanted to work on the comments
system as well. I have high hopes that it can be implemented as a
plugin. Perhaps you could collaborate with him?

–
John L.
http://wiseheartdesign.com