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

[Adagio]

I know there has been some discussion on using more objects lately, so I'll
throw in a suggestion on how to do callbacks in an oo way in Drupal that I
believe is popular elsewhere. This is tied to an object form of "widgets".
I'm assume there is some rationale behind not using more objects, but I've
wondered why not do something like the following as I've gotten to know
Drupal over the last months. If it's a "cult thing" it might not be the best
of reasons ;-). This is easy easy, clean, flexible and more extendable than
todays way of doing things. And it works with php 4. Here is a brainstormish
rewrite of user_register:

/**
 * This is a rewrite of user_register. Now it's multipage.
 * There could for instance be different types of callbacks.
 */
class user_register extends callback {
 /**
  * default() could be called first on all callbacks. There could also be
"internal callbacks" as this have.
 function default() {
  $name =& $this->addwidget('textinput', 'name');
  $name->text = 'Preferred username';
  // other way of reaching properties
  $this->form->username->description = 'Between 6 and 30 characters';
  $pass =& $this->addwidget('safepass', 'password'); // shows two password
fields, but keeps the value in one variable.
  $pass->text = 'Password';
  $pass->description = 'Type in twice';
  $mail =& $this->addwidget('textinput', 'mail');
  $mail->text = 'Email';
  $mail->description = 'Make sure it\'s correct. You\'ll get an important
email';
  $this->addaction('Next step', 'profileinfo'); // submit button added.
Callback registered internally.
 }

 /**
  * Internal callback from default
  */
 function profileinfo() {
  $this->keeppostdata(); // serialize in session variable
  $this->addinfo('This is not required, but if you fill this - we like');
  // widget for adress, locale aware. This should show multiple fields;
street, number, coutry etc.
  $this->addwidget('address', 'adress');
  $this->addaction('Register', 'register');
 }

 /**
  * Additional validation of form. What widgets should do in terms of
validation, they do. Rest is done here.
  * This is called whenever a form is submitted.
  */
 function validate($action) {
  switch ($action) {
   case 'profileinfo':
     // Adress validation taken care of in widget. Nothing here.
   break;
   default:
    // Username validation
    if ((strlen($this->postdata['name']) < 6) or
(strlen($this->postdata['name']) > 30))
     $this->error('name', 'Username must be between 6 and 30 characters');
    if (db_query("SELECT count(*) FROM {user} WHERE name=%s",
$this->postdata['name']))
     $this->error('Username is taken', 'name');
    // Passwordvalidation done in formwidget
    // an email widget could be made to check mail adress.
   break;
  }
 }

 /**
  * Internal callback from profileinfo
  */
 function register() {
  $p =& $this->postdata;
  // Note the use of adress.
  if (db_query("INSERT INTO {user} (name,password,mail,street,country)
   VALUES ('%s','%s','%s','%s',%d)"),
   $p['name'], $p['pass'], $p['mail'],$p['adress']['street'],
$p['adress']['country_id']))
   $this->addinfo('Thanks for registering with us. Check your mail');
  else $this->addinfo('There was a database error, please try later');
 }
}

The menu_execute_active_handler() could creates an instance of this object, 
and
an execute() method or something of it. This execute method may be
overridden.
By default, it can call the default() method, validate() with an $action
argument if a form has been submitted or some internal callback. It should
also check with the different widgets if they validate the values they've
recieved. It takes care of some common tasks, while letting the
module/callback have complete control by allowing it to override methods.

----- Original Message ----- 
From: "Bèr Kessels" <berdrupal at tiscali.be>
To: <drupal-devel at drupal.org>; <rob at robshouse.net>
Sent: Tuesday, May 10, 2005 10:49 AM
Subject: Re: [drupal-devel]Widgets (was Enable multiple block regions (not 
just "left" and "right" sidebars))


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 ]