Posted by Merlin on Sat Jul 14, 2007 4:25 pm.
While I'm on the topic, these are the remaining TODO items before I am ready to call Panels 2 beta:
- Pluggable context. This means letting the panels page have a context selector (think: argument in Views) that can validate the argument and load the context. I want to supply user, node, vocabulary and taxonomy term contexts, and it needs to be able to identify basic Views arguments to correlate how a View can automatically be promoted to function with this context.
- To accomplish the last part of item 1, views.inc needs to be smarter; it needs to be able to look at a view and provide views more intelligently. The administrator needs to be able to configure how some of the views are provided as well. It needs to be smart enough to not offer the 'page' view for a view that doesn't have one, and not offer the 'block' view for a view that doesn't have one. It needs to be smart enough to not offer any of that and instead offer only preconfigured views to users who shouldn't necessarily be seeing that data.
- Arguments embedded in the URL. i.e, node/%/panel.
- Documentation. I haven't done much. I just did a little; I need to do a lot more.
- There are some Drupal-offered blocks that require a context, and this needs to be reflected -- the author information block, for example, requires a context. The thing is, it's pretty dumb about context since it mines the URL to acquire the context. This is not how Panels wants to operate.
- panels_mini.module (Wim Leers is working on this). This is one of my requirements for Panels 2 beta.
Surprisingly, that's it. There are other things that could theoretically go in, but I don't think they need to hold up a beta. Things like the dashboard converter and some other panels-related modules.
For people who want to help, there's the Panels working group over on g.d.o.


Contexts = theme functions
I love the idea of context switching. It would be a nice trick to have contexts and theme functions merge. With the new templating possibilities in D6 where every theme function can easily have its own tpl.php file, and in the future real OObjects with methods (for traversing contexts/relations), this would lend itself to a Drupal object based query language that could be reused in theming, business logic, permissions and so forth.
Post new comment