On 3/2/06, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > 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.
IMO, using Spring MVC simply for it's URL handling is silly. The URL Rewrite filter can do any URL finagling we need to do. We probably don't take advantage of this library as much as we should. Of course, since it's GPL, we'll likely have to rewrite everything because of it's "viral" license. ;-) Matt > > -- Allen > > > > > - Dave > > > > > > > > > > >
