24 Jan
2010
24 Jan
'10
7:50 p.m.
Guillaume Lerouge wrote:
Yes, definitely. The blog actually used to do this but we changed it some
time ago because when content got truncated sometimes markup was no longer
closed properly, which led to wome weird display on the blog homepage (half
of the text getting underlined, stuff like that).
With the new rendering engine, it could be possible to write a "smart"
snippet algorithm that would cut the markup in the right place. In the
default version, you'll notice that if you manually fill the "summary"
field
of a blog post it gets displayed on the blog homepage instead of the actual
article content, which I believe is close to the behavior you're looking
for. If that's what you want to do, follow the indications on
http://code.xwiki.org/xwiki/bin/view/Applications/BlogApplication to create
a blog out of any page.
OK. I'll give this a try. In theory the engine could be smart enough
to know if it is going to truncate in the middle of markup and adjust
accordingly, but having people provide a summary is a decent alternative.
But what I'm trying to do is create the blogs, but then be able to list
the blogs on another regular wiki/content page - either in a list or a
summary format. I don't want to force the user to go to the "blog" page
to get the teasers for that content - I'd like to be able to tease the
content on another page or two (where relevant, by category, or blog,
etc) and let them click to read the full thing.
By the way, I'd be interested in hearing your
feedback about XWiki as
compared to Confluence. Specifically, if you were to name one thing you like
best in XWiki vs Confluence and one thing you like best in Confluence
compared to XWiki, what would those be?
Well, it's probably too soon to tell as I'm very new with XWiki and very
comfortable with Confluence. My sense is that XWiki has a long way to
go - Confluence's markup language is excellent, and you can do pretty
much anything you want with the macros they provide and the parameters
for them. For example with the blog issue you simply use the blog macro
on any page and pass it the parameters for which blogs you want
(category, space, date ranges, what kind of listing, etc) and voila.
There's no need to know Velocity to do anything so you don't have all
this code that regular editors and site maintainers won't ever have a
prayer of knowing all over the place. XWiki's preview doesn't work
correctly - often you will preview and want to go back to editor and
it's broken. For example, edit a blog and then preview, and when you go
back to edit it will have a different look (no 'summary' and 'content'
pane, just one pane, and an error in it). Very annoying. The number of
plug-ins and add-ons to confluence is massive - it allows a richness of
content that is unmatched by pretty much any other product on the
market. It's something that, if I were XWiki, I would target to make
plugins compatible with Confluence's. Confluence's permissions seem to
be easier to use and apply to discrete pages, spaces, and functions
within than pretty much any other product's. Confluence's macros around
inclusion of Confluence content really set it apart from XWiki. Pretty
much anything in Confluence can be included on a page through a macro.
That's something that really helps. I know you can code it in XWiki but
that really is not something that makes sense for a site managed by end
users.
See:
http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax
versus
http://sandbox.onconfluence.com/renderer/notationhelp.action?section=all
The panels on XWiki are awesome. That's really an easy way to create
that sort of thing - Confluence can't do it - you have to do sections
and such and it's not perfect. You can do it, but it's not as easy as
XWiki's.
Again- take with a bit of a grain of salt because I'm much, much more
familiar with Confluence. I'm using XWiki for a client who doesn't want
to pay the license fee, which is a major advantage for XWiki. But right
now, it's not quite there as far as ease of use or richness/completeness
of features.