Allen Gilliland wrote:
yes, there is a jira issue called "better urls" which will definitely be happen
in the not too distant future assuming nothing comes up. i am in full agreement that we
need to support a much better url structure, but how we implement that is still up in the
air right now.
i am hoping to get the ball rolling on this pretty soon (next week or two) and
ideally implement it for what i would guess to be the Roller 3.0 timeframe (2-3
months away). i am more than happy to work with you make make sure we can do
as much of this as possible. the virtual domains is not something we will use
for blogs.sun.com, but if we can engineer things correctly we should be able to
allow for pluggable url structures and vanity url mapping schemes.
Cool!
C) Support pluggable view layers in Page views, Feed views, etc. so view
technologies other than Velocity could be used.
this is technically possible now,
I looked at the code last night and the only way I see to do it is to do
some major Java coding. My guess is ballpark a person week. I don't
think that's what you mean by technically possible. I think I'm missing
something...
but it's not as if it's a 5 minute change.
I say 5+ person days.
it also requires code changes, so maybe that's what you are trying to avoid?
No, I'm not trying to avoid it. I'm just trying to build up courage and
support ;)
you want a way to allow the Roller admin to choose their own view
technology? that may be more trouble than it's worth.
I'm not sure how/when the view technology would be selected. Options are:
1) At build time.
2) At install/configure time.
3) Add a "template type" to the template table and use the right view
technology at run time.
The first step, I think, would be to replace VelocityServlet with
SpringMVC Controllers and have everything work exactly as before. The
next step would be to try to wire things up at build or configure time
to work with Freemarker or an alternate view technology.
There was a discussion on the list a few months ago about modularizing
Roller and creating a "Blog Components" or "Blog Tools" ASF project.
Modularizing the view technology could be a step in that direction. It
would allow experimentation or deployment with alternate template types,
but using the Roller persistence layer, UI, etc.
D) I'd love to see a template language like that from Blogger or Movable
Type.
http://help.blogger.com/bin/answer.py?answer=753&topic=39
http://www.sixapart.com/movabletype/docs/3.2/a_template_tag_reference/
I'm a Velocity hacker myself, but I want users to be able to easily
modify/write templates themselves.
yep. velocity can't do that i don't think, so that means changing to something
else. also note that you are flirting with *huge* backwards compatability
problems here.
Flirting, but definitely not ready to date, let alone marry ;)
it would be very hard for an existing site to make a change like that.
The template type option (#3) above would allow migration of existing
sites, if people wanted to go that route.
E) Create a blog template "View" component that could be re-used by
other Java-based blogs (such as Blojsom or Pebble) -- it could help
create critical mass for a larger library of templates.
F) A template language compatible with Blogger or MovableType.
(Wordpress is popular and has a huge template library but IIRC it uses
php in its templates.)
G) A conversion tool to allow people to convert templates from other
systems.
E, F, and G would be nice, but i wouldn't put too much faith in it. the
problem is that most people aren't bouncing around between blog software, they
choose one and stick with it.
Sure most people choose one and stick with it, but template authors
often port themes from one blog to another. For example, the Kubrick
theme is available for Blojsom, Wordpress, etc... Blojsom has done a
good job of getting lots of themes ported. If the same themes could be
used for Blojsom and Roller, that alone would be a big help.
I am not a Spring guru, but so far my initial thoughts have been that
there isn't a whole lot of new value in switching to Spring.
I'm a Spring initiate, but not a Guru. The nice thing about Spring is
it tries really hard not to be an "all or nothing" conversion. I've
mixed in SpringMVC with existing projects to add better URL support and
it is fairly straightforward and non-invasive.
For the page, rss, flavor, etc. servlets I would look at using
AbstractController as the base class. It is the most scaled down base
class in SpringMVC and is a close mapping to VelocityServlet. One
issue would be converting all instances of VelocityContext to a simple
Map, which is what SpringMVC uses for the model. There's not a huge
value here, but Spring is Apache-licensed, well documented, etc. and
there's no need to re-invent the wheel. Plus the .jar is already in the
project for Acegi.
However, if you think the urls stuff can be done very easily using SpringMVC
then my ears are open.
Spring uses something called a "HandlerMapping" to map from URLs to
controllers. The SimpleUrlHandlerMapping uses ant-style path
expressions and is fairly flexible. If that isn't flexible enough, we
could write our own. HandlerMappings are IOC-pluggable so that would
make the URL mapping quite configurable at build/deploy time.
To truly convince me of this I would want to see a simply webapp example
using Spring which can support the vanity urls that we have discussed.
More precisely it needs to at least support /<weblog>* vanity url
mapping.
I would be very happy to work a little with you offline to get this
test app
setup so that I have some indication about how this would work
using Spring. You could try doing this as a patch to Roller,
but I suggest just creating a new app with just the url mapping so
that I can take a look at it.
I'm game for this at some point in the next couple weeks. One way of
demonstrating this would be to add the Spring Dispatcher servlet to
Roller's web.xml and wire up a HandlerMapping and Controllers to
implement the old and new URL structure using servlet forwarding.
I could also provide you with some examples of similar things I have
done with SpringMVC offline.
2) Document and possibly change/simplify what objects are in the
VelocityContext/SpringMVC model. Document URLs and what templates must
do to properly support those URLs.
Yep. I figure that will just snowball from any cleanup we do to the templating
process as a whole.
Yes, it has to be a "holistic" approach in order to simplify/cleanup.
Which is hard for me, since I'm a Roller beginner. I do bring naivety
and a fresh perspective though ;)
3) Unroll #includes and macros in templates so more of the HTML is
visible in the templates to authors. This complicates maintenance of
the built-in templates, but perhaps a build time process could be used
to minimize duplicate code in templates. (Duplicate code is bad for
Roller maintenance, but good for template authors)
Yep. I still don't know what you mean when you suggest
things happen at build time. Can you give a detailed example of what
you are talking about?
I'm just brainstorming here, but the rough idea is to use macros for
things like #showCategoryList() and "unroll" the macros at build time.
let's say we want to provide 10 built-in themes. There could be an ant
task in the build that unrolls the #showCategoryList() into something
like this:
<RollerCategories>
<a href="<$RollerCategoryURL$>" class="catlink">
<$RollerCategoryTitle$>
</a>
</RollerCategories>
The "unrolling" would happen as the templates are copied into
build/roller/WEB-INF/classes (or wherever it is that they go.)
Once deployed, A template author can now click "customize" and change
the class attribute right there rather than having to look up and
override the Macro. But maintaining the built-in templates is
simplified by the macros. If the built-in templates are in velocity
than the build-time macro processor might have to use another
language/technology. It's just a half-baked idea on my part to make
life easy for Roller maintainers *and* template authors. Does this
explanation make sense?
4) Experiment with FreeMarker as a Velocity alternative. Freemarker
5) Define a blog tag language (in FreeMarker?) for Roller (or make it
4 and 5 sound cool to me, but once again it's the same problem of backwards
compatability. i have no idea how a reasonable sized site would manage to
convert all of its existing template content into a new template language.
that would be a very hard thing to do.
Agreed.
Regards,
Sean
