On 6/5/06, Allen Gilliland <[EMAIL PROTECTED]> wrote:
1. I noticed you setup the PermissionsData pojo to make it available in
the velocity context, but I am wondering if we can try and avoid that.
That object doesn't actually contain any information that should be used
at rendering time and I think it would be best to not make it available
in the rendering context. Why is this needed? It appears that the
methods that return the wrapped PermissionsData are supposed to return
either Users or Weblogs.
Yes, it would be better to simply return Weblogs or Users. I'll fix
that. I've also got some concerns of my own about the return types for
some of the methods -- I'm working on a write up for that too.
2. Can rename the default PageModel to WeblogPageModel since that is
more descriptive.
Yes. And I'd like to introduce an interface with the name PageModel:
interface PageModel {
public String getModelName();
}
Where the handle will be the model's name within the Velocity context.
3. I noticed that you altered that absoulte site url handling a bit and
i think that's a good thing, but I want to make sure we are doing it
carefully. I saw that you were removing the old way of
$absBaseURL$entry.permaLink and changing that to just $entry.permaLink,
but that would cause problems for existing blogs right? Existing blogs
are probably counting on $absBaseURL being valid, so we can't remove
that field, and we also can't change the behavior of $entry.permaLink
since that would also break links. We may need to simply add a new
method like $entry.permalink (notice the lower case l) to keep them
separate.
Yuck but you are right.
4. I see some new interfaces which are inner classes of the WeblogEntry
interface. We've talked about the WeblogEntry interface before and I am
still not convinced this is necessary design decision. However, I feel
even more strongly about the other interfaces that you added on top of
that. What is the need for those interfaces and why are they inner
classes of the WeblogEntry interface? I don't see the need for any of
these interfaces and to me they only seem to be complicating things.
Those additional interfaces are required to form a complete common
entry model. If the WeblogEntry interface is going to be used by both
blog entries and planet entry POJOs, and those POJOs are in differernt
modules of modular Roller, then we can't refer to concrete types in
the interface.
The added interfaces are exceedingly simple and small and strongly
tied ot the WeblogEntry interface, so I added them as inner classes of
the WeblogEntry interface.
And I changed the proposal to better explain the need for these
interfaces, heres what it says now:
Currently, we model entries in Roller in two different classes:
* WeblogEntryData - Roller stores entries using POJOs of this class
* PlanetEntryData - Roller's planet aggregator stores entries using
POJOs of this class
This is confusing to template authors and prevents code re-use, as
code written for weblog entries won't work for planet entries. Using a
uniform interface for both types of entries will make it easier to
write Velocity code that displays entries and possible to re-use code.
We could simply modify the methods of the two entry representations to
match, but the better approach is to create a common WeblogEntry
interface and have both WeblogEntryData and PlanetEntryData implement
that interface. This has these benefits:
* The template author documentation (yes, I'm writing docs) for the
new frontpage models and macros will document only the properties
exposed in those interfaces.
* When an template author is trying to write code to work with both
types of entries (as I have already done in the frontpage macros), he
is guaranteed that the two entry implement the WeblogEntry interface.
* When a Roller developer is adding new properties to the
WeblogEntryData and PlanetEntryData classes, he'll know specifically
which methods are promised to work in templates. So it's much less
likely that he'll break template code.
I don't see how they complicate anything. They simply document and
enforce a simple and minimal common interface to entries.
- Dave
