[Radiant] Part types

[Xavier]

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 <monodeck at gmail.com> 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.
>
> 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
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Radiant mailing list
> Radiant at lists.radiantcms.org
> http://lists.radiantcms.org/mailman/listinfo/radiant
>


--