15 Jan
2010
15 Jan
'10
9:08 p.m.
Hi,
I'm new to XWiki but know Confluence pretty well. I'd like to be able to do
something similar to what Confluence does with their blog macro - be able to
show 1..n recent blog posts on a page, either just showing the titles (which
we can do with Velocity as per the default Dashboard), or showing a "teaser"
that shows the title, date posted, poster, and a small intro snippet of the
post...
Format would be like:
TITLE
snippet...
...
...
Posted by user at datetime (possibly comment stats etc)
Is there a way to do this in XWiki?
15 Jan
15 Jan
11:43 p.m.
Hi Rick,
On Fri, Jan 15, 2010 at 9:08 PM, Rick Hadsall <nospam(a)elwynor.com> wrote:
Hi,
I'm new to XWiki but know Confluence pretty well. I'd like to be able to
do
something similar to what Confluence does with their blog macro - be able
to
show 1..n recent blog posts on a page, either just showing the titles
(which
we can do with Velocity as per the default Dashboard), or showing a
"teaser"
that shows the title, date posted, poster, and a small intro snippet of the
post...
Format would be like:
TITLE
snippet...
...
...
Posted by user at datetime (possibly comment stats etc)
Is there a way to do this in XWiki?
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.
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?
Hope this helps,
Guillaume
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
24 Jan
24 Jan
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.
8:38 p.m.
Hi Rick,
On Jan 24, 2010, at 7:50 PM, Rick Hadsall wrote:
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).
Guillaume Lerouge wrote:
First let me thank you a lot for the feedback, that's really useful for us.
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? 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.
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
8:54 p.m.
Vincent Massol wrote:
XWiki Enterprise 2.1.25683
Yes, that's the problem. Perhaps a JAR with a package that would allow
developers to map functions or something- something to make it easier to
port to XWiki. If it's easy, they'll do it. Since many (most??)
Confluence add-ons are open source you guys could do 5-10 and release
them with lots of code comments and documentation to show how easy it
is. One thing that is clear is that XWiki CAN do whatever Confluence can.
First let me thank you a lot for the feedback, that's really useful for us.
No problem. As I continue to learn I'll give more.
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).
Cheers, Vincent. I'll take a look at this in more depth. One question
- does the WYSIWYG support pages that use the XWiki Syntax 2.0 though?
I'd avoid using confluence syntax on XWiki personally, and will
recommend my users to do the same.
Note: I am having trouble right now having two separate named blogs in
one space. I figured out how to do it in theory by renaming "Blog" to
whatever I want it to be, but since it relies heavily on templates and
what not from the Blog _space_, it doesn't actually work in practice.
But I will mess with the macros to see if this is necessary because if I
can control the display of blog teasers by category using an XWiki
macro, I'll do that.
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.
Inline scripting is a bad idea, though. But one thing that you might
want to do - and maybe you have it already, but the default pages don't
seem to make use of it - it allow user macros and global macros that are
code/markup/macros that can be referred to as a standard XWiki macro w/
parameters. Confluence does this - you can put the scripting and stuff
in the user macro or the space macro - which isn't Java code, but this
kind of code - and then users use the resulting macro w/ parameters in
the actual pages. This is much better as it's easier for end-users to
understand and work with. Code inline in the page - they'll just back
away from the keyboard and call someone else, which defeats the purpose.
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.
No, I think even in 3.1 you can't back-date the blog post, which is
stupid. I really like that you can do that - we're starting a new site,
we have extant blog posts - I want to preserve the continuity. Can't do
that on Confluence, so you're correct.
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.
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?
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.
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.
That's great news!
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/ )
I'll check this out more too, thank you. I missed that entirely.
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)
This might be your biggest weakness. The documentation was VERY
frustrating as a first time user to navigate through. It seemed it was
nearly empty - took a long time to even find the syntax pages and I
missed the macros pages, and the videos seemed to be all that there was,
and I really dislike videos so I tend to overlook that. I want
something I can have open in a new window and tab back and forth to.
More examples would help too - One of the things I'm going to need to do
is sort out how to re-do the look and feel of the site to remove the
"wiki" look and feel for most of it, as I'm using XWiki as a platform
for content management as well as a Wiki, which will actually only be a
small part of the site. There aren't many themes/etc available to
download (unless, again, I'm missing something) and I can't find
detailed documentation on how to do this.
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.
Yes, it'd be great to just do :
{blog:space=whatever|name=blogname|category=this,that|datefrom=optional|dateto=optional|max=#|displaytype=(full,summary,list)}
and have it.
One thing I'm also not clear how to do is if I wanted to put up a form
on a page that collects some information and then e-mails it to someone
(e.g., a request for information form) - is that something I can even do
at all? That would be okay to have scripting since it'd need CAPTCHA
and all that.
Rick
9:09 p.m.
On Jan 24, 2010, at 8:54 PM, Rick Hadsall wrote:
Definitely, that's what wiki macros are for (the link I gave in my first reply). Here
it is:
http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial
XWiki Enterprise 2.1.25683
hmm the conversion of the blog to xwiki syntax 2.0 was done in XE 2.1 final so it should
be ok. Sergiu any idea what could be wrong?
Yes, that's the problem. Perhaps a JAR with a package that would allow
developers to map functions or something- something to make it easier to
port to XWiki. If it's easy, they'll do it. Since many (most??)
Confluence add-ons are open source you guys could do 5-10 and release
them with lots of code comments and documentation to show how easy it
is. One thing that is clear is that XWiki CAN do whatever Confluence can.
You can find all categories of extensions here:
http://code.xwiki.org/xwiki/bin/view/Main/WebHome
Yes there's work to do in this regards and all help would be most welcome. The wiki is
editable by all.
Re captcha we have just committed a captcha component. You'll have it in XE 2.2
milestone 2 to be released next week.
Re mail, we have a mail sender plugin:
http://code.xwiki.org/xwiki/bin/view/Plugins/MailSenderPlugin
Thanks
-Vincent
Vincent Massol wrote:
Yes.
First let me thank you a lot for the feedback, that's really useful for us.
No problem. As I continue to learn I'll give more.
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).
Cheers, Vincent. I'll take a look at this in more depth. One question
- does the WYSIWYG support pages that use the XWiki Syntax 2.0 though? I'd avoid using confluence syntax on XWiki
personally, and will
recommend my users to do the same.
I agree since the xwiki syntax is more powerful, our support of the confluence syntax is
not complete (maybe around 70%) and as I said our wysiwyg editor won't allow editing
anything other than xwiki syntax for now).
Note: I am having trouble right now having two
separate named blogs in
one space. I figured out how to do it in theory by renaming "Blog" to
whatever I want it to be, but since it relies heavily on templates and
what not from the Blog _space_, it doesn't actually work in practice.
But I will mess with the macros to see if this is necessary because if I
can control the display of blog teasers by category using an XWiki
macro, I'll do that.
I'll let Sergiu answer this since he's the blog app author.
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.
Inline scripting is a bad idea, though. But one thing that you might
want to do - and maybe you have it already, but the default pages don't
seem to make use of it - it allow user macros and global macros that are
code/markup/macros that can be referred to as a standard XWiki macro w/
parameters. Confluence does this - you can put the scripting and stuff
in the user macro or the space macro - which isn't Java code, but this
kind of code - and then users use the resulting macro w/ parameters in
the actual pages. This is much better as it's easier for end-users to
understand and work with. Code inline in the page - they'll just back
away from the keyboard and call someone else, which defeats the purpose. 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.
No, I think even in 3.1 you can't back-date the blog post, which is
stupid. I really like that you can do that - we're starting a new site,
we have extant blog posts - I want to preserve the continuity. Can't do
that on Confluence, so you're correct.
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.
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?
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.
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.
That's great news!
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/ )
I'll check this out more too, thank you. I missed that entirely. 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)
This might be your biggest weakness. The documentation was VERY
frustrating as a first time user to navigate through. It seemed it was
nearly empty - took a long time to even find the syntax pages and I
missed the macros pages, and the videos seemed to be all that there was,
and I really dislike videos so I tend to overlook that. I want
something I can have open in a new window and tab back and forth to.
More examples would help too - One of the things I'm going to need to do
is sort out how to re-do the look and feel of the site to remove the
"wiki" look and feel for most of it, as I'm using XWiki as a platform
for content management as well as a Wiki, which will actually only be a
small part of the site. There aren't many themes/etc available to
download (unless, again, I'm missing something) and I can't find
detailed documentation on how to do this.
Some pointers:
- we have a new skin tutorial being written ((still a draft right now):
http://dev.xwiki.org/xwiki/bin/view/Drafts/XWikiNewSkin
- you could also check Skin extensions:
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial
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.
Yes, it'd be great to just do :
{blog:space=whatever|name=blogname|category=this,that|datefrom=optional|dateto=optional|max=#|displaytype=(full,summary,list)}
and have it.
One thing I'm also not clear how to do is if I wanted to put up a form
on a page that collects some information and then e-mails it to someone
(e.g., a request for information form) - is that something I can even do
at all? That would be okay to have scripting since it'd need CAPTCHA
and all that.
9:26 p.m.
Vincent Massol wrote:
Yep. Do you have a tutorial on how to combine that with a form? I need
to create a page that has a bunch of fields (Name, address, some free
form, etc) and then have everything submitted get e-mailed to someone to
process.
> ...
>
Thank you for all your suggestions, pointers, and comments. Clearly
support is not a problem with XWiki. I'll start working with this
information some more now and see if that helps me get the project
moving faster!
One thing
I'm also not clear how to do is if I wanted to put up a form
on a page that collects some information and then e-mails it to someone
(e.g., a request for information form) - is that something I can even do
at all? That would be okay to have scripting since it'd need CAPTCHA
and all that.
Re captcha we have just committed a captcha component. You'll have it in XE 2.2
milestone 2 to be released next week.
Re mail, we have a mail sender plugin:
http://code.xwiki.org/xwiki/bin/view/Plugins/MailSenderPlugin
25 Jan
25 Jan
10:24 a.m.
Hi there,
Vincent Massol wrote:
The problem is that the content is submitted and the editor reloaded.
The new WYSIWYG editor should behave correctly though.
Thanks,
Marius
Hi Rick,
On Jan 24, 2010, at 7:50 PM, Rick Hadsall wrote:
Guillaume Lerouge wrote:
First let me thank you a lot for the feedback, that's really useful for us.
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,
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.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
5401
days inactive
5411
days old
7 comments
4 participants
participants (4)
-
Guillaume Lerouge -
Marius Dumitru Florea -
Rick Hadsall -
Vincent Massol