[Radiant] Part types

John W. Long ng at johnwlong.com
Tue Jul 11 09:53:06 CDT 2006


Ryan Platte 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  ;-)  ...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 Long
http://wiseheartdesign.com




More information about the Radiant mailing list