Dave wrote:
On 3/28/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
More info added to the widgets proposal ...
http://cwiki.apache.org/confluence/display/ROLLER/Proposal+Widgets+and+Panels
In particular I've added a couple sections about what new object and
data model changes we would make as well as a breakdown of 2 different
options we have for rendering.
check it out and lets hear some comments.
I read over the proposal again and the new info looks good.
I think "Option 2: Widgets go through the full rendering system"
sounds overly complex. It's definitely nice for a widget to be able to
specify a special model class to be loaded, but I'm not sure it's
worth that complexity.
I am very much on the fence with this decision, so I would definitely
like to hear more discussion about it. I had actually been leaning a
little more towards option #2, but still hadn't made up my mind.
As far as complexity is concerned, I think the increased complexity is
relative. In option #1 all we are doing is calling #parse() on the
widget control template, which is dead simple, so any other options are
going to seem more complex. The actual code to implement option #2 is
actually very simple and minimal though, it's basically just 1 extra
class which I am calling the WidgetContentManager and that class has 1
primary method getRenderedWidget(weblog, widget). So the added
complexity is not all that much in terms of required code.
Now, in terms of what actually happens at processing time the complexity
is definitely a bit more with option #2 because it will pass through a
fair bit more code for each widget that gets rendered. Unfortunately,
until I build it and test it there is no way to know what kind of effect
that would have on performance or widget rendering time, but my guess is
that it would be negligible.
So when it's all said and done my feeling is that from a coding point of
view both options are easy enough to implement that we can do either.
One thing that I didn't mention in the proposal that *could* be a very
nice benefit of option #2 is that you can do some far more fancy things
with it like ...
1. rendering widgets individually and outside of the normal weblog
rendering, so live previewing options are much better.
2. since widgets are rendered and managed individually we can easily
make them consumable in different ways, such as by providing a widgets
endpoint in weblog urls like /<weblog>/widget/<widget> that would return
the html for a specific widget. that would enable our blog designers
the possibility of doing ajax style inclusion of widgets if they wanted
to. **NOTE: this assumes that widgets are not contextual elements,
meaning that they don't rely on knowing what view they are being
rendered for.
3. widget caching. we can cache a widget so that if it's included in
100's of pages then we don't need to render it 100's of times.
4. custom models for widgets, which allow much more flexibility in what
widgets will be able to accomplish.
Anyways, at this point I am mainly trying to determine what the cons are
to each approach and see which one has more of the cons which we don't
really want to live with. Right now my thinking is that while option #1
is easier and less complex it's quite a bit less flexible, and although
option #2 takes a bit more effort to develop up front, once it's working
it will provide us a lot more options for the cost a speculatively
meager performance hit. It's a tough call though.
-- Allen
- Dave
