Dave Johnson wrote:
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.
sounds good.
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.
yep, i think that's a good way to do it.
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.
i know :(
one thought i had here was to *force* the use of the site.absoluteurl
runtime property. basically, if that property isn't set then your urls
will just be relative. i know that MT actually does this and i expect
other blog software does as well. i don't think it's too much to ask
for people to put in their absolute url.
the other alternative is for us to still *force* the use of the
site.absoluteurl, but if at any point it is unset then we try and
determine a logical value for it and set it ourselves.
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.
I think I am still unconvinced that these interfaces are really needed,
but if you want them to be there then that's fine.
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.
This one I am going to disagree with pretty strongly. I hate inner
classes because they are hard to find. If we are going to use these
interfaces can you please pull them out of the WeblogEntry interface and
put them in classes of their own.
I would also like to consider some renaming for these interfaces.
1. Author instead of User. That seems more descriptive to me. We are
talking about someone who authored content, not a system user.
2. Author.getName() instead of User.getUserName(). User name doesn't
actually describe the author in all cases. A planet entry may have an
entry authored by "Allen Gilliland" and that's not a username.
3. Weblog instead of Website. I think we should be moving away from
using the term website, these things are weblogs.
4. WeblogEntry.getPermalink() instead of WeblogEntry.getPermaLink(). I
think this conflicts with the way the current WeblogEntryData returns a
PermaLink, which is actually a relative url. I think it's better if we
start using the new getPermalink() method and ensure that it returns a
full permalink at all times. This means we need to add this method to
WeblogEntryData and make sure it returns a full permalink, which is
something we want anyways right?
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.
Maybe the better thing to do is use subclassing instead of interfaces.
Something like this ...
Define these 4 objects as you did with the interfaces, but make them
abstract.
Weblog
WeblogEntry
WeblogAuthor
WeblogCategory
Have our Roller and Planet specific classes extend those classes. this
makes more sense to me because the relationship between a WeblogEntry
and roller WeblogEntryData seems more like a subclass relationship where
the WeblogEntryData is building on the functionality of it's parent class.
This way we can also use the benefits of inheritance, which interfaces
do not provide.
-- Allen
I don't see how they complicate anything. They simply document and
enforce a simple and minimal common interface to entries.
- Dave
