I started looking at MySite/Panels integration today. From my end, the obvious starting point is making MySite-defined content available as Panels.
Why?
- MySite currently defines 14 plugin types (+3 contribs), which would explode the options available to Panels.
- MySite now has a mysite_display() function that makes accessing a MySite content element possible from within another module or theme.
Here's the issue I ran into, and it may be that I simply haven't dived deep enough.
1) It is possible that some MySite content types (like term.inc) may produce hundred or thousands of options. How would the current JS/popup window UI of Panels handle that? Does it allow pagination? If so, how.
2) Ideally, I think, the Panels settings would allow the admin to enable certain classes of MySite-defined content (blogs, terms, users) instead of the individual options within those. Then when adding content to a panel page, the user could select from the list of available content of that type.
As I see it now, there doesn't seem to be a way to do the second, and doing the first would overwhelm the UI.
Attached is the first pass. It doesn't generate content, just options. Only the panels_admin_content_types_mysite() function needs any feedback; the rest are stubs.
| Attachment | Size |
|---|---|
| mysite.inc_.txt | 4.63 KB |
| mysite2.inc_.txt | 6.54 KB |
Comments
The basic panel page has a
The basic panel page has a very simple content enabling mechanic, but something that would be used for MySite would, I expect, have a much more complex mechanic of enabling content.
Right now, I have a simple 'required context' mechanic, where content will only include itself if that context is available; at the moment, nothing actually uses that, but it's there at the bottom level. The next version of panel pages will actually use that.
I think we can make this mechanic more complicated, if we need to. I'm willing to make changes to the Panels API to make this work.
Ideally, the number of options available when adding content needs to be reduced; so hundreds or thousand of options should theoretically be right out.
From what you've said about 2) the required context may be enough.
(Naturally this isn't well documented, because nothing uses it, but search the code for the word 'context' and you'll see some places where it's at least respected, if not actually used).
The big UI problem
With regards to: "Ideally, the number of options available when adding content needs to be reduced; so hundreds or thousand of options should theoretically be right out."
Well, based on the site content and the MySite API, it is possible to have this many options. Even desirable. Say, for example, you want to add the X most recent posts by merlinofchaos at groups.drupal.org. The mysite_type_user_options() list is "all users on groups.drupal.org."
In the current UI, MySite handles this through AJAX-assisted search and paginated browsing of options. (Side note: one reason MySite doesn't have Panels-style JS for adding content is solving this problem in a JS/popup window. Ideally, we'd find a single solution that works for both modules.)
I think, ideally, in the Panels world, as the admin, I'd be able to configure the MySite content classes under Panels settings. E.g. "allow blogs, users, and terms".
Then, and I think I can make this work, in the form for adding that panel, you select "blogs" and then get a list of options (and a search box). Done that way, I think it can work. And this sounds like the 'context' that you're talking about.
Stupid debug question: How can I call the JS/popup page as a regular URL callback during testing?
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
OK
Second version of the plugin works as I would like -- http://groups.drupal.org/files/mysite2.inc_.txt
With the caveat: It doesn't restrict the number of options returned. When you open the add/edit Panel screen, you'll get a radio set of all available options for MySite content type X.
What I need is a way to:
a) AJAX search the available options.
b) AJAX (?) paginate through the available options.
Thoughts? Code?
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
I think, philosophically
I think, philosophically speaking, what you're setting as options should more likely appear as its own content pane. You can easily create multiple Mysite categories, so for example you could have "MySite feeds" or whatnot. Of course, I suppose if you have thousands of feeds that could get problematic.
For example, each aggregator feed gets its own block. In places where we use nodes, we use an autocomplete to fetch one -- it's places like that where things get really difficult, because that point a WHOLE lot of content is available. But even pagers don't work well with thousands of feeds. You generally want something more like activeselect where you can drill down into categories and reduce the number of feeds to something digestible by the user.
An ajax pager probably won't be too hard to write, although we have an interesting problem in the popups with binding behavior, so we're limited in what javascript we can do based upon what the popup is smart enough to cause to bind. Perhaps we can come up with some kind of a method to help with that, too.
I'm just using feeds as an obvious example here; I'm not familiar enough with mysite's contents to know what else might show up as having hundreds or thousands of variations. I suppose there's posts.
Note that from looking at this, it's also distinctly possible that you may want each mysite content type to show up as a distinct panels content type as well. There isn't much of a penalty for this but you can more closely tie the content types in that way, I think.
Yea
OK, so to create multiple MySite content categories through a single plguin: is that possible? Complex data sets (like taxonomy terms) are already grouped, so drill down would work.
Other obvious points where MySite has "too much" content for the UI: feeds, users, terms, posts, comments.
I was hoping to write a single MySite plugin for Panels that can serve as interpreter between the two interfaces, rather than trying to write a new include for each one.
What I really hoped to create -- and I think would make this easier -- is an additional step in the panel add form process. If the first screen (or the second screen) could be allowed to process just the form elements that I need, then it might be easier to do what I'm trying.
I tried to use autocomplete, but couldn't quite make it work. Problem is, the MySite API's autocomplete functions return strings as keys, not NIDs, by design. I suppose I could write a variant function that returns the nid.
I looked at the Panels node behavior to see if I can learn anything.
[Note: panels_node_autocomplete is throwing a SQL error:]
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
OK, so to create multiple
OK, so to create multiple MySite content categories through a single plguin: is that possible? Complex data sets (like taxonomy terms) are already grouped, so drill down would work.
Yes, it's just a matter of filling in the category as you like on each pane. Note how block.inc imports blocks and categorizes them as it needs to.
I was hoping to write a single MySite plugin for Panels that can serve as interpreter between the two interfaces, rather than trying to write a new include for each one.
This probably works ok; on the surface I'm concerned that you'll get a looser integration that'll produce a UI that isn't useful, but the more I think on it, the more I think that probably isn't true. So I retract this.
What I really hoped to create -- and I think would make this easier -- is an additional step in the panel add form process. If the first screen (or the second screen) could be allowed to process just the form elements that I need, then it might be easier to do what I'm trying.
I used to have this step, but I wasn't comfortable with how complex it made the UI. I can possibly put it back in so we can do more step by step stuff.
Other obvious points where MySite has "too much" content for the UI: feeds, users, terms, posts, comments.
User can be solved with an autocomplete; Panels already does node content, so it seems like it would be redundant. I'd rather make the Panels' node content do what you need than have two variations. That'll really confuse users. I hadn't thought about comments. Are comments something users really want to add to panels? Likewise with terms? Maybe I'm lacking vision here.
The general solution for feeds, I think, is that we should be sparse about the feeds we automatically provide, and let users create feeds from URLs and only provide feeds that are marked a particular way. I remember you said you did a lot of work on feeds, and in general I think this is a problem that is bigger than just "the UI can't hold it". I honestly don't think you really want to present massive lists of feeds to the users in any form.
Oh and I checked in a fix
Oh and I checked in a fix for that autocomplete. Silly quoting issue. I'm not sure why I've never run into it; maybe some mysql versions accept the " and some don't.
Arbitrary categories
<?phpif ($active[$type] && !empty($options['options'])) {
$list[$type] = array(
'title' => $options['name'],
'icon' => 'icon_contrib_block.png',
'description' => filter_xss_admin($options['description']),
'category' => array(t('MySite'), -1), // This doesn't have to be MySite. This can be anything you want. Per block presented.
);
?>
Per block presented
OK, what I don't grok from this is: Can I pass more than one category in the array? If so, in what format?
<?phpif ($active[$type] && !empty($options['options'])) {
$list[$type] = array(
'title' => $options['name'],
'icon' => 'icon_contrib_block.png',
'description' => filter_xss_admin($options['description']),
'category' => array($options['name'], -1), // So if I pass multiple categories, they all show up?
);
?>
That would give me X variations, which would be displayed as separate content elements in the Panels Admin? Will test.
As for term, et. al. Take a quick look at what MySite actually does. In general, it pulls the X most recent nodes that match concept Y. (Very similar to views, but with fixed definitions of what Y means).
And so on. Remember that MySite then lets the user choose how to display those node lists. The two current options are theme_item_list() and node 'teaser view' (basically).
There is a whole lot of crossover between the two modules. So working towards a unified API is where I'm going. First step is a "translation" layer, so that MySite content can be read by Panels, and vice versa. (Figuring that out will also let me understand Panels better.) Once that's worked out, we can start to eliminate redundancies.
Check out http://therickards.com/api/groups for API documentation, and the README for detailed info.
A good starting point to see what's going on, code-wise, is blog.inc. It lets a user add the X most recent blog posts from user Y.
http://therickards.com/api/file/plugins/types/blog.inc/MySite
The functions that I need to expose / translate / integrate with Panels are:
http://therickards.com/api/function/mysite_type_blog_options/MySite
http://therickards.com/api/function/mysite_type_blog_data/MySite
http://therickards.com/api/function/mysite_type_blog_search/MySite
http://therickards.com/api/function/mysite_type_blog_autocomplete/MySite
And don't forget the demo: http://therickards.com/mysite/agentrickard
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
OK, what I don't grok from
OK, what I don't grok from this is: Can I pass more than one category in the array? If so, in what format?
No, but that's because this is a single item, with an icon, a category, a title and whatever meta-data is required. You can pass back as may items as you like, each in a category.
Profile pulls selected elements from the user's profile.
The current user or select a user?
For something that can select users, for MySite purposes it may be better to have an intermediate step where a list or lists of friends are created, the content can restrict requested users to that friends list.
Then you can just add content icons per friend. "MySite profiles" Ryan's profile, Pat's profile, Sam's profile. "Mysite blogs" My blog, Ryan's blog, Pat's Blog, Sam's blog.
Likewise, each Droplet should likely be its own icon. "Mysite Droplets".
Also, where some of this stuff isn't tied specifically to mysite, it'd be nice to create a separate module so it can be generally available without actual MySite.
BTW, for selecting a 'current' user, that's one place where the 'context' stuff will really matter. THe $context object can contain arbitrary data.
More
Profile pulls only from the user/owner of a MySite page. You can only add your own profile to your collection. This is by design.
As for friends, the idea, from a MySite perspective, would be to use Buddylist (or OG) and then pull a list of users belonging to a specific list. The API would support plugins for both modules. I have been focusing on core feature support. Currently, the Users plugin lets the admin select which roles to expose to the list of options (since roles are part of core); then MySite users can browse through the list of available users.
I was looking at Crell's 'Component' module, and it might make sense if we abstract all content-generation to something like that. Use 'Component' as an API for pulling data back in requested formats (raw arrays, formatted HTML, lists), and then use the Panels or MySite engines as presentation layers.
http://drupal.org/project/component
I think Crell will be in Barcelona. I will.
The MySite module (current), now allows this form of abstraction. The mysite_render() and mysite_display() functions allow you to request content generated by MySite plugins for use in themes, blocks, etc.
If you look at
panels_content_mysite()in the attachment, you'll see how that works.<?php$block->content = mysite_display($conf['type'], $conf['type_id'], $conf['uid'], $conf['format']);
?>
Those functions could be abstracted into a submodule that could be used by other content-generators. Or we could all work with Component, etc.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
Back to the UI
OK, so I figured out how to return a separate content icon for each potential content element, but that can be overwhelming. What I really need to do is:
At the admin screen (panels_common_settings):
At the add content screen:
Is it currently possible to present just the categories at the admin level and all the options at the icon level? Will test.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/
The admin screen hasn't
The admin screen hasn't caught up with the categories feature, so at the moment it is not; however, it should be able to do that. I just haven't gotten back to that one.
Looking
I really wouldn't want the admin to have to enable all the MySite content elements individually. In the MySite world, the admin just enables the type handler (with optional configurations). Then a whole realm of icons becomes available to the end user.
It looks like I could separate the admin choices (limited to high-level categories) from the icon choices (all options in a category) if the $context was set?
Or if the content_types callback was split into 'content_types_admin' and 'content_types_icon'. Or if the function that invoked the 'content_types' callback passed an $op variable indicating the context.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
--
http://ken.therickards.com/