What needs to be done now to ensure that more advanced features can be added in the future?

For example, something that would be nice would be the ability to create groups or lists of widgets (probably using taxonomy). Corresponding navigation tabs would then be provided within the widget to switch between widgets. That way, a number of widgets could be provided in one embedded widget.

Also, widgets that first display a login widget and then other widget(s) that require authentication to access is something to keep in mind.

I won't be able to implement many ideas during Summer of Code, but I'd like to keep the ideas flowing so that I can help make this project as extensible as possible.

CommentFileSizeAuthor
#17 js-tabs.patch8.54 KBjtsnow
#16 js-tabs.patch8.9 KBjtsnow
#4 Multi Widgets.patch30.92 KBjtsnow

Comments

nedjo’s picture

a number of widgets could be provided in one embedded widget

I'm hopeful that the use case of combining various items can be addressed natively in Drupal through e.g. Panels rather than requiring us to combine different widgets.

jtsnow’s picture

My reasoning behind including multiple widgets or multiple sources in one widget is that widgets are typically very small. To put more content in the small space, many third pary API's allow the creation of tabs. I am planning on implementing widgets as Google Gadgets as part of my summer of code project. The Google Gadgets API includes a tabs library: http://code.google.com/apis/gadgets/docs/ui.html#Tabs

You can then fill the widget tabs with content.

What if we put a "sources" field in the database schema? This field could hold an array of sources. Sources could be blocks, feeds, views, nodes, pages, etc. We could create a tab for each source. Then, when editing a block/page, we could have a form that lets the user add that block/page as a source in a widget that they have created.

For IFrame widgets, the sources can also be displayed as tabs/links across the top of the widget.

jtsnow’s picture

I have added the multi-widget functionality. It required changes in all the modules. I have set up a demo/test site. Rather than trying to scour through my code to see what I am talking about, try out the demo site:

http://www.deviable.com/widgets

Login with test/test. I have created a multi-widget that contains sources from blocks, views as blocks, and pages. I also created a simple widget theme.

Let me know if you like this direction or if we should scrap the multi-widgets idea. I think that adding tabs can be a powerful feature.

jtsnow’s picture

Status: Active » Needs work
StatusFileSize
new30.92 KB

Also, here is the patch for these changes. The code it needs quite a bit of work, but I wanted to get feedback on the UI and these new features.

nedjo’s picture

The demo is looking very good. I had a quick look at the patch, no time at the moment for thorough review. I'd say go ahead though. There's going to be a use case for this.

jtsnow’s picture

Ok, I've integrated these changes. The official release is a mistake. (Still learning how to use CVS!) I've been looking for someone who can remove that for me.

I have a few ideas on how to improve upon the multi-source widget features:

  1. TabView (http://developer.yahoo.com/yui/tabview/) is part of the Yahoo! UI library. I think it's pretty slick. A tabbed user interface can be created through HTML markup or through JavaScript. Tabs can also be added/removed dynamically and load tab content from external sources. The current implementation of tabbed widget browsing requires a page load inside the iframe each time a tab is clicked. Using the TabView library would eliminate the extra page loading. It may also be a simple way to implement JavaScript widgets without dealing with namespace collisions in the case where multiple widgets are embedded on the same page as was discussed early on (http://groups.drupal.org/node/9633).
  2. A "embed_widget_sources" database table: Having the widget sources stored in a separate table will pave the way for a few things. Administrators will be able to create a list of sources (blocks, vocabularies, views, nodes) that are available to be embedded. This may be an initial approach to allowing users to create their own widgets (see #268340: Allowing the user to create his own widget??). A user could choose from the list of sources to add to their custom widget; the administrator still has control over what content is embeddable. My only concern at this point is that I don't want to over-complicate the project right now. But, if an additional 'sources' table this is worth implementing, then it would be easier to do it now than later.

Any thoughts?

jtsnow’s picture

I just found that the jQuery UI library also offers a tabs library. This would probably be more suitable than Yahoo's. Some demos:

http://ui.jquery.com/functional_demos/#ui.tabs
http://stilbuero.de/jquery/tabs_3/

nedjo’s picture

Have a look at my Tabs module, http://drupal.org/project/tabs, which implements the jQuery UI tabs plugin. You could introduce it as a dependency.

alex ua’s picture

Given jQuery's integration with Drupal I definitely think that you should go in that direction.

jtsnow’s picture

Thanks nedjo, the tabs module works great, but I'm trying to determine the best way to implement the Tabs UI.

I have a working version where I simply add a 'tabpage' for each source in the widget...

<?php>
foreach ($embed_widget['sources'] as $sid => $source) {

...

    $form['widget']['tab'. $sid] = array(
      '#type' => 'tabpage',
      '#title' => $tabTitle,
      '#content' => $tabContent,
    );
}
return tabs_render($form);
</?>

That works fine. However, I have been using templates to theme the widgets. I could pass the contents of tabs_render($form) to my template and stick it in there, but that defeats much of the purpose of the template file away since much of the markup will be provided by tabs_render($form).

Adding the markup for the tabs in the template instead of having it rendered would be simple. I suppose I could then just call tabs_load() from my module, but that defeats much of the purpose of having the Tabs module as a dependency.

Is there another approach that I'm not seeing? I'd like to keep all the markup within the template file to keep things consistent.

nedjo’s picture

Try this: specify a '#theme' callback for the tab pages and for the the tabset. Like this:


    $form['widget']['tab' . $sid] = array(
      '#type' => 'tabpage',
      '#title' => $tab_title,
      '#content' => $tab_content,
      '#theme' => 'embed_widgets_tabpage',
    );

And ditto for the tabset. (Note two small changes I've made in your code: as of D7 there is now a space between a string and the . concatenator and I figure we might as well start using it; and Drupal uses underscores rather than camel case in variable and function names.) That should give you the theming flexibility you need.

jtsnow’s picture

That makes sense, but is there a way to pass more arguments to the theme function in addition to $form? Or do I need to pass additional variables as elements of $form?

nedjo’s picture

Yes, you could add more form element properties if you need them.

What exactly are you needing to do? If it's allow a custom look for the tabset, can you achieve that just through CSS? If not, what are the changes needed to the rendered HTML that you need? Could you add what you need as a patch to tabs.module, improving the general themability of tabs and tabsets?

jtsnow’s picture

I am trying to make the template for iframe widgets as friendly as possible. Since I'm overriding the theme functions, all I really need from Tabs is the JavaScript. Currently, variables such as $page["breadcrumb"], $page["created"], and $page["taxonomy"] are available in the template. They need to be in a 'tabpage'. I could append them to $tab_content, but then their placement in the markup is set in stone.

The other option is making additional elements in the $form array like so:

<?php>
$form['widget']['tab'. $sid] = array(
      '#type' => 'tabpage',
      '#title' => $tab_title,
      '#content' => $tab_content,
      '#theme' => 'embed_widgets_iframe_tabpage',
    );
$form['widget']['tab'. $sid]['page'] = $page;
$form['widget']['tab'. $sid]['embed_widget'] = $embed_widget;
</?>

This seems like extra overhead. Why not implement my theme as is, and simply include the JavaScript necessary to implement the Tabs UI?

<?php>
tabs_load();
...
print theme('embed_widgets_iframe_page', $embed_widget, $page);
</?>

Would that work?

nedjo’s picture

I'm not totally following what you're doing. If you need to theme the content of a tab page, you can do so before adding it to a tab.

  ...
  'content' =>  theme('embed_widgets_tabpage', $widget),
  ...

Does that not work? If not, can you improve the theming of tabs in tabs.module so that it does?

Before defaulting to just using the library directly, which of course is always an option, I'd like to understand the limitation that makes that necessary.

jtsnow’s picture

StatusFileSize
new8.9 KB

My problems yesterday were because I wanted to theme the whole widget with just one template. Once I abandoned that I idea, this is what I came up with. Here is a patch of what I have so far.

Problems:

  1. Using '#theme' in the tabset element causes the tabpages to not render.
    <?php
    $form['widget'] = array(
        '#type' => 'tabset',
        '#theme' => 'embed_widgets_iframe_tabset',
      );
    ?>
  2. The tabset is rendered first using the theme function in the Tabs module and then using my template. Both are output.
jtsnow’s picture

Status: Needs work » Needs review
StatusFileSize
new8.54 KB

Ok, I got it working. You can demo a widget using jQuery Tabs here: http://deviable.com/widgets/embed-widgets/3/tabs

It works perfectly except if the page is reloaded in FireFox, nothing is displayed, even though the HTML is output the same. In IE, everything works after reloading. Any idea why this is?

Here is the latest patch.

jtsnow’s picture

Status: Needs review » Closed (fixed)

Old...