I like your concept and I agree in a perfect world this would be ideal.
However, I think this would only work if we had a very diligent working
group that is constantly defining the spec and making it public. The biggest
hurdle is documentation and awareness. In addition, the debates that would
erupt over set APIs could drag on. Just look at how long people are still
talking about the forums, and that has no impact on the code itself.
With that said I am still interested in some of the basic concepts. I would
like to see the concentration on the UI core, if this is to be pushed
forward. UI design hasn't really changed, and I think its in poor practice
to change established behavior. I'm talking about things like scrollbars. I
think having a common API would be a good thing.
The problem with UI components in a browser, is the fragmentation of pieces.
HTML/CSS/JS all have an impact. Let me give you an example. If I have a
modal window that uses a standard API and I added in a scrollbar I expect
the scrollbar to automatically be skinned to match my modal. I shouldn't
have to worry about skinning each UI piece, the look should cascade down. In
addition to defining the object interfaces I think we would need to define
the UI hooks. So lets say I define a 'default' UI look. I implement a few
components in a page to utilize them. Great. Then I want to add more
components that use a 'custom' UI look. The problem that starts to arise is
naming collision, to associate to the appropriate styling. I am not saying
its a blocker. Just trying to help box and define the problem so the focus
can be narrowed.
On Sat, Oct 4, 2008 at 2:25 AM, VirtuosiMedia <[EMAIL PROTECTED]>wrote:
>
> 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
>
