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.



_______________________________________________
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Reply via email to