Hi All:
This is just an idea and I am not shure to what extent it fits into the
no-fluff concept of Radiant. It seems that many people are trying to
extend
Radiant and in many cases their extensions have nothing to do with pages
(i.e. attachments, forms, comments, forums, etc.) or in particular with
page parts as they are currently defined. A single arbitrary length
string
is just not the right data type to store an attachment, a form or a
forum
and its user interface via a text area clearly does not allow for
convenient input.
Therefore, I suggest to treat page parts as an abstract data type whose
implementation is determined by the behavior selected for a page.
Specifically the current PagePart model acts as an interface between the
Page model and the actual implementation of the page parts used. Each
implementation of a page part defines its own database schema and input
forms. The behavior of a page will determine which implementations of
page
parts can be used for that page, ideally which parts are required and
which
are optional. That way one can ensure that the content of each page part
can be accessed and processed properly.
Two examples to illustrate:
Attachments:
As I mentioned in another thread it might be beneficial to use Radiant’s
already existing hierarchical storage stucture to add an attachment to a
page as its child instead of changing the page’s model and assume each
page
could potentially have an attachment. The problem with the current
design
is, that a child of a page can again only be a page consisting of page
parts that just store text. With multiple page part implementations,
however, one could just add a “File” page part to the page, that allows
uploading a file to the system. The “Attachment” behavior of this page
then
provides approriate render methods and tags to access the content stored
in
the “File” page part associated with the page.
For those, who do not like to have attachments being stored as separate
pages, one could provide a “Page with Attachment” behavior that merges
the
behavior of a page with that of an attachment and allows for “Text” page
parts as well as one or more “File” page parts.
Comments:
Similar to file attachments as described above, comments are essentially
also attachments to a page and can be treated as children of a page.
Their
structure, however, is somewhat different from “normal” pages and
certainly
from file attachments in a sense that they have a potentially
non-authenticated author, who wants to provide an URL as well as an
actual
comment text. Therefore a comment page needs to store at least 3 fields:
author, URL and text. All of these fields could be defined with the
current
page parts, however, using arbitrarily long text fields for each field
might be overkill and the data model does not enforce consistency.
Instead
a “Comment” page part implementation can provide a model that stores
comments in their own database schema with appropriate data types
chosen.
The “Comment” page bahavior on the other hand ensures that the page in
fact
has a “Comment” page part and provides appropriate tags to access the
page
part’s content.
It is clear that this way of providing commenting requires some
significant
improvements in Radiant’s access and permission control, since it is
currently not possible to add comment pages by non-authenticated users.
In
the future, however, I think those improvements will be necessary
nevertheless.
The examples forms and forums mentioned above can be implemented
similarly
to comments.
As stated eariler, I am not sure on how this fits into Radiant’s roadmap
and I am open for comments and suggestions. I will also try to cobble
together an implementation.
Cheers,
Oliver
