Part types

Ruby Apps Radiant CMS
1

Maybe somebody’s had this idea already, but better to echo it
accidentally than to lose a good brainstorm.

Somebody brought up the idea of a central asset store. i like this
idea more than trying to shoehorn assets into some relationship with
pages.

So it occurs to me, parts are currently text + filter, right? (if
“filter” isn’t assigned per part, i think it should be)

What if what’s now a “filter” also got to draw the admin interface
for that part? So Textile and Markdown could have their own previews,
a rich text editor could do its thing without bothering anybody else,
and an image part could give us a gallery-browse option.

Interested in support or attacks or whatever, but i think there’s a
seed of something that ought to go into Radiant here.

–
Ryan P.
Senior Developer, SubscriberMail, LLC

3333 Warrenville Rd.
Suite 530
Lisle, IL 60532
(630) 303-5072

Not Just Email…SubscriberMail

This message (including attachments) contains proprietary information
which may not be disclosed or used beyond the purposes of this
message without the written consent of SubscriberMail, LLC. If you
receive this message in error, notify the sender and destroy this
message and all attachments immediately. Thank you.

SubscriberMail is covered under US PATENT 6,769,002

2

I agree, and I also think it might be a good idea for the filter (which
probably should be called something else in this approach) to be called
when
the data is entered/changed by the admin interface. This way a new
filter
might edit before DB insertion or maybe put it into a different DB
table,
write it to a file, etc.
Dror

3

On Jul 10, 2006, at 11:15 AM, dror tirosh wrote:

I agree, and I also think it might be a good idea for the filter
(which probably should be called something else in this approach)
to be called when the data is entered/changed by the admin
interface. This way a new filter might edit before DB insertion or
maybe put it into a different DB table, write it to a file, etc.

I strongly agree. Lifecycle hooks like that make a plugin-system much
more loosely coupled. It’s the approach that Eclipse uses, as
discussed by JUnit co-creator and Eclipse lead Erich Gamma here:

http://www.artima.com/lejava/articles/reuse3.html

Rails’s monkey-patching is a lazy hack, frankly. It’s understandable
for RoR’s goals, but it lacks the characteristics that will permit
the stability available to well-designed OO systems – which is why
Rails plugins break, and break again. So we should do better.

I’ll be happy to lead this effort if we get agreement on what to create.

–
Ryan P.
Senior Developer, SubscriberMail, LLC

3333 Warrenville Rd.
Suite 530
Lisle, IL 60532
(630) 303-5072

Not Just Email…SubscriberMail

This message (including attachments) contains proprietary information
which may not be disclosed or used beyond the purposes of this
message without the written consent of SubscriberMail, LLC. If you
receive this message in error, notify the sender and destroy this
message and all attachments immediately. Thank you.

SubscriberMail is covered under US PATENT 6,769,002

4

I’ld think it is probably good to follow the same method the behaviors
are
used.
So you can inherit normal “filter” action from one class and override
them
if needed.
The default will just return the text area when asked for the interface
and
store the data in the page_parts DB table when data is received. When
needed
to output the data it will do nothing.
any of the existing filters will only overwrite the output function by
using
the current filter function in the existing filters.
We can probably do that by enhancing the current TextFilter class, a few
changes in the current admin implementation.
The output can be delegated to the filter in the parse functions in the
behavior.rb
I wouldn’t mind giving it a go over the next few days and see if I can
send
you guys something to look at.
Dror

5

On Jul 10, 2006, at 1:23 PM, John W. Long wrote:

Somebody brought up the idea of a central asset store. i like this
idea more than trying to shoehorn assets into some relationship with
pages.

How do you see this relating to part types?

Decoupling the assets from pages, 1) for free reusability of the
assets between pages, and 2) to preserve the fact that currently
pages are text-only.

and an image part could give us a gallery-browse option.

Ug. This doesn’t smell right to me. Filters are for filtering text.
Not
adding images to pages.

But what about adding image URLs to pages? In HTML, that’s all
images are – URLs.

–
Ryan P.
Senior Developer, SubscriberMail, LLC

3333 Warrenville Rd.
Suite 530
Lisle, IL 60532
(630) 303-5072

Not Just Email…SubscriberMail

This message (including attachments) contains proprietary information
which may not be disclosed or used beyond the purposes of this
message without the written consent of SubscriberMail, LLC. If you
receive this message in error, notify the sender and destroy this
message and all attachments immediately. Thank you.

SubscriberMail is covered under US PATENT 6,769,002

6

Ryan P. wrote:

Maybe somebody’s had this idea already, but better to echo it
accidentally than to lose a good brainstorm.

Somebody brought up the idea of a central asset store. i like this
idea more than trying to shoehorn assets into some relationship with
pages.

How do you see this relating to part types?

So it occurs to me, parts are currently text + filter, right? (if
“filter” isn’t assigned per part, i think it should be)

Filters are assigned per part.

What if what’s now a “filter” also got to draw the admin interface
for that part? So Textile and Markdown could have their own previews,
a rich text editor could do its thing without bothering anybody else,

That’s an interesting idea. I’m considering giving behaviors the ability
to alter a page’s interface, but perhaps filters should be able to do
the same. (See: http://dev.radiantcms.org/radiant/ticket/40/.)

and an image part could give us a gallery-browse option.

Ug. This doesn’t smell right to me. Filters are for filtering text. Not
adding images to pages.

–
John L.
http://wiseheartdesign.com

7

Ryan P. wrote:

On Jul 10, 2006, at 1:23 PM, John W. Long wrote:

Somebody brought up the idea of a central asset store. i like this
idea more than trying to shoehorn assets into some relationship with
pages.
How do you see this relating to part types?

Decoupling the assets from pages, 1) for free reusability of the
assets between pages, and 2) to preserve the fact that currently
pages are text-only.

I’m lost. How do filters relate to a central asset store? I see the
advantages of a central asset store, but I don’t see how it relates to
text filters.

and an image part could give us a gallery-browse option.
Ug. This doesn’t smell right to me. Filters are for filtering text.
Not
adding images to pages.

But what about adding image URLs to pages? In HTML, that’s all
images are – URLs.

???

–
John L.
http://wiseheartdesign.com

8

Sorry, I’m hijacking the thread. Im just evaluating Radiant and I have
some observations, ideas, input, to share.

Maybe the parts could have type (maybe even plug-able):

  • Text
  • Attachment/Asset/File (however you will call it)
  • Tag

A Image or Word-Document would be a part of the page too. Makes sense to
me.

Another interesting thing would be to add behaviours or plugins to
parts: So you can have “Comments” part which adds the usual blog-style
comment stack (comments, new comment form, submit,
thanks-for-your-comment message). And in the backend, it would have a
special interface to manage comments. Then again the tag part would let
us add the keyword-tags in the backend and displays them on the
front-pages.

Just a thought.

Ah, btw, another thought: Can you put the public/images/* that are for
the admin interface in a sub-folder, say images/admin/* So we have
clear separation of images used on the front vs. backend? Would help
keeping clean IMHO.

And one on the attachments-strorage thing:
If you consider storing images in the database (and cache them locally).
I have good experiences with this (using acts_as_attachment quite large
intranet app). It’s not much slower than the filesystem, and cached
there’s no difference. I find it very important for a CMS that documents
are stored in the DB (or storage is choosable for each file). It
simplifies so much.
However the RDBMS should have good support for Blobs (stay away from
MSSQL and Sqlite). The bad reputation of BLOBs are mainly through the
bad implementations in the 90ties and when BLOBs are used in DB-logic
(triggers, sp, views) , they are usually slow.

Thanks, and keep up the great work. Looks very promising (look at Typo3
code and you know what I mean ;))
Andreas

9

Andi wrote:

me.
I’d like to keep it simple and avoid making different parts of the
interface ambiguous. Right now the way I’d like for attachments to be
implemented looks like this:

http://johnwlong.com/downloads/radiant/attachments/

Another interesting thing would be to add behaviours or plugins to
parts: So you can have “Comments” part which adds the usual blog-style
comment stack (comments, new comment form, submit,
thanks-for-your-comment message). And in the backend, it would have a
special interface to manage comments. Then again the tag part would let
us add the keyword-tags in the backend and displays them on the
front-pages.

Just a thought.

Again, I think it’s better not to have ambiguous objects.

Ah, btw, another thought: Can you put the public/images/* that are for
the admin interface in a sub-folder, say images/admin/* So we have
clear separation of images used on the front vs. backend? Would help
keeping clean IMHO.

That’s a good idea. Can you create a patch for this and attach it to a
ticket?

And one on the attachments-strorage thing:
If you consider storing images in the database (and cache them locally).
I have good experiences with this (using acts_as_attachment quite large
intranet app). It’s not much slower than the filesystem, and cached
there’s no difference. I find it very important for a CMS that documents
are stored in the DB (or storage is choosable for each file). It
simplifies so much.

Agreed. This is what I’d like to see implemented.

However the RDBMS should have good support for Blobs (stay away from
MSSQL and Sqlite). The bad reputation of BLOBs are mainly through the
bad implementations in the 90ties and when BLOBs are used in DB-logic
(triggers, sp, views) , they are usually slow.

So the disadvantage for MySql and Sqlite is that they are slow? Perhaps
the could be uploaded to the location where they will be stored in the
file system and then imported into the DB?

–
John L.
http://wiseheartdesign.com

10

Hi John,

Right now the way I’d like for attachments to be implemented looks like this:
http://johnwlong.com/downloads/radiant/attachments/

That looks very cool! Can’t wait to see it working.

Ah, btw, another thought: Can you put the public/images/* that are for
the admin interface in a sub-folder, say images/admin/*

That’s a good idea. Can you create a patch for this and attach it to a
ticket?

I hope I get around to it on the weekend.

However the RDBMS should have good support for Blobs (stay away from
MSSQL and Sqlite).

So the disadvantage for MySql and Sqlite is that they are slow?

MSSQL seems to have trouble handling BLOBs in general. And Sqlite: I did
not get it working without encoding Base64 (it messed up the files…
however I think it’s the rails connectors’ fault).

RDBMs which have sane BLOB implementations (I know of, there are
certainly more) are: MySQL, Postgres, DB2, Frontbase.

The DB gets slow if it has to calculate with BLOBs i.e. if you process
rows with blobs in stored procedures things get slow and can consume
much memory. However I never had those cases, I think the logic (mainly)
belongs to the app, not the database. So using BLOBs as simple
backup-able replacement to for the file-system is fine (however the DBAs
will yell about bad style;))

Perhaps the could be uploaded to the location where they will be stored in the
file system and then imported into the DB?

Hmm, would be be more work I guess. I have no bad experience uploading
them directly to the DB. However I did not try it vice versa.

Andreas

11

On Jul 10, 2006, at 4:10 PM, John W. Long wrote:

I’m lost. How do filters relate to a central asset store? I see the
advantages of a central asset store, but I don’t see how it relates to
text filters.

They don’t. I’m imagining broadening the concept of “filter” to
“component that handles everything needed to translate a part’s text
into whatever actually goes on the site”. This includes things like
simple Textile filters, but could mean rich text editors, image
browsers, LaTeX environments :wink: …anything that could persist to
the part’s text field and somehow present an admin interface, and
render something for the public view of the site.

So I guess I was just referring to the idea that the images could
simply be referenced by URL string or some other text-only
representation, instead of adding to Radiant’s DB model to hard-code
this functionality that different folk will want to implement
different ways for their own needs. Which to me would suggest
something more like a central asset store than an attachment system.

and an image part could give us a gallery-browse option.
Ug. This doesn’t smell right to me. Filters are for filtering text.
Not
adding images to pages.

But what about adding image URLs to pages? In HTML, that’s all
images are – URLs.

???

Again, keeping part data restricted to a text field looks like a very
valuable concept to me. Instead of hard-coding some special case for
asset-handling, just open up parts to store data about them (like
their URL and alt text) in YAML or something, and let us build Part
Type plugins to render and manage the assets using that text field
for persistence.

–
Ryan P.
Senior Developer, SubscriberMail, LLC

3333 Warrenville Rd.
Suite 530
Lisle, IL 60532
(630) 303-5072

Not Just Email…SubscriberMail

This message (including attachments) contains proprietary information
which may not be disclosed or used beyond the purposes of this
message without the written consent of SubscriberMail, LLC. If you
receive this message in error, notify the sender and destroy this
message and all attachments immediately. Thank you.

SubscriberMail is covered under US PATENT 6,769,002

12

Ryan P. wrote:

They don’t. I’m imagining broadening the concept of “filter” to
“component that handles everything needed to translate a part’s text
into whatever actually goes on the site”. This includes things like
simple Textile filters, but could mean rich text editors, image
browsers, LaTeX environments :wink: …anything that could persist to
the part’s text field and somehow present an admin interface, and
render something for the public view of the site.

Gotcha. I will have to think about this. My gut reaction is no, but I
can see why you believe it has value. My main concern is to keep things
as simple as possible and this seems like it would make filters about 5
times more complicated with little real gain.

The Rich Text view holds the most weight for me. While I’m not
interested in this being part of the core, it does seem to be asked
about frequently. Providing hooks into the admin interface for it may be
a good idea.

What’s the use case you want it for? That is, what are you trying to do
that makes you feel you need it?

So I guess I was just referring to the idea that the images could
simply be referenced by URL string or some other text-only
representation, instead of adding to Radiant’s DB model to hard-code
this functionality that different folk will want to implement
different ways for their own needs. Which to me would suggest
something more like a central asset store than an attachment system.

I’m having trouble seeing why making this work off or page parts would
be an improvement. It seems like if we go with the whole central asset
store concept it would be better implemented as being a built in part of
the admin interface. Or again, provide hooks in the plugin system so
that it could be inserted into the admin interface.

–
John L.
http://wiseheartdesign.com

13

Xavier,

I would love to see what you have even if its rough. I have a project
coming that Radiant seems perfect but the Assets part is critical. I
need to be able to attach files (PDFs, Word docs, etc) to pages. I was
thinking of hacking it sorta outside the Radiant way because I don’t
have the time to really find out how to do it right. But if you have
something that works…

Sincerely,

Adrian M.

Xavier wrote:

I’m with John on the assets issue. Look at the comps he posted a few
weeks ago and you’ll see how clean the workflow is!

I’m afraid that having typed parts may introduce a lot of extra
complexity to the core of Radiant.

I already have a working implementation of the page attachment on my
experimental branch of Radiant and I really find this solution very
elegant (I use two seperate models/tables Attachment and
AttachmentData with proper method delegation to the associated page).
It offers an easy way to organize your stuff and also provides clever
and painless (plain DRY) namespacing for all your assets.

(Now I just gotta take some time to polish the UI part and merge my
code with the svn edge and send my patch but I’m kind of overworked at
the moment, sorry… is there any deadline/milestone set for this
feature?)

Xavier

http://defrang.com

On 7/10/06, Andi [email protected] wrote:

me.

are stored in the DB (or storage is choosable for each file). It

–
Posted via http://www.ruby-forum.com/.

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

–

14

On Jul 10, 2006, at 5:17 PM, Xavier wrote:

I’m afraid that having typed parts may introduce a lot of extra
complexity to the core of Radiant.

Just to point out, we already have typed parts. There, it didn’t
introduce any complexity. :slight_smile:

My idea is, right now we’ve got a way to create something that uses
the text string of the part and translates it to HTML. If that
functionality, currently called a “filter”, grew the ability to run
its own admin pane, we could implement things like rich text editing
and image management, with one added hook (or perhaps a related set
of hooks).

Not exactly J2EE.

–
Ryan P.
Senior Developer, SubscriberMail, LLC

3333 Warrenville Rd.
Suite 530
Lisle, IL 60532
(630) 303-5072

Not Just Email…SubscriberMail

This message (including attachments) contains proprietary information
which may not be disclosed or used beyond the purposes of this
message without the written consent of SubscriberMail, LLC. If you
receive this message in error, notify the sender and destroy this
message and all attachments immediately. Thank you.

SubscriberMail is covered under US PATENT 6,769,002

15

I’m with John on the assets issue. Look at the comps he posted a few
weeks ago and you’ll see how clean the workflow is!

I’m afraid that having typed parts may introduce a lot of extra
complexity to the core of Radiant.

I already have a working implementation of the page attachment on my
experimental branch of Radiant and I really find this solution very
elegant (I use two seperate models/tables Attachment and
AttachmentData with proper method delegation to the associated page).
It offers an easy way to organize your stuff and also provides clever
and painless (plain DRY) namespacing for all your assets.

(Now I just gotta take some time to polish the UI part and merge my
code with the svn edge and send my patch but I’m kind of overworked at
the moment, sorry… is there any deadline/milestone set for this
feature?)

Xavier

http://defrang.com

On 7/10/06, Andi [email protected] wrote:

me.

are stored in the DB (or storage is choosable for each file). It

–
Posted via http://www.ruby-forum.com/.

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

–