Page Parts as Attachments, Tags, Images, Events, etc

Hi all,
Following a few discussions that I read here before, and my site needs I
have decided to try and implement an option for attaching files, adding
events and other goodies.

I decided to try an approach of adding a type to each page part, so
thatwhen
you create a new page part you can choose the page part type, simple
page
parts acts exactly like the page parts we had so far, but you can easily
create page parts that allows for attachments, setting events, images,
etc.

I did that by setting a few simple hooks in the radiant source that
calls an
external PagePart class for managing of the following actions:

  1. Showing the page part to visitors to the web page (on calls to
    <r:content
    part=“xyz” />)
  2. Showing the admin interface for the page part on creat or edit
  3. Saving the page part data
  4. deleteing page part data

I also added a column to the page_part table called page_part_type_id

Creating new page parts is similar to creating behaviors or filters.

You can see samples, screenshots and some of the code on
http://www.drortirosh.com:8080 (hope it is not too slow)

Waiting to hear what you think,
Dror

Sorry,
Link has changed to http://www.drortirosh.com
Dror

---------- Forwarded message ----------
From: dror tirosh [email protected]
Date: Jul 21, 2006 4:11 PM
Subject: Page Parts as Attachments, Tags, Images, Events, etc.
To: [email protected]

Hi all,
Following a few discussions that I read here before, and my site needs I
have decided to try and implement an option for attaching files, adding
events and other goodies.

I decided to try an approach of adding a type to each page part, so
thatwhen
you create a new page part you can choose the page part type, simple
page
parts acts exactly like the page parts we had so far, but you can easily
create page parts that allows for attachments, setting events, images,
etc.

I did that by setting a few simple hooks in the radiant source that
calls an
external PagePart class for managing of the following actions:

  1. Showing the page part to visitors to the web page (on calls to
    <r:content
    part=“xyz” />)
  2. Showing the admin interface for the page part on creat or edit
  3. Saving the page part data
  4. deleteing page part data

I also added a column to the page_part table called page_part_type_id

Creating new page parts is similar to creating behaviors or filters.

You can see samples, screenshots and some of the code on
http://www.drortirosh.com:8080 (hope it is not too slow)

Waiting to hear what you think,
Dror

Thanks Scott,
The changes are very small, not more than a few lines in theright places
to
create the hooks and the SimplePagePart you can see on the site.
I don’t think it will realy work as a plugin, it is too much integrated
into
the radiant admin functionality (requires an extra DB column and a few
lines
of code changed), the change is minimal and it gives lots of options, I
started on combining it with behaviors that use the DB records saved by
the
page_part which gives even more options.
I can send the files I changed to someone who can do a patch of it.
Dror

dror tirosh wrote:

Following a few discussions that I read here before, and my site needs I
have decided to try and implement an option for attaching files, adding
events and other goodies.

Can you create a “[RESEARCH]” ticket for this and attach a diff? I’m
interested in your approach.


John L.
http://wiseheartdesign.com

Hi John,
I didn’t manage to create the diff file, can I send you the files I
changed,
so you can create the diff file?
Dror

Nice job! Is this something that you can package into a plugin? I was
thinking about something like this, but I think John wants to keep
things simple. However if we had it a plugin those that need different
part types can certainly use it.

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

----- Original Message ----
From: dror tirosh [email protected]
To: [email protected]
Sent: Friday, July 21, 2006 4:11:24 PM
Subject: [Radiant] Page Parts as Attachments, Tags, Images, Events, etc.

Hi all,
Following a few discussions that I read here before, and my site needs I
have decided to try and implement an option for attaching files, adding
events and other goodies.

I decided to try an approach of adding a type to each page part, so
thatwhen you create a new page part you can choose the page part type,
simple page parts acts exactly like the page parts we had so far, but
you can easily create page parts that allows for attachments, setting
events, images, etc.

I did that by setting a few simple hooks in the radiant source that
calls an external PagePart class for managing of the following actions:

  1. Showing the page part to visitors to the web page (on calls to
    <r:content part=“xyz” />)
  2. Showing the admin interface for the page part on creat or edit
  3. Saving the page part data
  4. deleteing page part data

I also added a column to the page_part table called page_part_type_id

Creating new page parts is similar to creating behaviors or filters.

You can see samples, screenshots and some of the code on
http://www.drortirosh.com:8080 (hope it is not too slow)

Waiting to hear what you think,
Dror

Can you post the code to a website? I would love to take a look at it.

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

----- Original Message ----
From: dror tirosh [email protected]
To: [email protected]
Sent: Saturday, July 22, 2006 7:10:27 PM
Subject: Re: [Radiant] Page Parts as Attachments, Tags, Images, Events,
etc.

Hi John,
I didn’t manage to create the diff file, can I send you the files I
changed, so you can create the diff file?
Dror

On 7/21/06, John W. Long [email protected] wrote:dror tirosh wrote:

Following a few discussions that I read here before, and my site needs I
have decided to try and implement an option for attaching files, adding
events and other goodies.

Can you create a “[RESEARCH]” ticket for this and attach a diff? I’m
interested in your approach.


John L.
http://wiseheartdesign.com


Radiant mailing list
[email protected]
http://lists.radiantcms.org/mailman/listinfo/radiant

I just uploaded all changed files and a couple of page_part_types
examples
Dror

Are ‘comments’ not best treated as page parts too? Conceptually this
seems to work for posted comments in a weblog, as well as reviewer
annotations in a document repository.

I can’t see how a ‘comment’ or ‘annotation’ has any meaning outside
the context of a page.

d.r.

dror tirosh wrote:

I didn’t manage to create the diff file, can I send you the files I
changed, so you can create the diff file?

That works.


John L.
http://wiseheartdesign.com

My vote would be no. I see parts as content that you encompasses a page
. A comment on the other hand is not a piece of content (some may
argue) that makes up the page. Accessing comments could easily be
linked off the main pages nav tree.

Just me 2 cents.


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

----- Original Message ----
From: David R. [email protected]
To: [email protected]
Sent: Saturday, July 22, 2006 9:21:54 PM
Subject: Re: [Radiant] Page Parts as Attachments, Tags, Images, Events,
etc.

Are ‘comments’ not best treated as page parts too? Conceptually this
seems to work for posted comments in a weblog, as well as reviewer
annotations in a document repository.

I can’t see how a ‘comment’ or ‘annotation’ has any meaning outside
the context of a page.

d.r.

sorry missed the link before the files are in:
http://www.drortirosh.com/source

On 7/22/06, David R. [email protected] wrote:

Are ‘comments’ not best treated as page parts too? Conceptually this
seems to work for posted comments in a weblog, as well as reviewer
annotations in a document repository.

I can’t see how a ‘comment’ or ‘annotation’ has any meaning outside
the context of a page.

Shouldn’t comments logically be subpages in Radiant? I imagine it this
way:

  • Page that takes comments
    ** Comment subpage
    *** Comment 1
    *** Comment 2
    *** Comment 3
    *** etc.
    ** Other normal subpages of the page in question, if desired.

Having all the comments parented by a subpage rather than the page
itself
gives us a place to declare things like the layouts, etc. for the
comment
display, and store info so the admin knows not to display that page’s
children in the main screen.

My approach to checking what should be part of a page or not is
different, I
think the author of the content is the deciding factor.
I see Radiant as a publishing platform/CMS, which means we have content
authors that use the admin interface to add content to our website, and
we
have readers, that might add some comments, ratings, etc.

Because of this reason I think the actual place where you keep comments
is
more of a storage issue than anything else, I’ld say that the approach
of
having it as child pages makes the most sense to me.

I do think this raises an interesting problem, if we decide to use page
parts, wouldn’t it make sense to have different behaviors to different
page
parts?
I’ll give a few examples -

  1. Comments to a gallery page - to do it now we will have to create a
    child
    page and probably give it a comment behavior.
  2. A book behavior - that shows the childs of each page and has a back,
    up,
    next links - this can be used while the page can have any type of
    content,
    with different behaviors.
  3. Password protected pages that already have any behavior.
    Etc.

What do you think?
Dror

PS - I know we are kind of loosing the subject this thread started with,
but
if we are thinking of page part types maybe adding behaviors on that
level
should be discussed

My vote would be no. I see parts as content that you encompasses a page .
A comment on the other hand is not a piece of content (some may argue) that
makes up the page.

A comment clearly is a constituent component of a page. It is rendered
as a part (there’s that word!) of a page by any weblog that I can
think of. Same situation when Radiant is used as document repository,
or when reviewer comments are applied to multi-person page workflow
(i.e. sticky notes on a page, working on the design of a web site.)

A comment has either little or no meaning when viewed independently,
outside the context of a rendered page (doesn’t mean that the comment
must always be rendered, though.)

And it seems likely that this will fit in very easily with the
part-type proposal for ‘attachments’ being discussed here (roles and
permissions need to be addressed though.) Any other approach starts
very quickly to look like a special case.

d.r.

David R. wrote:

Are ‘comments’ not best treated as page parts too? Conceptually this
seems to work for posted comments in a weblog, as well as reviewer
annotations in a document repository.

One of the things I’ve striven to do in Radiant is to come up with
generic solutions to common problems–to find the building blocks that
make it easy to build buildings. But generic solutions can be
dangerous. If you make something too generic it can end up being complex
and hard to configure. In the end, instead of making it easier for the
end user, you’ve made it more difficult.

Blurring the line between page parts and comments might make it easier
for developers to create solutions to other problems, but I fear that it
would make it more difficult for the average user who just wants to add
comments to their blog.

Comments will need some sort of moderation system for spam and other
problems. Why would you implement a system for moderating page parts?
No, as Scott said, the origin of the content (content producer vs. site
visitor) is enough to make this a separate object.


John L.
http://wiseheartdesign.com

On 7/23/06, John W. Long [email protected] wrote:

Comments will need some sort of moderation system for spam and other
problems. Why would you implement a system for moderating page parts?
No, as Scott said, the origin of the content (content producer vs. site
visitor) is enough to make this a separate object.

And I can think of several very natural ways we could use a generic
inherited-privilege system for moderating subpages. Imagine, say, a
documentation site:

Home Page (site owner)

  • Documentation (doc admins + site owner)
    – Topic 1 (topic authors + doc admins + site owner)
    — Topic 1 comments (topic authors + doc admins + site owner)
    ---- Topic 1 comment 1 (comment author + topic authors + doc admins +
    site
    owner)
    ---- Topic 1 comment 2 (comment author + topic authors + doc admins +
    site
    owner)
    – Topic 2 (topic authors + doc admins + site owner)
    — Topic 2 comments (topic authors + doc admins + site owner)
    ---- Topic 2 comment 1 (comment author + topic authors + doc admins +
    site
    owner)
    ---- Topic 2 comment 2 (comment author + topic authors + doc admins +
    site
    owner)

The admins of the documentation area of the site don’t have access to
mess
with the home page or its other subpages. The authors of each topic (or
perhaps book) can’t disturb things outside their topic. And same for the
author of a comment, if he/she has a user.

Ryan P. wrote:

And I can think of several very natural ways we could use a generic
inherited-privilege system for moderating subpages. Imagine, say, a
documentation site…

But again what are we trying to build? Admittedly we could do that, but
why? This is not The O. CMS to Rule Them All ™. :slight_smile: Radiant has
limited scope and usefulness. I hope to keep it that way.


John L.
http://wiseheartdesign.com

Hi John,

My message got specific with details in response to your statement:

“One of the things I’ve striven to do in Radiant is to come up with
generic solutions to common problems–to find the building blocks that
make it easy to build buildings.”

Is there a specific reason why you believe this isn’t a good path, or
are
you just hesitating (not a bad idea when considering a feature)?

You and other Radiant users already need some way to support commenting,
don’t you? I’m pointing out a way to implement commenting in Radiant
that
will slightly generalize the tool for broader purposes rather than
creating
a new narrow feature that builds in more assumptions.

On 7/23/06, John W. Long [email protected] wrote:

Ryan P. wrote:

And I can think of several very natural ways we could use a generic
inherited-privilege system for moderating subpages. Imagine, say, a
documentation site…

But again what are we trying to build? Admittedly we could do that, but
why? This is not The O. CMS to Rule Them All ™. :slight_smile: Radiant has
limited scope and usefulness. I hope to keep it that way.

Limited usefulness? Is that an actual project goal? What if it stayed
just
as simple but gained more power under the hood (and thus usefulness)?
Well-placed hooks, etc. will create lots more usefulness and very, very
low
code clutter.

Comments should be separate as John says. It’s a little too abstract to
start calling everything a page part. Just call it a comment and give it
a table and the problem is solved. It’s simple to do and it’s pragmatic
to boot.

Just my two cents.

Josh F.