Page History

...

• define what is meant by a widget and how it would be defined in Roller.
• define how widgets would be configured and grouped for use in blog templates and themes.
• discuss how widgets would be controlled via the Roller UI.
• define a way for Roller administrators to view the list of configured widgets, import new widgets, remove old widgets, and enable/disable widgets.

Design (Overview)

What is a widget?

A widget is a reusable component of content that can be inserted into any blog template, typically on the blog sidebar.

...

Also, before spending too much time drawing up a UI I'd like to get general approval from the community with regards to the functional aspects of the proposal. It would be wasted time to design a nice UI only to have it discarded because we decided to use a different approach to the problem. Once we are committed to this general approach then we would spend more time flushing out the UI design and discussing that specifically. The main point is that users would have a wysiwyg style UI for choosing widgets and organizing them in panels which would alleviate the need for direct template editing.

Design (Rendering)

what actually happens to render a widget and insert it into a template?

Option 1: Just #parse() the widget control template during normal page rendering

In this approach, widgets are rendered as part of the overall rendering process for a page, so widgets are just templates that get parsed and included. i.e. a call to #showWidget("foo") triggers a call to #parse("widget:foo") and relies on a WidgetResourceLoader to provide an input stream to the appropriate widget control template.

Pros:

• simplest approach and least resource intensive.

Cons:

• less opportunity for caching since the logic is inside of a macro call, tied to normal page rendering, and mostly handled by velocity.
• we don't have much control over widget rendering. widgets would have to work with whatever is available in the normal model for page rendering, and wouldn't have an opportunity to be given special rendering attention. so in this situation widgets basically just become a glorified way to make macro calls.

Option 2: Widgets go through the full rendering system

With this scenario widgets go through the full rendering process and the output simply gets pasted into the template. so calling #showWidget("foo") calls a Model method like $model.widget("foo") that instigates the typical rendering process and inserts the returned output. The $model.widget("foo") call may trigger something like this ...

WidgetManager.renderWidget(widgetName, Weblog weblog)
    - caching lookup (optional)
    - lookup control Template for rendering specified widget
    - calls renderer manager to find renderer for widget template
    - render output
    - caching storage (optional)
    - return output

Pros:

• Caching can be done easily by the WidgetManager so that widgets aren't re-rendered for every page.
• We can control Models for widgets, optionally doing something fancy here like allowing special Model classes for certain widgets. we also wouldn't have to load the model with all the same data available for normal page rendering, which can be a lot of unnecessary data when pre-3.0 model loading is enabled.

Cons:

• some level of performance hit during rendering since you add in the overhead of going back through the rendering system, possibly multiple times. this could likely be negated by providing some decent caching for widgets, so that once a widget is rendered it can be reused multiple times without needing to be re-rendered.

Issues

• how to access widget resources? Roller takes the approach that all components used by a weblog should be accessed via that weblogs urls, but this creates some issues for resources that are meant to be shared across weblogs.
  • option 1, use the existing resource servlet the same way we do for theme resources.
  • option 2, pick a url location outside of the weblog url space (/roller-ui/) to use for accessing widget resources, such as /roller-ui/widgets/<widget>/