David M Johnson wrote:
On Mar 1, 2006, at 3:26 AM, Sean Gilligan wrote:
I'm still trying to learn how the current Roller works before seriously
proposing anything. Further, I think that any serious changes that I
would propose are much more than I'd be able to make as a "Proposal
with
commitment". So the following stuff is just a handful of ideas.
Some of the changes are indirectly
related (like virtual hostnames) but I think they are relevant in
the general context of site/template authoring.
Some broad goals (that could be implemented over time) would include:
A) Support virtual hostnames for weblogs, of either of two forms:
i) yourhost.yourdomain.tld (any arbitrary domain)
ii) yourhost.rollerdomain.tld (similar to how Blogger works
with yourblog.blogspot.com)
I believe Javalobby wants that one too.
B) New URLs for blogs pages with backward compatible support for old
urls.
i) Blog pages could be at http://virtualdomain/path or
http://non-virtualdomain/handle/path rather than
http://domain/servlet-name/handle/path
ii) Permalinks would not use ?entry=pemalink_name, but something
like /YYMM/permlink_name.html
Good stuff. I think everybody agrees that we need better URLs in Roller.
C) Support pluggable view layers in Page views, Feed views, etc. so
view
technologies other than Velocity could be used.
I've never been very excited about supporting different view
technologies because of the support and maintenance implications. So
much of the Roller display logic is in those VelociMacros and that
would have to be duplicated for each view technology.
But I would like to see Roller become more modular and pluggable. For
example, moving app logic out of the Struts actions so that it's
possible to replace the Struts/JSP UI with something else. I guess
"pluggable view layers" is a similar concept; you want to be able to
replace the Velocity based rendering engine with something else.
Dave makes an excellent point here. I completely agree that we do not
want to be in the business of managing multiple templating language
libraries.
I still agree with Sean that I have been somewhat disappointed with what
Velocity supports, but maybe we can try and make positive contributions
to Velocity rather than replacing it.
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.
I don't see how those are easier than Velocity.
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.
Possibly, but those three systems have different object models and
features. Seems highly unlikely that we'd be able to agree on a
common object model, template languages, etc.
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.)
I like the compatible with Blojsom and Pebble idea better than this one.
G) A conversion tool to allow people to convert templates from other
systems.
Definitely a good idea.
OK, now for some concrete, implementation-level things we could do:
1) Convert all VelocityServlet-derived classes to be SpringMVC
controllers. The basic SpringMVC Controller is about as simple and
lightweight as VelocityServlet but allows for easier URL path map
configuration and pluggable view implementations. Using SpringMVC
would have two benefits: i) make supporting alternate URLs for
content easier and ii) open the door to templates that don't use
Velocity.
I've had good experiences with SpringMVC and would be willing to
contribute to this development. I'm not ready to commit to a
schedule yet. There may be alternatives to SpringMVC that are
equivalent/better, but SpringMVC has worked well for me.
I'd like to keep the rendering engine part of Roller simple and with
minimal dependencies, i.e. just Servlets and Velocity. I don't see
why we need to pull in another MVC framework to do that. We already
have a giant learning curve for new developers with all the
frameworks and dependencies we have.
So, I guess I agree with your goals but not with the idea of bringing
in SpringMVC.
I am also in strong agreement with Dave here. I am not in the mood to
start introducing new libraries and frameworks just because they sound
cool. There is nothing actually broken with the way our presentation
layer is setup right now, so I don't see a big reason to change it.
However, I am willing to look into ways that SpringMVC could help with
improving our urls and if I think the SpringMVC solution is compelling
enough then I would be willing to start using it.
-- Allen
- Dave
