Re: [xwiki-users] Blog: Showing teasers inline on a wiki page
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
Re: [xwiki-users] Blog: Showing teasers inline on a wiki page
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). 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
Re: [xwiki-users] Help needed to setup XWiki Component development env in Eclipse
Hi Olivier, On Jan 23, 2010, at 7:55 PM, Olivier Berger wrote: Hi. If I get it right, nowadays, development of Java plugins/add-ons for XWiki is done through Plexus components. Nope :) They are done through XWiki components. See http://code.xwiki.org/xwiki/bin/view/Modules/ComponentModule Is there a way ATM to setup easily a HelloWorld component development project in Eclipse, in order to be able to learn and test such component development ? Sure it's very easy. You don't need to do anything. I do XWiki component dev in Eclipse and IDEA. It seems that the maven archetype is quite outdated, and I couldn't find examples on what needs to be configured in such a Java+Maven project to make it work. Annotations support for instance doesn't seem trivial to activate for me (Java and Eclipse beginner). Annotations is supported by default in eclipse since it's a java 5 feature. Also, as the Plexus archetype on codehaus is in no better shape (can't even be installed with maven), it doesn't help a lot. You shouldn't use that since we're not using Plexus (we were using it several months ago though but it was always under the hood and not exposed in any API). Please don't hesitate to post more specific questions if you need help. Right now the best doc is: http://code.xwiki.org/xwiki/bin/view/Modules/ComponentModule Thanks and enjoy! -Vincent PS: Feedback on component dev in xwiki is most welcome so that we can improve stuff even further. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Re: [xwiki-users] Blog: Showing teasers inline on a wiki page
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? 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? XWiki Enterprise 2.1.25683 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
Re: [xwiki-users] Blog: Showing teasers inline on a wiki page
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
Re: [xwiki-users] Blog: Showing teasers inline on a wiki page
Vincent Massol wrote: ... 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 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. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] wiki editor doesn' t work
I have posted a few questions here and I really appreciated your replies. I just received the 1,000,001 error from this XWiki program when I was trying to switch editor from WYSIWYG to WIKI. This error must be a result of some old version libs. I have excluded beanutil.jar and xercesImpl.jar. Again the error info: Jan 24, 2010 10:46:38 PM org.apache.tomcat.util.http.Parameters processParameters WARNING: Parameters: Invalid chunk ignored. 2010-01-24 22:46:38,351 [] [http://secure10.olemiss.edu/xwiki/bin/edit/Main/WebHome?editor=wiki$param] ERROR [/xwiki].[action] - Servlet.service() for servlet action threw exception java.lang.NoSuchFieldError: fFeatures at org.apache.xerces.parsers.XML11NonValidatingConfiguration.init(Unknown Source) at org.apache.xerces.parsers.XML11NonValidatingConfiguration.init(Unknown Source) at sun.reflect.GeneratedConstructorAccessor116.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at org.xwiki.xml.internal.DefaultXMLReaderFactory.createXMLReader(DefaultXMLReaderFactory.java:81) at org.xwiki.rendering.internal.util.XWikiXMLReaderFactory.createXMLReader(XWikiXMLReaderFactory.java:50) at org.xwiki.rendering.internal.parser.WikiModelXHTMLParser.createWikiModelParser(WikiModelXHTMLParser.java:154) at org.xwiki.rendering.internal.parser.wikimodel.AbstractWikiModelParser.parse(AbstractWikiModelParser.java:86) at org.xwiki.rendering.internal.parser.WikiModelXHTMLParser.parse(WikiModelXHTMLParser.java:111) at com.xpn.xwiki.wysiwyg.server.converter.internal.DefaultHTMLConverter.fromHTML(DefaultHTMLConverter.java:100) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:295) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Thread.java:595) -- View this message in context: http://n2.nabble.com/wiki-editor-doesn-t-work-tp4452240p4452240.html Sent from the XWiki- Users mailing list archive at Nabble.com. ___ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
[xwiki-users] Is it possible to programatically change xwiki class properties
Hi,
I am trying to change the values for a static list field in a wiki class
programatically but so far I have only figured out how to display them. Is it
possible to set class property values for static list fields programatically
through velocity or groovy code?
The code that I'm using to display the values is pasted below:
#set($classdocname = Test.TestClass)
#set($classdoc = $xwiki.getDocument($classdocname))
#foreach($field in $classdoc.getxWikiClass().properties)
* $field.prettyName
$doc.displayEdit($field.xWikiClass.get(values), ${field.name}_ , $field)
#end
Thanks,
Radek
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
