[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