On Jan 24, 2010, at 8:54 PM, Rick Hadsall wrote: > Vincent Massol wrote: >> >> 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?
Yes. > 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. 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 >> 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? >> >> > 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? >>> >>> 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. >> >> > 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. >> 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. You can find all categories of extensions here: http://code.xwiki.org/xwiki/bin/view/Main/WebHome >> 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, Yes there's work to do in this regards and all help would be most welcome. The wiki is editable by all. > 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. 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 _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
