Most frameworks have a convention allowing apps to expose reusable
"blocks" or "portlets" etc. These are views which can be embedded in
any page, which may take context passed from the main page view.
For example, a client wants the login form (of Pinax's account app)
displayed on the homepage. Great. I can just reuse the existing view.
Well, no, since the existing view returns a fully-rendered page.
That's the essential problem with making views reusable in this way.
I'd like to have access to all of an app's views for placement on any
page.
How can we make view reuse easier?
- clever hacks (maybe just grab the block you want from the template
parser? possible to override the "extends" tag?)
- architectural directions (return "bare" views, wrap them up in a
site template ?)
How do other systems handle it, and with what level of success/
tradeoffs?
- Grok viewlets?
django-app-plugins seems interesting. It allows the admin to place app-
supplied plugins through the admin? Is it possible for the plugins to
be passed context form the containing view? This is a limitation in
Drupal's blocks system (most blocks guess context by looking at urls
and other globals)
Eric Drechsel wrote: > django-app-plugins seems interesting. It allows the admin to place > app-supplied plugins through the admin? Is it possible for the > plugins to be passed context form the containing view? This is a > limitation in Drupal's blocks system (most blocks guess context by > looking at urls and other globals)
In Django this is usually done with template tags, which may get the template context.
I did not try them, but in addition to django-app-plugins, I know of thwo other projects doing something similar:
The Internet runs on free software, and not because it has copied anything from Microsoft. The proprietary software guys like to accuse free software of not innovating [...]. That's just not true, but guys like the Mono Project are reinforcing that stereotype. - Mark Shuttleworth, June 2008
django-chunks is for storing one-off content blocks in the DB, then
placing them in templates via the chunks templatetag. It's definitely
related, since it follows the same "provide globally, place at
runtime" workflow that I'm interested in (coming from Drupal, where
that is the norm, and where the builtin "boxes" features of
block.module serves the same purpose as chunks). I use chunks for
allowing content editors to update template text and I think it's
great.
I was referred to django-modular by James iirc earlier, and it seems
right up the same alley as Drupal's hugely powerful Panels [1] module.
My goal is actually to implement panels for Django, although first it
is important to abstract out an API for providing reusable components
which is as general and simple as possible. That's one place where
Panels needs alot of refactoring (although to be fair Earl developed
it as a sort of clean-room remixing of the core drupal component apis,
not a small task) and perhaps django modular too (although I haven't
played with it yet, since it's not 1.0 updated). After all, not
everyone wants a DnD My Yahoo clone; some of us just want a way to
reuse parts of other people's apps without having to write a bunch of
redundant glue code.
I'll check out modular, and see if there is a good api in there to be
abstracted out. For bling, jQuery's Layout demo [2] looks nice (it's
really similar to Panels' content tab, while panels also includes a
simple layout editor)
> Eric Drechsel wrote:
> > django-app-plugins seems interesting. It allows the admin to place
> > app-supplied plugins through the admin? Is it possible for the
> > plugins to be passed context form the containing view? This is a
> > limitation in Drupal's blocks system (most blocks guess context by
> > looking at urls and other globals)
> In Django this is usually done with template tags, which may get the
> template context.
> I did not try them, but in addition to django-app-plugins, I know of thwo
> other projects doing something similar:
> The Internet runs on free software, and not because it has copied
> anything from Microsoft. The proprietary software guys like to accuse
> free software of not innovating [...]. That's just not true, but guys
> like the Mono Project are reinforcing that stereotype.
> - Mark Shuttleworth, June 2008
Ok, back on Earth, late October 2008, we have template tags. And
template tags are great! Also if many of the reusable views in Pinax
are converted to templatetags, there will already be a simple function
which returns the bare view, which can be decorated to work with any
component API that comes along in the future.
So I ask James + other Pinax core devs: if a bunch of "add templatetag
version of view Y" patches landed in the queue, would that be a
welcome direction?
On Oct 18, 2008, at 10:28 PM, Eric Drechsel wrote:
> Ok, back on Earth, late October 2008, we have template tags. And > template tags are great! Also if many of the reusable views in Pinax > are converted to templatetags, there will already be a simple function > which returns the bare view, which can be decorated to work with any > component API that comes along in the future.
> So I ask James + other Pinax core devs: if a bunch of "add templatetag > version of view Y" patches landed in the queue, would that be a > welcome direction?
We've already done a bunch of that and plan to do more.
(Pinax-specific discussion should move to pinax-users, though)
On Oct 16, 12:38 am, Eric Drechsel <ericd...@gmail.com> wrote:
> django-app-plugins seems interesting. It allows the admin to place app-
> supplied plugins through the admin? Is it possible for the plugins to
> be passed context form the containing view? This is a limitation in
> Drupal's blocks system (most blocks guess context by looking at urls
> and other globals)
This is exactly how app-plugins work, you can also pass in explicit
additional context on the plugin point.
I haven't had any time to get back to this, but I want to add a new
type of plugin point and plugin 'generic' (currently there are
registered and unregistered). This would allow any plugin to be
connected to any point. Then we can add points all over the
templates.
Right now, you could create a registered plugin-point for the login
widget, and then the person writing the templates could stick it on
any page they want. Or they could stick in their own unregistered
point for it. But this point would be tied to the plugin and the
plugin would be tied to the point.
The style I was thinking of was the WordPress Theme plugin style
(where you can add the 'tags' section to the 'right' or 'left' column
in your them, etc...).
The template writer would come up with all the generic plugin points,
and then any generic plugin could be assigned to any of the generic
points (multiple at the same time).
The bulk of the app-plugin code is in managing the migration/upgrade
issues so that adding or removing an app, or editing templates will
'do the right thing'.
This is the hardest thing to get right. Even WordPress does not get it
right 100% of the time.
I must say I don't entirely understand plugin points, especially their
database component. it seems like it is perhaps trying to do too many
things at once. perhaps some use-cases would be helpful for thinking
about how people would use it.
On Nov 10, 12:25 am, Dougn <doug.napole...@gmail.com> wrote:
> On Oct 16, 12:38 am, Eric Drechsel <ericd...@gmail.com> wrote:
> > django-app-plugins seems interesting. It allows the admin to place app-
> > supplied plugins through the admin? Is it possible for the plugins to
> > be passed context form the containing view? This is a limitation in
> > Drupal's blocks system (most blocks guess context by looking at urls
> > and other globals)
> This is exactly how app-plugins work, you can also pass in explicit
> additional context on the plugin point.
> I haven't had any time to get back to this, but I want to add a new
> type of plugin point and plugin 'generic' (currently there are
> registered and unregistered). This would allow any plugin to be
> connected to any point. Then we can add points all over the
> templates.
> Right now, you could create a registered plugin-point for the login
> widget, and then the person writing the templates could stick it on
> any page they want. Or they could stick in their own unregistered
> point for it. But this point would be tied to the plugin and the
> plugin would be tied to the point.
> The style I was thinking of was the WordPress Theme plugin style
> (where you can add the 'tags' section to the 'right' or 'left' column
> in your them, etc...).
> The template writer would come up with all the generic plugin points,
> and then any generic plugin could be assigned to any of the generic
> points (multiple at the same time).
> The bulk of the app-plugin code is in managing the migration/upgrade
> issues so that adding or removing an app, or editing templates will
> 'do the right thing'.
> This is the hardest thing to get right. Even WordPress does not get it
> right 100% of the time.
On Nov 15, 6:35 am, Eric Drechsel <ericd...@gmail.com> wrote:
> I must say I don't entirely understand plugin points, especially their
> database component. it seems like it is perhaps trying to do too many
> things at once. perhaps some use-cases would be helpful for thinking
> about how people would use it.
It would be more obvious if I could get around to writing the
interface for it.
The best example would be to fire up Pinax and go into the admin and
go to the plugins list.
You can disable the plugins for the profile page and change the
default order with which they appear on the profile page.
You can mark them as 'required' (which right now has no effect but I
will get to...)
You could create User Plugin Preference.
This is where users can override the default plugin settings for a
plugin point. You can change the plugins order and which plugins are
visible on your profile page.
For the profile page this would be changing the order of the items on
that page (say you want your blog posts at the top and your tweets at
the bottom).
You can remove entries (maybe you don't want your tweets on your
public profile page....). Plugins which are marked 'required' can not
be removed by the user preferences.
The Plugin object/model can have plugin preferences hung off of (for
say a plugin which there are administrative configs)
The User Plugin Preferences are an object/model which you can hang
your user preferences for a plugin off of.
My hope is to get back to this and set up some standard views for
creating and modifying the preferences stuff along with some jquery
for the preferences page to make things more obvious.
I was thinking of a modified version of this:
> On Nov 10, 12:25 am, Dougn <doug.napole...@gmail.com> wrote:
> > On Oct 16, 12:38 am, Eric Drechsel <ericd...@gmail.com> wrote:
> > > django-app-plugins seems interesting. It allows the admin to place app-
> > > supplied plugins through the admin? Is it possible for the plugins to
> > > be passed context form the containing view? This is a limitation in
> > > Drupal's blocks system (most blocks guess context by looking at urls
> > > and other globals)
> > This is exactly how app-plugins work, you can also pass in explicit
> > additional context on the plugin point.
> > I haven't had any time to get back to this, but I want to add a new
> > type of plugin point and plugin 'generic' (currently there are
> > registered and unregistered). This would allow any plugin to be
> > connected to any point. Then we can add points all over the
> > templates.
> > Right now, you could create a registered plugin-point for the login
> > widget, and then the person writing the templates could stick it on
> > any page they want. Or they could stick in their own unregistered
> > point for it. But this point would be tied to the plugin and the
> > plugin would be tied to the point.
> > The style I was thinking of was the WordPress Theme plugin style
> > (where you can add the 'tags' section to the 'right' or 'left' column
> > in your them, etc...).
> > The template writer would come up with all the generic plugin points,
> > and then any generic plugin could be assigned to any of the generic
> > points (multiple at the same time).
> > The bulk of the app-plugin code is in managing the migration/upgrade
> > issues so that adding or removing an app, or editing templates will
> > 'do the right thing'.
> > This is the hardest thing to get right. Even WordPress does not get it
> > right 100% of the time.
> On Nov 15, 6:35 am, Eric Drechsel <ericd...@gmail.com> wrote:> I must say I don't entirely understand plugin points, especially their
> > database component. it seems like it is perhaps trying to do too many
> > things at once. perhaps some use-cases would be helpful for thinking
> > about how people would use it.
> It would be more obvious if I could get around to writing the
> interface for it.
> The best example would be to fire up Pinax and go into the admin and
> go to the plugins list.
> You can disable the plugins for the profile page and change the
> default order with which they appear on the profile page.
> You can mark them as 'required' (which right now has no effect but I
> will get to...)
> You could create User Plugin Preference.
> This is where users can override the default plugin settings for a
> plugin point. You can change the plugins order and which plugins are
> visible on your profile page.
> For the profile page this would be changing the order of the items on
> that page (say you want your blog posts at the top and your tweets at
> the bottom).
> You can remove entries (maybe you don't want your tweets on your
> public profile page....). Plugins which are marked 'required' can not
> be removed by the user preferences.
self-replying is bad form, but what the heck.
To drive the point home, I added two Plugin User Preferences on
cloud27 for my account.
I removed my blog posts and made my photos the first item on my
profile (friends are not put on the page via the plugin system):
http://cloud27.com/profiles/dougn/
