[Radiant] Part types

[Ryan Platte]

On Jul 10, 2006, at 4:10 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.

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.

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 Platte
Senior Developer, SubscriberMail, LLC

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

Not Just Email...SubscriberMail
http://www.subscribermail.com/

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