Dave wrote:
On 3/12/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Reminder, please comment on proposals if you have something to say. I
plan to start implementing my 4.0 proposals very soon.
Overall, I think this is a good idea. I do share James concern about
going too far and defining too many actions -- so I like your core
set.
yep. we should definitely discuss which ones we think are worth doing
and which ones are not, i don't have any strong opinions about that
except for the 2 i included by default, which are the search results
page and a tags index page.
my thinking right now is that it's best to start simple and build from
there. there is no reason to try and add lots of custom actions right
from the start and once the code is in place and working it should be
very easy to add support for new actions.
Here are a couple of questions about the proposal:
* What is the schema for the new ROLLER_ACTION table you are adding
and please include it's relationships with other tables.
I think you misread that part, there aren't any new tables, only a
single new column in the existing webpage table.
* How is the mapping from URL to Action Name defined and can it be
changed via configuration properties?
That's a very good question. The way I was going to define the mappings
was simply in the code, and most specifically the code which parses our
urls. So the logic would go in the various WeblogXXXRequest objects
under rendering.util.*
Making them configurable could be a cool idea, but I'm not sure exactly
how it would work. The other problem with making it configurable is
that it creates a potential for users to mess things up. I'll think
about this one a bit more though.
* Does this change any of the existing URL structure? (I hope not)
nope, no changes to any urls. it just allows us to assign a specific
template to be used for certain urls or possibly groups of urls so that
we don't have to keep using the Weblog template for rendering all views.
* What classes in the rendering/request-mapping system do you expect
to change? Just the PageServet?
pretty close, the changes are actually fairly minor. the first change
will be in the various WeblogXXXRequest objects which we use to
represent a parsed weblog request. those classes will be updated to
support an 'action' attribute so that when a url is parsed into one of
these objects we determine what type of action is represents.
then the second change is in the PageServlet and SearchServlet where
we'll update it's rendering logic so that it looks at the 'action'
attribute from the parsed request and chooses the appropriate template
for rendering based on the action value. right now the logic is pretty
simple ...
if(custom page) {
// lookup custom template and render
} else {
// get 'Weblog' template and render
}
... that logic will be expanded to include other alternatives like ...
} else if(action == tagsIndex) {
// look for special tags index template
}
* What are the implications for customizable feeds? I assume we'd use
actions to define them too w/actions like entryfeed, commentfeed.
This doesn't actually change the situation with customizable feeds and
to be honest I'm still not sure what we really want to do regarding the
idea of customizable feeds. But that should probably be a separate
discussion.
This proposal isn't currently planning to make any changes with the way
that feeds are rendered. It could if we wanted it to, but I wasn't
planning on it. If we decided that we did want to allow for custom feed
actions then I think it would work like you suggest above where we
define some special actions to represent customized feeds which could be
edited on the Template Editing UI.
* What's the difference between an "entry index" and a "permalink" action?
They are just different urls. So the entry index url is ...
<weblog>/entry/
... and the permalink url is ...
<weblog>/entry/<anchor>
... 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
