On Wed, 2006-03-01 at 00:26, Sean Gilligan wrote: > Allen Gilliland wrote: > > In > >> my opinion the difficulty of template customization is one of the > >> biggest weaknesses of Roller as compared to other blogging software I've > >> worked with (Movable Type and Blogger) So, this is an area where I'd > >> like to help. > > > > This I am in absolute agreement with and I would be more than happy to > > try and work out some ways to improve our templating situation. This is > > something that I have marked on my future TODO list, but there are quite > > a few other things to do first. > > > > I would definitely be interested in what you had in mind though. > > You asked for it... > > 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.
it's all good, ideas are the fun part of the process anyways ;) > > 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) > > 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 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. > > 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, but it's not as if it's a 5 minute change. it also requires code changes, so maybe that's what you are trying to avoid? you want a way to allow the Roller admin to choose their own view technology? that may be more trouble than it's worth. > > 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. it would be very hard for an existing site to make a change like that. > > 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. > > 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 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. However, if you think the urls stuff can be done very easily using SpringMVC then my ears are open. 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. > > 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. > > 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? > > 4) Experiment with FreeMarker as a Velocity alternative. Freemarker > supports nested, tag-based macros: > http://freemarker.sourceforge.net/docs/dgui_misc_userdefdir.html > I have not used FreeMarker, but it seems to have a good reputation and > is supported by SpringMVC. There is also a Velocity to FreeMarker > template conversion tool. > > 5) Define a blog tag language (in FreeMarker?) for Roller (or make it > more generic so other blogs could use it?) Can this map directly to > FreeMarker tags/directives? Could it be compiled to Velocity macros and > variables? > > So you could potentially have something like this: > <@entries category="Music"> > ${entry.title}<br/> > ${entry.text} > </@entries> > > A pre-processor could easily convert to the above from: > <RollerEntries category="Music> > <$RollerEntryTitle$><br/> > <$RollerEntryText$> > </RollerEntries> > > or perhaps it could map directly to velocity/velocimacros? > > I don't know if this would work, but it might be a way to create a > tag-based template language without having to write one from scratch. > 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. > These are just ideas, and potentially a great deal of work, but I'm > willing to contribute to #2 and might commit to #1 at some point in the > near future. cool. then lets focus on the better urls for now. -- Allen > > -- Sean
