You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Sean Gilligan <se...@msgilligan.com> on 2006/02/28 21:59:09 UTC
Changing default page in Roller 2.1?
I've noticed an issue (don't know whether to call it a change, bug, or
documentation discrepancy) in Roller 2.1.
It seems you can no longer change the default "page" for your site from
Weblog.vm. It looks like this happened as part of the
"StandardizedTemplates" change:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedTemplates
This seems a step backwards in functionality because you can't have a
home page on your "website" that is not a Weblog page. It also requires
you to cut and paste between templates to make a "whole file" change
to your homepage.
Regards,
Sean
Documentation references:
Section 4.1 (Weblog Settings):
Lists the "Page to be used as the homepage" setting (I put a ? here when
I submitted some edits recently)
Section 5.1 (Weblog and day templates) of the manual says:
"Your weblog page is the main page of your web site, the one that is
specified as the default page in your Preferences:Settings page."
Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
Allen Gilliland wrote:
>>
> My personal opinion is that this was a case of a double edged blade. I
> knew that the change for standardized templates was going to make things
> more difficult in the case you mentioned in this thread, but I felt that
> the benefits outweighed the costs in the long run.
If you are willing to explain the issues with changing the default page
to me in more detail, I'm willing to try to come up with solutions.
From your proposal, I'm assuming the issue is that having the home page
be other than "Weblog" complicates caching because it is no longer
possible to assume that page/handle and page/handle/Weblog are the same?
-- Sean
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
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
Re: Vanity/Improved URLS (was Re: Templating ideas (was Re: Changing
default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
On Fri, 2006-03-03 at 14:26, Sean Gilligan wrote:
> Allen Gilliland wrote:
> > I was always just talking about using vanity urls for incoming requests, not for url rewriting of outputed html. I don't have any real desire for rewriting urls on their way out.
>
> IMO, the new, improved, vanity, etc. URLs should be the native URLs for
> the various pages/resources on the system, so no rewriting would be
> required. Having the native URLs of the system be simple and consistent
> (i.e. not different after a redirect or following a link) is important
> for search engine ranking, bookmarking, feed urls, etc.
yep.
>
> It would be preferable not to rewrite the URLs on the way out. Ideally,
> they would be the vanity/improved URLs from the start.
yep.
>
> Additionally the URL arrangement should be as configurable as possible
> with the default being backwards-compatible with the current solution.
> There should also be support for existing blogs that want to migrate to
> a new scheme (redirects and/or forwards.)
yep.
i think i probably used the term "vanity urls" inappropriately. i agree that we want this to be *the* url scheme.
-- Allen
>
> -- Sean
>
Vanity/Improved URLS (was Re: Templating ideas (was Re: Changing
default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
Allen Gilliland wrote:
> I was always just talking about using vanity urls for incoming requests, not for url rewriting of outputed html. I don't have any real desire for rewriting urls on their way out.
IMO, the new, improved, vanity, etc. URLs should be the native URLs for
the various pages/resources on the system, so no rewriting would be
required. Having the native URLs of the system be simple and consistent
(i.e. not different after a redirect or following a link) is important
for search engine ranking, bookmarking, feed urls, etc.
It would be preferable not to rewrite the URLs on the way out. Ideally,
they would be the vanity/improved URLs from the start.
Additionally the URL arrangement should be as configurable as possible
with the default being backwards-compatible with the current solution.
There should also be support for existing blogs that want to migrate to
a new scheme (redirects and/or forwards.)
-- Sean
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
I was always just talking about using vanity urls for incoming requests, not for url rewriting of outputed html. I don't have any real desire for rewriting urls on their way out.
However, conceptually speaking I would think you could overcome your "response already committed" problem by overloading the HttpServletResponse object and providing a buffered implementation instead. That way all the rendering that goes on via servlets, jsps, etc is just being written to a buffer and not actually flushed to the client. This would give you the opportunity to inspect the buffer after everyone else is done with it and then do your url rewriting before sending anything back to the client.
-- Allen
On Fri, 2006-03-03 at 05:18, John Hoffmann wrote:
> I had tried to implement HTML rewriting in a servlet filter to alter its
> URL's about 2 years ago. The exercise was foiled by error messages
> stating that the response had already been commited to the browser. So
> somewhere in the code, something had triggered a flush of the buffer. I
> have since run into the same problem in other apps, so in my experience,
> an outbound filter is almost impossible to use unless you have written
> the entire codebase from hand.
>
> -John
>
> Sean Gilligan wrote:
>
> > Matt Raible wrote:
> >
> >> 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. ;-)
> >
> >
> > Has anyone done anything significant with this filter and Roller? Is
> > there a demo/documentation of the results?
> >
> > I suppose the Rewrite filter would need to filter the outgoing pages
> > to rewrite any links in the HTML to the new URLs, right?
> >
> > -- Sean
>
>
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by John Hoffmann <jo...@sun.com>.
I had tried to implement HTML rewriting in a servlet filter to alter its
URL's about 2 years ago. The exercise was foiled by error messages
stating that the response had already been commited to the browser. So
somewhere in the code, something had triggered a flush of the buffer. I
have since run into the same problem in other apps, so in my experience,
an outbound filter is almost impossible to use unless you have written
the entire codebase from hand.
-John
Sean Gilligan wrote:
> Matt Raible wrote:
>
>> 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. ;-)
>
>
> Has anyone done anything significant with this filter and Roller? Is
> there a demo/documentation of the results?
>
> I suppose the Rewrite filter would need to filter the outgoing pages
> to rewrite any links in the HTML to the new URLs, right?
>
> -- Sean
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
Matt Raible wrote:
> 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. ;-)
Has anyone done anything significant with this filter and Roller? Is
there a demo/documentation of the results?
I suppose the Rewrite filter would need to filter the outgoing pages to
rewrite any links in the HTML to the new URLs, right?
-- Sean
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Matt Raible <mr...@gmail.com>.
On 3/2/06, Allen Gilliland <Al...@sun.com> 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
> >
> >
> >
> >
> >
>
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
Allen Gilliland wrote:
>
> 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 agree, too. As I said in my response to Dave, I think that having the
architectural capability to plug in other templating mechanisms is
different from supporting multiple templating mechanisms.
>
> 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.
I'll provide more detail in a separate post. I'll make sure it sounds
more practical than cool ;) The stuff I'm talking about is really
pretty simple. The cool stuff these days is JSF and Tapestry (and of
course, AJAX)...
> 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.
I spent some time this week looking at the code and I don't think it is
broken in any way. But I do think it can be improved.
>
> 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.
I agree with Matt that using SpringMVC just for it's URL handling would
be a little silly. I think the view independence is the big win and the
URL-handling is the bonus. So, if Allen is willing to look/listen at
the URL handling, I'll take him up on the offer. (Anyone whose last
name matches /Gilli*an*/ can't be all bad...)
-- Sean
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
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
>
>
>
>
>
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by David M Johnson <Da...@Sun.COM>.
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.
> 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.
- Dave
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
>> 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.
>> 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.
Just to be clear: I think prototyping this before jumping in is a great
idea. I need less convincing than you that SpringMVC can handle this,
but I haven't done exactly what we need to do here before.
-- Sean
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
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
Re: Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
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
Templating ideas (was Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
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.
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
C) Support pluggable view layers in Page views, Feed views, etc. so view
technologies other than Velocity could be used.
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.
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.
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.
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.
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)
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.
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.
-- Sean
Re: Changing default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
On Tue, 2006-02-28 at 16:37, Sean Gilligan wrote:
> > there is no need to [update the proposal]. the proposal is old and is only meant as a
> > description of work to be done. now that the work is complete if would
> > be tiresome to keep the proposals up to date.
>
> I understand. Personally, I find the old proposals helpful in
> understanding the details of particular features and why they were
> implemented. If I find or get useful information from a list, I figure
> I should share it with others in the Wiki. A small contribution to
> documentation, I suppose. Not a big deal.
>
Absolutely. The better documentation we have the better, and we
definitely appreciate that you are willing to help with this.
> >
> > The ability to change your default
> > template was removed on purpose.
> >
> >> Would it be possible and/or desirable to re-enable the ability to change
> >> the default without renaming/deleting the required "Weblog" template?
> >
> > pretty unlikely, but you can try if you like. like i said, there were
> > technical reasons for making this change which affected the caching
> > system, the way urls were handled, the theme system, etc.
>
> I started to look at the form and objects code to see if this feature
> could be re-enabled and submitted as a patch to the project. However,
> in this case it sounds like the removal of that feature is a closed
> issue. I'd only be interested in doing that work if it could be included
> in Roller itself. In any event, I wouldn't want to break caching or url
> handling...
My personal opinion is that this was a case of a double edged blade. I
knew that the change for standardized templates was going to make things
more difficult in the case you mentioned in this thread, but I felt that
the benefits outweighed the costs in the long run.
>
> i'm sorry
> > that it has caused you a little extra work.
>
> I don't really mind the extra work (of copy/pasting templates) if it was
> just for me, but I'm looking to Roller as a solution for other users,
> too. I am willing within my ability and available time to contribute
> improvements and thought this might be an area where I could help. 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.
-- Allen
>
> Regards,
>
> Sean
Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
> there is no need to [update the proposal]. the proposal is old and is only meant as a
> description of work to be done. now that the work is complete if would
> be tiresome to keep the proposals up to date.
I understand. Personally, I find the old proposals helpful in
understanding the details of particular features and why they were
implemented. If I find or get useful information from a list, I figure
I should share it with others in the Wiki. A small contribution to
documentation, I suppose. Not a big deal.
>
> The ability to change your default
> template was removed on purpose.
>
>> Would it be possible and/or desirable to re-enable the ability to change
>> the default without renaming/deleting the required "Weblog" template?
>
> pretty unlikely, but you can try if you like. like i said, there were
> technical reasons for making this change which affected the caching
> system, the way urls were handled, the theme system, etc.
I started to look at the form and objects code to see if this feature
could be re-enabled and submitted as a patch to the project. However,
in this case it sounds like the removal of that feature is a closed
issue. I'd only be interested in doing that work if it could be included
in Roller itself. In any event, I wouldn't want to break caching or url
handling...
i'm sorry
> that it has caused you a little extra work.
I don't really mind the extra work (of copy/pasting templates) if it was
just for me, but I'm looking to Roller as a solution for other users,
too. I am willing within my ability and available time to contribute
improvements and thought this might be an area where I could help. 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.
Regards,
Sean
Re: Changing default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
On Tue, 2006-02-28 at 15:23, Sean Gilligan wrote:
> I just re-read the proposal and I don't see an explanation of how
> changing the default template makes things harder. If I had a better
> understanding of Roller internals, I might get it, but from the proposal
> alone, I don't understand.
The second paragraph under Abstact lists the reason for the change. The
truth is that based on my knowledge of the Roller internals I felt this
change was a necessary change technically.
>
> If you provide details, I'll update the proposal to include them.
there is no need to do that. the proposal is old and is only meant as a
description of work to be done. now that the work is complete if would
be tiresome to keep the proposals up to date.
>
> Just to be clear: I'm talking about setting the default page to use a
> different template, without allowing deletion or renaming of the Weblog
> template. (I believe this would be implemented as the ability to write
> the "defaultpageid" field of the "website" table)
I know exactly what you are talking about, especially because it was my
proposal and I completed the work. The ability to change your default
template was removed on purpose.
>
> Would it be possible and/or desirable to re-enable the ability to change
> the default without renaming/deleting the required "Weblog" template?
pretty unlikely, but you can try if you like. like i said, there were
technical reasons for making this change which affected the caching
system, the way urls were handled, the theme system, etc. i'm sorry
that it has caused you a little extra work.
-- Allen
>
> -- Sean
>
>
> Allen Gilliland wrote:
> > I will concede that the old way was slightly easier from a UE point of
> > view, but the point was to gain some leverage technically. We haven't
> > lost any real functionality and the fact is that most people still just
> > want their blog homepage to work the way it works by default, so you
> > represent the exception, not the rule.
> >
> >>From a technical point of view, allowing users to change their default
> > weblog template was making things harder on us in various ways. The
> > details are in the proposal that you mentioned.
> >
> > -- Allen
> >
> >
> > On Tue, 2006-02-28 at 14:08, Sean Gilligan wrote:
> >> That's what I ended up doing, but it seems to me to be less friendly
> >> than the way it worked before. For two reasons:
> >>
> >> 1) I can't easily change the default template with a pop-up (I have to
> >> edit one template, select all text, copy, edit another, paste, save)
> >>
> >> 2) It's nice to keep the default template unmodified for comparison
> >> purposes or to switch back if I break something.
> >>
> >> I understand the benefit of clearly marking (and enforcing the presence
> >> of) the required templates, but is there any harm in allowing the
> >> default to be changed?
> >>
> >> -- Sean
> >>
> >>
> >> Allen Gilliland wrote:
> >>> You can still have a custom homepage, the only requirement is that you
> >>> use the template named "Weblog" to represent the homepage for your
> >>> blog. So login, edit template "Weblog", and do whatever you want with
> >>> it.
> >>>
> >>> -- Allen
> >>>
> >>>
> >>> On Tue, 2006-02-28 at 12:59, Sean Gilligan wrote:
> >>>> I've noticed an issue (don't know whether to call it a change, bug, or
> >>>> documentation discrepancy) in Roller 2.1.
> >>>>
> >>>> It seems you can no longer change the default "page" for your site from
> >>>> Weblog.vm. It looks like this happened as part of the
> >>>> "StandardizedTemplates" change:
> >>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedTemplates
> >>>>
> >>>> This seems a step backwards in functionality because you can't have a
> >>>> home page on your "website" that is not a Weblog page. It also requires
> >>>> you to cut and paste between templates to make a "whole file" change
> >>>> to your homepage.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Sean
> >>>>
> >>>>
> >>>> Documentation references:
> >>>>
> >>>> Section 4.1 (Weblog Settings):
> >>>> Lists the "Page to be used as the homepage" setting (I put a ? here when
> >>>> I submitted some edits recently)
> >>>>
> >>>> Section 5.1 (Weblog and day templates) of the manual says:
> >>>> "Your weblog page is the main page of your web site, the one that is
> >>>> specified as the default page in your Preferences:Settings page."
> >>>>
> >>>
> >>>
> >
> >
> >
>
Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
I just re-read the proposal and I don't see an explanation of how
changing the default template makes things harder. If I had a better
understanding of Roller internals, I might get it, but from the proposal
alone, I don't understand.
If you provide details, I'll update the proposal to include them.
Just to be clear: I'm talking about setting the default page to use a
different template, without allowing deletion or renaming of the Weblog
template. (I believe this would be implemented as the ability to write
the "defaultpageid" field of the "website" table)
Would it be possible and/or desirable to re-enable the ability to change
the default without renaming/deleting the required "Weblog" template?
-- Sean
Allen Gilliland wrote:
> I will concede that the old way was slightly easier from a UE point of
> view, but the point was to gain some leverage technically. We haven't
> lost any real functionality and the fact is that most people still just
> want their blog homepage to work the way it works by default, so you
> represent the exception, not the rule.
>
>>>From a technical point of view, allowing users to change their default
> weblog template was making things harder on us in various ways. The
> details are in the proposal that you mentioned.
>
> -- Allen
>
>
> On Tue, 2006-02-28 at 14:08, Sean Gilligan wrote:
>> That's what I ended up doing, but it seems to me to be less friendly
>> than the way it worked before. For two reasons:
>>
>> 1) I can't easily change the default template with a pop-up (I have to
>> edit one template, select all text, copy, edit another, paste, save)
>>
>> 2) It's nice to keep the default template unmodified for comparison
>> purposes or to switch back if I break something.
>>
>> I understand the benefit of clearly marking (and enforcing the presence
>> of) the required templates, but is there any harm in allowing the
>> default to be changed?
>>
>> -- Sean
>>
>>
>> Allen Gilliland wrote:
>>> You can still have a custom homepage, the only requirement is that you
>>> use the template named "Weblog" to represent the homepage for your
>>> blog. So login, edit template "Weblog", and do whatever you want with
>>> it.
>>>
>>> -- Allen
>>>
>>>
>>> On Tue, 2006-02-28 at 12:59, Sean Gilligan wrote:
>>>> I've noticed an issue (don't know whether to call it a change, bug, or
>>>> documentation discrepancy) in Roller 2.1.
>>>>
>>>> It seems you can no longer change the default "page" for your site from
>>>> Weblog.vm. It looks like this happened as part of the
>>>> "StandardizedTemplates" change:
>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedTemplates
>>>>
>>>> This seems a step backwards in functionality because you can't have a
>>>> home page on your "website" that is not a Weblog page. It also requires
>>>> you to cut and paste between templates to make a "whole file" change
>>>> to your homepage.
>>>>
>>>> Regards,
>>>>
>>>> Sean
>>>>
>>>>
>>>> Documentation references:
>>>>
>>>> Section 4.1 (Weblog Settings):
>>>> Lists the "Page to be used as the homepage" setting (I put a ? here when
>>>> I submitted some edits recently)
>>>>
>>>> Section 5.1 (Weblog and day templates) of the manual says:
>>>> "Your weblog page is the main page of your web site, the one that is
>>>> specified as the default page in your Preferences:Settings page."
>>>>
>>>
>>>
>
>
>
Re: Changing default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
I will concede that the old way was slightly easier from a UE point of
view, but the point was to gain some leverage technically. We haven't
lost any real functionality and the fact is that most people still just
want their blog homepage to work the way it works by default, so you
represent the exception, not the rule.
>>From a technical point of view, allowing users to change their default
weblog template was making things harder on us in various ways. The
details are in the proposal that you mentioned.
-- Allen
On Tue, 2006-02-28 at 14:08, Sean Gilligan wrote:
> That's what I ended up doing, but it seems to me to be less friendly
> than the way it worked before. For two reasons:
>
> 1) I can't easily change the default template with a pop-up (I have to
> edit one template, select all text, copy, edit another, paste, save)
>
> 2) It's nice to keep the default template unmodified for comparison
> purposes or to switch back if I break something.
>
> I understand the benefit of clearly marking (and enforcing the presence
> of) the required templates, but is there any harm in allowing the
> default to be changed?
>
> -- Sean
>
>
> Allen Gilliland wrote:
> > You can still have a custom homepage, the only requirement is that you
> > use the template named "Weblog" to represent the homepage for your
> > blog. So login, edit template "Weblog", and do whatever you want with
> > it.
> >
> > -- Allen
> >
> >
> > On Tue, 2006-02-28 at 12:59, Sean Gilligan wrote:
> >> I've noticed an issue (don't know whether to call it a change, bug, or
> >> documentation discrepancy) in Roller 2.1.
> >>
> >> It seems you can no longer change the default "page" for your site from
> >> Weblog.vm. It looks like this happened as part of the
> >> "StandardizedTemplates" change:
> >> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedTemplates
> >>
> >> This seems a step backwards in functionality because you can't have a
> >> home page on your "website" that is not a Weblog page. It also requires
> >> you to cut and paste between templates to make a "whole file" change
> >> to your homepage.
> >>
> >> Regards,
> >>
> >> Sean
> >>
> >>
> >> Documentation references:
> >>
> >> Section 4.1 (Weblog Settings):
> >> Lists the "Page to be used as the homepage" setting (I put a ? here when
> >> I submitted some edits recently)
> >>
> >> Section 5.1 (Weblog and day templates) of the manual says:
> >> "Your weblog page is the main page of your web site, the one that is
> >> specified as the default page in your Preferences:Settings page."
> >>
> >
> >
> >
>
Re: Changing default page in Roller 2.1?
Posted by Sean Gilligan <se...@msgilligan.com>.
That's what I ended up doing, but it seems to me to be less friendly
than the way it worked before. For two reasons:
1) I can't easily change the default template with a pop-up (I have to
edit one template, select all text, copy, edit another, paste, save)
2) It's nice to keep the default template unmodified for comparison
purposes or to switch back if I break something.
I understand the benefit of clearly marking (and enforcing the presence
of) the required templates, but is there any harm in allowing the
default to be changed?
-- Sean
Allen Gilliland wrote:
> You can still have a custom homepage, the only requirement is that you
> use the template named "Weblog" to represent the homepage for your
> blog. So login, edit template "Weblog", and do whatever you want with
> it.
>
> -- Allen
>
>
> On Tue, 2006-02-28 at 12:59, Sean Gilligan wrote:
>> I've noticed an issue (don't know whether to call it a change, bug, or
>> documentation discrepancy) in Roller 2.1.
>>
>> It seems you can no longer change the default "page" for your site from
>> Weblog.vm. It looks like this happened as part of the
>> "StandardizedTemplates" change:
>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedTemplates
>>
>> This seems a step backwards in functionality because you can't have a
>> home page on your "website" that is not a Weblog page. It also requires
>> you to cut and paste between templates to make a "whole file" change
>> to your homepage.
>>
>> Regards,
>>
>> Sean
>>
>>
>> Documentation references:
>>
>> Section 4.1 (Weblog Settings):
>> Lists the "Page to be used as the homepage" setting (I put a ? here when
>> I submitted some edits recently)
>>
>> Section 5.1 (Weblog and day templates) of the manual says:
>> "Your weblog page is the main page of your web site, the one that is
>> specified as the default page in your Preferences:Settings page."
>>
>
>
>
Re: Changing default page in Roller 2.1?
Posted by Allen Gilliland <Al...@Sun.COM>.
You can still have a custom homepage, the only requirement is that you
use the template named "Weblog" to represent the homepage for your
blog. So login, edit template "Weblog", and do whatever you want with
it.
-- Allen
On Tue, 2006-02-28 at 12:59, Sean Gilligan wrote:
> I've noticed an issue (don't know whether to call it a change, bug, or
> documentation discrepancy) in Roller 2.1.
>
> It seems you can no longer change the default "page" for your site from
> Weblog.vm. It looks like this happened as part of the
> "StandardizedTemplates" change:
> http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_StandardizedTemplates
>
> This seems a step backwards in functionality because you can't have a
> home page on your "website" that is not a Weblog page. It also requires
> you to cut and paste between templates to make a "whole file" change
> to your homepage.
>
> Regards,
>
> Sean
>
>
> Documentation references:
>
> Section 4.1 (Weblog Settings):
> Lists the "Page to be used as the homepage" setting (I put a ? here when
> I submitted some edits recently)
>
> Section 5.1 (Weblog and day templates) of the manual says:
> "Your weblog page is the main page of your web site, the one that is
> specified as the default page in your Preferences:Settings page."
>