Views widgets

We're planning on providing pages and blocks as widgets. Views can be displayed as pages or blocks. The AJAX functionality works when embedding a view block/page in an IFrame. My question is, are there advantages to providing Views widgets as other types of widgets (JavaScript, Google Gadgets)?

MySpace (and perhaps other networks) doesn't allow embedding iFrames. Therefore, I believe it imperative to allow at least one other type of widget, probably as JavaScript.

looks like you're already addressing this with http://drupal.org/node/267186

Sorry, my question was poorly worded. Of course I'm planning on types of widgets in addition to IFrames. My question is: Are there any advantages to adding more functionality for embedding a View when a View can already be embedded as either a block or a page?

As I mentioned in the usability issue there are multiple reasons to have views support. One big example would be to use arguments to determine the widget your site serves up, so that one drupal path with an argument and/or tokens could produce multiple widgets (i.e. you should be able to have a single taxonomy widget that lists any tax term pages you want). If you then enabled this by adding something like taxonomy/term/%1 (or whatever the argument was) you could create widgets on the fly with taxonomy terms.

This would definitely make this module much more usable, imo.

Please see this for more info on how this works: http://drupal.org/node/54455

I looked into Views2 a bit more. Currently, Embed Widgets already can handle embedding views that accept arguments. The view simply needs to be created and then the path to that view added as a widget source.

I think that some default views should be created by Embed Widgets using hook_views_default_views(). For example, we could create a generic view that displays a list of all nodes tagged with taxonomy terms given as arguments. That view could then be overridden and customized further by an admin to restrict certain content types or vocabularies.

Then, when a user customizes a widget, they can choose to add that view as a tab in their widget and give one or more taxonomy terms or content types as arguments. We could even have a view that accepts the current user as an argument so that they could create a widget that lists recent content contributed by them... a very personalized widget!

After looking at Views a bit more, I think it will work rather nicely and will add make for some very powerful features!

Do you mean the path to the View itself or to the page the view is making? If it's the first- how does Embed Widgets know which version of the view to grab? If it's the second you really should put something in the help text on that page...

I wouldn't bother with the default views: these are created by other modules, with several provided by default, including the one you mention (I believe). That functionality seems out of scope for this module.

I'd originally envisioned a View Style for "Widget" (from the drop-down under Basic Settings). However, as you're already overriding page layout, that seems unnecessary, as long as it's well-documented.

With the caveat that someone could conceivably want a particular view to ONLY be available from a widget, and not with its own stand-alone "page". As long as you're able to provide Blocks as Widgets, however, that would be adequate. (That would probably apply to Panels as well.)

You'd have to consider the "more" link in that case as well. Again, makes a stronger case for not using a page view, and using a block view instead (or a new 'widget' view style).

I also envisioned a new View style for Widgets, but it isn't necessary. Here is how I see it now:

We allow Views to be added to widgets, the same way I've done with blocks. Suppose I had a view named "my_view".
That view can then be embedded by calling a simple function built-in by Views:
<?php views_embed_view('my_view', 'default'); ?>

The display type could also be selected by the user: 'default', 'page', or 'block'. If someone only wanted a view available to a widget without also creating a page or block, they can select 'default'.

Now, what about arguments? Another function can be called:
<?php views_get_view('test_view', $reset = FALSE); ?>
This will get all the information about the view. This will tell the Embed Widgets module how many arguments the view accepts. It can also be determined what type of arguments the view takes.

Using this information, a user interface could be create to 'expose' those arguments. Suppose that "my_view" accepts a taxonomy argument. If a user adds this view to a widget, an additional field will be displayed when configuring the widget. This field will accept the taxonomy argument. For IFrame widgets, arguments could be passed to the widget in the URL. Those arguments would then be passed to the view. For example:
<iframe src="http://www.mysite.com/embed-widgets/1/embed/iframe?term=Drupal"></iframe>
That could be the URL that is embedded in the IFrame if the user wanted to embed a view and provide "Drupal" as the taxonomy argument. Passing arguments through the URL would allow users (non-admins) to customize their widgets by entering their own arguments.

I hope I'm making sense. :) Does this seem like a good approach?

@aaron: Yes, I know that the existing default views are created by other modules. I was suggesting that it might be useful for the Embed Widgets module to create its own default views that people will find useful to embed in widgets.

I think this is a fantastic idea that could open the door to a great user interface for the module! I say go for it...

Embedding of views now works. Next up: Views Arguments!

The latest dev version creates a UI to input values for each argument a view accepts.

Now I'm trying to figure out how to make it as user friendly as possible. I'm thinking of making some autocomplete functions for some argument types. Some already exist (user, taxonomy).