Yeah, I misstated the last thing bucause anything that isn't being
overwritten that has the template indicator set should get removed, but also
with this confirmation.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <roller-dev@incubator.apache.org>
Sent: Sunday, March 25, 2007 10:11 AM
Subject: Re: Proposal: Individual Templates by Action
I had played with a similar sort of idea where we try and track what theme
a template came from, if any, but that didn't really seem to solve the
problem.
With what you described it doesn't sound like you would really need the
indicator field because we do already have the ability to know whether a
template comes from a theme vs. a weblog because they are different
classes and we access them conditionally. i.e. it's always a case of "if
weblog is using a theme, use theme template, else, use weblog template".
I hadn't thought of asking the user to confirm an overwrite, but I'm not
sure that's really what we need. The problem is not so much that
templates can be overwritten, the problem is that if these templates for
special actions are optional and not all themes provide them then there's
a potential templates from previous themes to take effect when they aren't
supposed to. So the problem is that there isn't an overwrite situation,
which is actually what we want. So here's a more detailed example ...
Lets assume assume a new weblog is created and the user chooses the
'basic' theme to be used. The 'basic' theme includes these templates ..
weblog
permalink
search
_css
_day
Now, if the user customizes the 'basic' theme they get a copy of those 5
templates. After doing that customization the user sees the
'brushedmetal' theme and decides they like that one better so they choose
it. The 'brushedmetal' theme includes these templates ...
weblog
_css
_day
At this point the user has a theme which does not implement the template
actions 'permalink' or 'search' but they do have those templates in their
custom weblog templates, so what do we do when rendering search results?
The options are to either 1) disregard the users custom search template
left over from the 'basic' theme and just use the default weblog template
from the currently selected 'brushedmetal' theme or 2) use the search
template from the old customized 'basic' theme. #1 seems far more
appropriate to me, but that means that we can't let users define templates
for specialized actions when using a shared theme, which seems okay to me.
Now take the example one step further and assume the user decides to
customize the 'brushedmetal' theme and gets copies of it's 3 templates. At
this point the user would have 5 templates which are now mixes from
different themes ...
weblog - brushedmetal
permalink - basic
search - basic
_css - brushedmetal
_day - brushedmetal
So at this point we have even more of a problem because we have mixed
templates again, but no way to know which ones to disregard as being from
older theme customizations. It seems pretty clear that in this scenario
we would want to ignore the 2 templates left over from the previous theme
customization, otherwise the blog owner is going to get certain pages
rendered using an old theme.
The options I can think of for handling this scenario are to either 1) at
customization time we delete any templates for special actions which are
not in the theme being customized, 2) just leave the old templates around
and let the user deal with it, or 3) force all templates to be overwritten
with something, namely the weblog template.
So it seems to me that to solve this problem overall we are back to a
couple of the ideas that I proposed before ...
1. Enforce that whenever a shared theme is being used we disregard any
custom weblog templates using special actions. This seems fair since the
point of a shared theme is to define the blog design, so it seems okay to
prevent users from doing custom templates for actions when they want to
use a shared theme. Then when a theme is customized we would delete any
custom templates for special actions which are left over in weblog's
templates so that we leave the weblog containing only templates by action
which come from the theme being customized.
2. Enforce that all themes must implement all templates for custom
actions, which would ensure that any time a theme is customized it
overwrites all the necessary templates.
I'm still open to other ideas, but those are the main 2 that I could come
up with.
-- Allen
Anil Gangolli wrote:
How about this approach?
- Keep an indicator field/column on the template indicating whether it is
from a theme or not.
- Customized theme templates have the indicator cleared.
- Template pages that the user creates independently are created with the
indicator cleared.
- If a new theme being applied collides on a page name with a page that
doesn't have the indicator, the user gets
an opportunity to confirm the overwrite.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <roller-dev@incubator.apache.org>
Sent: Friday, March 23, 2007 3:58 PM
Subject: Re: Proposal: Individual Templates by Action
I've committed the initial support for this feature to the trunk and
it's working now. I still need to refine the UI, but the functional
parts are there. 2 things though ...
1. We need to decide what actions we are going to support. I'll go
ahead and propose this list right now ...
weblog - The default template, same as 'Weblog' template now.
search - The search results page.
permalink - The entry permalink page.
tags-index - The tags section index page (/<weblog>/tags/).
2. There is one somewhat yucky issue that has come up after I did the
implementation work. Since these templates are optional and may not all
be present in all themes there is a potential problem with action
templates being left around from previous themes when the user changes
their theme multiple times.
For example, assume ThemeA defines a 'permalink' template. The user
chooses ThemeA and decides to customize it, so the templates are copied.
Then the user changes their mind and decides to use ThemeB, which does
not have a 'permalink' template. At this point the user has a
'permalink' template in their templates section left over from their
previous theme which will likely cause problems when rendering their new
theme. So, how should we handle this?
1. When rendering templates by action from a theme we ignore custom
templates from the weblog for specific actions. This prevents the
scenario above because when using a shared theme we would not look for
the 'permalink' template in the users custom templates. The drawback is
that this prevents the user from creating a template for a specific
action if their theme doesn't do it for some reason.
2. Accept that this is a potential problem and let users deal with it
themselves by deleting these left over templates. Not exactly a pretty
solution :/
3. Force all themes to implement all action templates moving forward.
This is probably the cleanest and most ideal solution. Also remember
that with the new theme metadata file it's entirely acceptable to define
2 templates in the theme using the same physical file, so the templates
for 'weblog' and 'permalink' actions could both use the same Weblog.vm
file.
Those are the main scenarios I am seeing right now. There are a few
others that I had thought of but they didn't really solve any more of
the problem than these options.
Right now I am thinking that option #3 is sounding the best. It may
seem a little harsh to force all themes to implement all the various
actions we are going to define, but remember that as I said you can use
a single template to do that.
thoughts? opinions?
-- Allen
James M Snell wrote:
As an aside, we've had quite a few requests for a simple entry index as
part of our default blog template. It seems to be quite useful for
quickly finding old posts.
- James
Allen Gilliland wrote:
[snip]
... with the difference being that in a permalink you actually have
the
anchor part of the url and are therefore pointing to a specific entry,
which the entry index page would be the index page for that section.
the reason for having an entry index page would be if you wanted to
provide some kind of entry archive navigation. i.e. if you go to the
entry index page you may get a very short and simple list of all entry
titles, or possibly a big calendar or something. i'm not really sure
it
would be useful enough to be worth supporting, it's just one of our
urls
which we currently don't allow.
-- Allen
Thanks,
- Dave
