[Radiant] Part types

[dror tirosh]

I'ld think it is probably good to follow the same method the behaviors are
used.
So you can inherit normal "filter" action from one class and override them
if needed.
The default will just return the text area when asked for the interface and
store the data in the page_parts DB table when data is received. When needed
to output the data it will do nothing.
any of the existing filters will only overwrite the output function by using
the current filter function in the existing filters.
We can probably do that by enhancing the current TextFilter class, a few
changes in the current admin implementation.
The output can be delegated to the filter in the parse functions in the
behavior.rb
I wouldn't mind giving it a go over the next few days and see if I can send
you guys something to look at.
Dror


On 7/10/06, Ryan Platte <ryan at subscribermail.com> wrote:
>
> On Jul 10, 2006, at 11:15 AM, dror tirosh wrote:
>
> > I agree, and I also think it might be a good idea for the filter
> > (which probably should be called something else in this approach)
> > to be called when the data is entered/changed by the admin
> > interface. This way a new filter might edit before DB insertion or
> > maybe put it into a different DB table, write it to a file, etc.
>
> I strongly agree. Lifecycle hooks like that make a plugin-system much
> more loosely coupled. It's the approach that Eclipse uses, as
> discussed by JUnit co-creator and Eclipse lead Erich Gamma here:
>
> http://www.artima.com/lejava/articles/reuse3.html
>
> Rails's monkey-patching is a lazy hack, frankly. It's understandable
> for RoR's goals, but it lacks the characteristics that will permit
> the stability available to well-designed OO systems -- which is why
> Rails plugins break, and break again. So we should do better.
>
> I'll be happy to lead this effort if we get agreement on what to create.
>
> --
> 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
>
>
>
> _______________________________________________
> Radiant mailing list
> Radiant at lists.radiantcms.org
> http://lists.radiantcms.org/mailman/listinfo/radiant
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.radiantcms.org/pipermail/radiant/attachments/20060710/a350a8c9/attachment.html