Hi there, Vincent Massol wrote: > Hi Rick, > > On Jan 24, 2010, at 7:50 PM, Rick Hadsall wrote: > >> 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? > > First let me thank you a lot for the feedback, that's really useful for us. > >> 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, > > In term of markup language, we had XWiki syntax 1.0 which was close to > confluence's syntax (since both depended on Radeox). However we've seen lots > of limitations and have created XWiki Syntax 2.0 which we believe is the most > powerful markup language (basically we can do back and forth from HTML and > not loose content which isn't true for the other syntaxes we know of). > > The new syntax is described here: > http://platform.xwiki.org/xwiki/bin/view/Main/XWikiSyntax > > I'd be happy to know if you still think there are things better done in the > confluence syntax and that xwiki's syntax cannot do (I believe the opposite > is true). >
> Also, to be noted, is that XWiki is polyglot ie it supports several syntaxes, > amongst which Confluence syntax (although if you use it you won't be able to > use our new WYSIWYG editor since right now it only supports XWiki Syntax 1.0). Correction: the new WYSIWYG editor works best with XWiki Syntax 2.0 but it's not restricted to this syntax. The WYSIWYG editor understands and produces annotated XHTML thus it can work with any syntax that has a parser from and a renderer to annotated XHTML. Of course, if the storage syntax is less powerful than XHTML you'll loose information during page save. The editor can be adjusted to restrict some XHTML constructs in order to reduce the information loss. > >> and you can do pretty >> much anything you want with the macros they provide and the parameters >> for them. > > I agree that confluence has an edge in term of number of macros. Where XWiki > catches up I believe is with the ability to write velocity/groovy/ruby/python > scripts directly in pages along with a powerful API accessible from theses > scripting language which makes it relatively easy to script any missing > macro. However this is no substitute for more macros since standard users may > not have the skills to write such scripts. > >> 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. > > I remember using the confluence blog a long time ago (around 2005) and I > didn't like it because it was something part of the Confluence core and you > couldn't modify it to your needs. For example it had not ability to modify > the date of a post (that's probably been added since then) and there was no > way I could add it (except to go in java dev mode and rewrite the blog > provided I had access to the sources). In XWiki the blog application is > contained in wiki pages and you can edit them and modify them to suit your > exact needs, where needed. > > In due time we'll probably make the most obvious features available directly > as macros or as configuration options but this example highlights one main > difference of confluence vs xwiki IMO. Confluence is done well and for a > usage in mind, XWiki is a toolbox/platform with powerful APIs. A few years > back XWiki was hard for its users since it was powerful but you needed > knowledge to benefit from this power. However for the past 3 years we've > focused on usability and it's starting to show. We still have the powerful > engine but now features are also much more accessible/usable than before. > Obviously there are always improvements to be done and we have lots of ideas > on stuff to do :) > >> 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. > > Right... > >> 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 problem is that the content is submitted and the editor reloaded. The new WYSIWYG editor should behave correctly though. Thanks, Marius > > This is strange. Could it be that you're using a version of XWiki where the > blog was still using the old wysiwyg editor? What version of XWiki Enterprise > are you using? > >> 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. > > Yep, see above. > >> It's something that, if I were XWiki, I would target to make >> plugins compatible with Confluence's. > > Yes we wanted to do this at one point but it's not something easy to do. We'd > need a confluence runtime, ie implement all APIs available from confluence > plugins which is probably the whole platform if we wanted to be 100% > compatible. > >> 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. > > I also agree here. XWiki permissions are probably more powerful but still too > complex to use. We have scheduled to work on this in the near future. > >> 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 > > Yes I know this confluence page but you shouldn't compare it with our syntax > page. On our syntax page we only describe the syntax not macros (we only > refer to it). > > Our macro page is here: > http://code.xwiki.org/xwiki/bin/view/Macros/ > > I agree that the presentation is nicer on the confluence page though and I > agree it coud be good idea that we dynamically include macro description > directly in that syntax help page. > > Note that there are also confluence macros that map to XWiki applications. > For example the confluence dynamictasklist probably maps to our Task > application: > http://code.xwiki.org/xwiki/bin/view/Applications/TaskManagerApplication > > (for other apps see http://code.xwiki.org/xwiki/bin/view/Applications/ ) > >> 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. > > cool. > >> 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. > > Again thanks for the feedback. What I think is: > > * several parts of the power of xwiki doesn't shine enough in ithe > documentation (or is too scaterred to perceive immediately) > * confluence has many macros and we should definitely take time to boost our > number of macros (especially since it's very easy to do with our wiki macros > notions - not sure if you've seen that one, it's awesome - see > http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial ) > * XWiki is still a bit more tech oriented than confluence is, even though > we're progressing fast in this domain, from release to release. The 2.2 > release (which is almost ready) has several new stuff in this regard: new > profile UI, improved menus, wiki macros in wiki farms, etc) > > Now let's focus on your need for blog macros and let's write them. I'm pretty > sure they are only a few lines of velocity which we can then wrap in a wiki > macro. > > Thanks Rick > -Vincent > > > _______________________________________________ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
