I like the idea of allowing a blog's look and feel to be extended to the
search results view.
I'm not sure how many more actions are required, I suppose an entry
would be good & so the permalink.
On my blog, I have an archive page, a links page and an about page.
I don't like the calendar widget, I don't post frequently enough to
allow it to be useful, so I have created a couple of tools to allow
people to find old posts, including the keyword search, the tag cloud,
the last 128 articles and my bookmarks and the calendar on the archive
page, and I have a links & tags page where I publish my roller &
del.icio.us tag clouds, which I may augment by adding my flickr and
slynkr tag clouds. None of these seem to be actions though.
This is shared as an example use case.
Allen Gilliland wrote:
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
--
Dave
<http://www.sun.com> * David Levy *
*Sun Microsystems Ltd.*
55, King William St.,
London EC4R 9ND United Kingdom
Phone +44 (0) 20 7469 9908/x18308
Mobile +44 (0) 7710-360922
Blog http://blogs.sun.com/DaveLevy
Email [EMAIL PROTECTED]
Sun Proprietary & Confidential . This e-mail message is for the sole use
of the intended recipient(s) and may contain confidential and
privilidged information. Any unauthorised review, use, disclosure or
distribution is prohibited. If you are not the intended recepient,
please contact the sender by reply e-mail and destroy all copies of the
original message.
