It's definitely an interesting idea. If you have some working
examples, please do share.
One thing that I've really tried to concentrate on in building my
classes is to relegate as much of the style to CSS as possible. For
instance, say you create a modal window class. Instead of creating an
option in the class for the color of the background, I would instead
create an option to assign the window a specific CSS class name or id.
That way, instead of limiting the background to hex color values, you
can include images as a background as well, plus you can assign the
window anything else you can assign via CSS. Plus, you don't have to
write an option in your class for every possible change that a user
could think of, so it saves code. Your "sockets" can be accomplished
with custom events, I think, like onModalOpen and onModalClose.
I really like the ideals of using HTML for structure, CSS for style,
and JavaScript for behavior. There will always be a little overlap,
but I think that by separating the three, you really make everything a
lot more customizable and easier to maintain.
On Oct 3, 9:20 pm, "Iván N Paz" <[EMAIL PROTECTED]> wrote:
> Hello people...
>
> I have so far accounted for over 50+ production quality plugins for
> mootools and 100+ that are nearly there with just some touches by the
> developer.
>
> There are lots of plugins repositories around the net already, some
> with lots, some with less.
>
> Isnt it time that the plugins developers take into account a really
> pluggable architecture when creating their stuff (myself included
> here)
>
> This would certainly not concern the core developers (but yes... maybe
> them too) and take this thought into account.
>
> An example here of what I'm talking about.
>
> Take a script (lightboxy style for instance) that loads some remote
> content and that content needs to be scrolled.... In this case, the
> developer of the lightbox would take care of all the ajaxing,
> animating, and cope with the fact that the content might need
> scrolling or not, and render scrollbars accordingly. (what If i love
> the way the remote part works, but not the scrollbars?? [i know,
> extend/implement/inherit, but keep reading]
>
> If we (the community and developers) agreed on some kind of draft
> (maybe we just dont need to go so literal here) and deal with this
> fact we could be doing this in a future:
>
> var myBox = new AjaxLoader({
> url:'/path/someurl.php',
> scrollbars: ScrollerClassName,
> etc: etcval,
> etc2: etcval2
>
> })
>
> (The example is lame, I know, its just a proof of concept)
>
> In this example the main caller class would do all its normal process,
> then instantiate/invoke the scrollbar class that would render them...
>
> To make this work... the people that develop ScrollBars would provide
> some common methods (interfaces???) to deal with his class (create,
> get, display, update, etc...) that the caller class [AjaxLoader in
> this case] would call to render scrollbars after content loaded...
>
> In this case you would use an object/class that has sockets created in
> order to plug there other peoples stuff.
>
> Sounds like a pretty weird/useless idea?
>
> ps. I have done a lot of mootooling these days.. most of the stuff
> I've done i've done it using class and following more or less this
> kind of pattern.
>
> - Objects with Sockets [that will take other classes and plug them in]
> - Objects with interfaces [that would plug into my sockets]
>
> Im planing on releasing some of the stuff (mainly mashups) as soon as
> I have the time and share it to anyone that finds some use for it!!!!
>
> Best regards
> Ivan
>
> --
> ◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦◦www.ivanicus.com
