David M Johnson wrote:
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.
There is a lot in those Velocimacros and it would be non-trivial to
replace it. The (core) Roller project wouldn't/shouldn't switch or
support more than one without serious deliberation. However, I believe
there are at least three benefits from going to "pluggable views":
1) Enable 3rd-parties to customize Roller with alternate views
2) Improved separation of concerns in the source code, making learning
and maintenance easier
3) When/if the time comes to make a significant change it is
a lot less painful
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.
Yep.
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.
They're not any easier for you or me, but I believe for the average web
designer or blogger who wants to customize their templates, that these
are easier. Of course, if we implement multiple views/template engines,
we can let the users decide...
I've been working with Velocity for almost 6 years, switching from
Webmacro as soon as Velocity came out. In fact, I've never done any
real work (in Java) with any other view technology. I like Velocity.
It works quite well for HTML designers who don't really "touch" the
Velocity code , but just modify the HTML, CSS, and images around it.
However, I recently asked a web designer (who has worked with velocity
pages before) to implement something that she had previously done in
Movable Type using Roller/Velocity and she was very discouraged. Part
of the problem is documentation, of course, but to do serious work in
Velocity you really need to understand the Java objects underneath. The
User Guide has links to the JavaDoc. The work I did this week had me
reading through the Java source in Eclipse (I may have some patches for
some velocimacros to submit shortly...)
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.
I don't know if explicit agreement would be required, one project might
just start borrowing components and templates from the other. At a
basic level all blogs have the same object model: blogs, categories,
entries, etc. I have no idea what would come out of all this, I just
want to enable possibilities. I know (but can't remember what) there
has been some borrowing of code between Roller and Blojsom. (I played
around with Blojsom quite a bit before deciding to move ahead with
Roller -- a big strength of Blojsom, in my opinion, is that it has a
nicer looking library of templates out of the box.)
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.
My internal engineer agrees with you. My internal marketing person
thinks the Blogger and MT compatibility or migration tool would be a
good thing. These blogs have books for sale in bookstores and on Amazon
about how to write/modify templates. That's a big deal.
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.
I understand your point. I'm put off from working on the admin UI for
Roller by the learning curve for Struts/JSP. (However, this UI was one
of the big deciding factors, for me, over Blojsom.)
The way I visualize using SpringMVC is not the typical "pull in another
framework" kind of approach. Spring, in general, is a very modular and
it really lets you pull in various pieces without having to adopt "the
whole enchilada". This is also true for SpringMVC: you can use a small
subset of classes and interfaces and ignore all the subclasses. I
visualize using a very small number of classes to do this. It could
even reduce the learning curve for new developers versus the current
implementation.
So, I guess I agree with your goals but not with the idea of bringing in
SpringMVC.
If it's ok with you (and the list) I'd like to keep trying to convince
you of why this would be a benefit for Roller. (I'll send a separate
message going in to more detail.) I'm also thinking about putting
together a prototype to show Allen how the URLs would work. I've used
SpringMVC in a very similar application and it worked really well (and
we also converted from a just just-Servlets-and-Velocity implementation.)
Another alternative is we could just "borrow" a few of the core
classes/patterns/concepts from SpringMVC and "roll our own". That could
be a good solution if there is a strong objection to the "framework"
aspect of SpringMVC.
-- Sean
