[drupal-devel] Widgets (was Enable multiple block regions (not just "left" and "right" sidebars))

[Bèr Kessels]

Just a short note:

On the HIG meetings we decided that we will get some of these widgets in the 
form of new form_foo functions. 

I have the notes and results here; but i did not get a single response on my 
previous notes, so I will not bother spending my time on more notes. However, 
if people are interested (so, let me know it if you are!) I will publish a 
list of widgets we agreed upon.

Ber

Op dinsdag 10 mei 2005 09:58, schreef Robert Douglass:
> factoryjoe,
>
> Your idea of "shareable layouts" and semantic layouts has a word
> already; widget. Isn't that true? Here you have touched on an important
> point - Drupal doesn't do widgets well. The widgets that we have now are
> the form_xxx functions in common.inc, but almost nobody ever uses
> anything but the default widget. Why? Because it is too hard to get
> overriding theme functions into your code and you can't share them easily.
>
> When I read your description of a "Person" layout, I think more
> immediately to date selectors. We have this really great event module
> which has a crappy way of entering dates. Much better would be one of
> the dozens of nifty calendar widgets that people have coded on
> SourceForge. Those are widgets.
>
> What I'd expect from a widget is that I can find it in a repository on
> Drupal, understand from a png what is it, drop it into a directory on my
> Drupal install, and activate it on a site/module basis (kind of like
> HTMLArea does with textareas). This is impossible now because the widget
> would have to belong to a theme or module to get included.
>
> The best widgets available in the Drupal world at the moment are the
> field.incs of flexinode, and it demonstrates what can happen if the
> widget loading mechanism is abstracted. I contributed a color picker
> (don't know if anyone ever used it) which is a perfect example of what I
> mean. There are many other ways to do a color picker, and anybody could
> contribute them too - just give them a different name and drop them into
> the flexinode/contrib dir. Then when it comes time to choose a color,
> there is a choice of tools on how to get the job done.
>
> There are a couple things we'd need in order to make our theme system
> widget aware. First, we'd need a widgets directory (naming open) that
> gets scanned and the file paths saved in system. Widgets can only work
> if they are drop-in code, not dependent on being loaded from a specific
> theme.
>
> Then we'd need a way of making a theme method widget aware. There is
> currently a hierarchy of places Drupal looks when looking for a
> theme('widget', x, y, z) function. It should be possible, probably from
> the administrator UI, to activate widgets that would then be pushed to
> the front of the line in this hierarchy.
>
> Widgets need not be limited to input forms or interactive UI elements.
> Anything with a theme method could take a widget. Like the Person
> example - there could be several Person widgets, each of which put the
> "name" and "picture" in different places, etc.
>
> Adrian was messaging me some of his ideas for the future of Drupal
> theming and it sounded like this sort of functionality was definitely a
> part of it, so perhaps he'll chime in with his views.
>
> As for the regions that chx and Ber are working on, I see that as
> completely separate to widgets, but that the two of them go hand-in-hand
> for making Drupal even easier to theme.
>
> cheers,
>
> Robert
Regards,
 Bèr
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]