[Radiant] Part types

John W. Long ng at johnwlong.com
Mon Jul 10 17:07:07 CDT 2006


Andi wrote:
> 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.

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 Long
http://wiseheartdesign.com



More information about the Radiant mailing list