- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [ANN] XWiki Enterprise 1.8 Release Candidate 1 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.8 Release Candidate 1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download First release candidate of the XWiki Enterprise 1.8 version. Main changes: * WYSIWYG improvements: macro support implemented, default browser list support overridden. * Various improvements on XWiki REST service. * Various bugs fixed in XWiki 2.0 syntax rendering. * Upgrade to groovy 1.6 RC3. Important bug fixes: * XWIKI-3208: getSpaceDocsName does not work with postgresql Fixed. Patch submitted by Dave Burklund. For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise18RC1 Note that general goals for XWiki Enterprise 1.8 are: * Office Importer * New Blog * REST API * Finish new rendering/syntax * Finish new WYSIWYG * French XE * MediaWiki import Thanks, - The XWiki dev team

16 years, 7 months

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise Manager 1.5.1 released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise Manager 1.5.1. This release is based on XWiki Enterprise 1.7.2. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Main changes since XWiki Enterprise Manager 1.5: * XEM now support virtual wikis using path urls and not host urls * XEM is now using XWiki Enterprise 1.7.2 For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM151 Thanks -The XWiki dev team

16 years, 7 months

1
0
0 0

[xwiki-devs] [ANN] XWiki Enterprise 1.7.2 Released

by Jean-Vincent Drean

The XWiki development team is pleased to announce the release of XWiki Enterprise 1.7.2. This is a bugfix release following XE 1.7.1. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download Important bugs fixed * XWIKI-3119: URLFactory does not work properly with an invalid request in the context * XWIKI-3208: getSpaceDocsName does not work with postgresql Syntax and WYSIWYG 2.0 Bugs fixed * XWIKI-3114: Backspace is ignored at the beginning of a list item if the previous list item is on a lower level * XWIKI-2734: Cannot edit the outer list item * XWIKI-3112: Cannot indent a list item after undo step * XWIKI-3089: Cannot move cursor after table * XWIKI-3090: Cannot move cursor before table * XWIKI-3110: Cannot unbold a bold word selected with double-click * XWIKI-3170: Custom parameter ending syntax characters are not escaped inside xwiki/2.0 custom parameter values * XWIKI-3104: Erroneous rendering of links to page anchors * XWIKI-3109: Headers generated from wiki syntax look and behave differently * XWIKI-3071: Hitting enter at the end of the paragraph moves the cursor at the beginning of the next unit in IE * XWIKI-3098: If a macro throw a NullPointerException it breaks the whole rendering process * XWIKI-3122: If macro contains format block the macro is printed in XWiki syntax with empty custom parameters before it * XWIKI-2993: Insert horizontal line on a selection of unordered list. * XWIKI-3113: New list item is on the same line after undo step * XWIKI-3096: NullPointerException when using toc macro without any section * XWIKI-3061: Overwrite the default list support * XWIKI-3115: Pressing Tab in the last table cell should generate a new table row * XWIKI-3143: Quotes are not escaped inside xwiki/2.0 custom parameter values * XWIKI-3072: Special characters in tables are not escaped by XWIKI renderer * XWIKI-3105: Use the same Range implementation for all browsers * XWIKI-3159: WYSIWYG 2.0 Editor Stylesheet Problem * XWIKI-3138: WYSIWYG 2.0 Preview Error * XWIKI-3053: When a HR is inserted at the beginning of a paragraph an extra empty paragraph is generated before that HR * XWIKI-3103: XHTML parser does not support macro with parameters but without content * XWIKI-3195: underscores in links not recognized in new wysiwyg editor For more information see the Release notes at: http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise172 Thanks -The XWiki dev team

16 years, 7 months

1
0
0 0

[xwiki-devs] embedding XWiki?

by Allen Rohner

I'm starting a webapp project in Clojure (http://clojure.org), and I'm looking for a wiki engine to embed. I want to control the look and feel of my application, and use the wiki engine as a backend only. i.e. on wiki pages I will have my own menus and other content around the wiki text. Is XWiki a good candidate for this? >From reading the source code, I think I can figure out how to start an embedded XWiki inside my app. Is this a good idea? The dev documentation was not very helpful in this area, which makes me ask: is this a "supported configuration"? Thanks, Allen

16 years, 7 months

3
2
0 0

[xwiki-devs] [VOTE] Release XE 1.7.2 and XE 1.8RC1

by Jean-Vincent Drean

Hi devs, 1.8RC1 is planned for today and I'd like to suggest the following: - release XE 1.7.2. - release XE 1.8RC1. - create 1.8 branch and make trunk 1.9. - delete the 1.7 branch since our rule is to maintain only 2 branches at the same time. I'll try to do it as quickly as my failing laptop will allow. Here's my +1. Thanks, JV.

16 years, 7 months

5
5
0 0

[xwiki-devs] [VOTE] Add new XWiki API: public String getURL(String fullname, String action, String queryString, String anchor, XWikiContext context)

by Vincent Massol

Hi, There's currently an API for: public String getURL(String fullname, String action, XWikiContext context) it's passing null to the underlying call to the URL factory for query string and anchor. I'm thus proposing to add the following API in XWiki.java: public String getURL(String fullname, String action, String queryString, String anchor, XWikiContext context) In the future we'll need to rationalize all this of course. I need this because I'd like to remove the throws XWikiException in DocumentAccessBridge.getURL() since getting a URL for a document should never raise an exception. Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 7 months

5
5
0 0

[xwiki-devs] [VOTE] Remove begin/endError events in the new rendering

by Vincent Massol

Hi devs, I introduced these events initially in order to be able to have inline error reporting in a generic manner. However there are some problems: * it currently works only for macros, if you wrap other blocks with an error block you'll get to see the output of what is wrapped. * there's no block other than the MacroBlock that can raise an error so there's no need to have a generic way of reporting an inline error Thus I propose the following (suggested by Marius): 1) We remove the begin/endError events 2) When macros fail to execute we output the exact same content as is currently output by the begin/endError events but generated as the macro content. Since we have macro marker block around it, it'll work just fine. Here's my +1 Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 7 months

5
5
0 0

[xwiki-devs] My first try to compile

by Hoani Cross

Hi ! Since a few days, I'm trying to compile the latest source code of xwiki fetching it from the SVN. Following the tutorial from the xwiki website first, I encounter major problems (like the TestCase class cannot be found !) but it resolves as magic a few days after by just updating the code. My last try was tomorrow, because I wanted to look at the last XWiki GWT impl. It took 2 hours to resolve problems and have the core module compiled and installed through maven. Here are the problems I encountered : - the sablecc plugin from the xwiki-core-query-jpql-parser module give me some trouble especially having the generated classes available for the test classes, my solution was to disable tests for this module (I wanted to go as fast as possible), - the project xwiki-core-query-xwql had problems in test cases getting some classes from the previous project : disabling the test was also my solution, - the xwiki-core tests fails at this test : public void testGetLinkedPages10() { this.mockXWiki.stubs().method("exists").will(returnValue(true)); this.document .setContent("[TargetPage][TargetLabel>TargetPage][TargetSpace.TargetPage][TargetLabel>TargetSpace.TargetPage?param=value#anchor][ http://externallink][mailto:mailto]"); List<String> linkedPages = this.document.getLinkedPages(getContext()); assertEquals(Arrays.asList("Space.TargetPage", "Space.TargetPage", "TargetSpace.TargetPage", "TargetSpace.TargetPage"), linkedPages); } As you may noticed, I just adapt the assertEquals() line, even if the expected result is not exact : I want to have the product installed, point. Then I re-run maven from the root, let it go and went to bed. This morning I even get another test failed on xwiki-plugin-spacemanager... :( What do you suggests me ? Deactivating the tests for all the modules as a env. var ? I don't want to spend hours just for compiling xwiki... Thx in advance ! -- Hoani CROSS Globotraders Tahiti Founder [http://globotraders-tahiti.com]

16 years, 7 months

3
8
0 0

[xwiki-devs] [VOTE] Port the REST subsystem to JAX-RS

by Fabio Mancinelli

Dear all, this is more a RFC than a vote... Currently the REST subsystem is written using Restlet and its API and there is a layer based on the XWiki Component manager written by me that is used to declare and configure resources and components for providing representations in a more dynamic way. During the last weekend I spent some time experimenting with the JAX- RS API and as a test I tried to port the current implementation to this API. I was able to do so without too much effort and the result was also a drastic reduction in code complexity. In fact all the plumbing I wrote is already handled by the JAX-RS API implementation. Actually the JAX-RS API provides also more powerful mechanisms wrt the ones I wrote because it takes into account representations in responses (GET), representations in requests (PUT and POST) and exception mappings (i.e., the possibility of capturing and representing all kind of exceptions, checked or unchecked). One consequence of these features is that I was able to write methods to handle requests that use our data model without having to deal with complicated try/catch blocks for adjusting the response wrt to exception thrown. Conversions from objects of our data model to representations and viceversa (text/plain, text/xml, etc.) are handled by the framework, and exceptions as well. The problem was the implementation to use. I tried both Jersey and Restlet and both of them were fine. Jersey misses some features such as authentication handling (I had to wrote a basic authentication handler by hand) and is not flexible as Restlet. Restlet, on the contrary, is very powerful and has a very good support for JAX-RS but it lacks automatic generation of the WADL description of the application. Coming to a conclusion, I would like to switch to JAX-RS + Restlet because we can have the best of the two worlds. If we need, in fact, we can still leverage the Restlet API if the JAX-RS is not suitable for implementing a resource. We will have to give up the WADL support for the moment, but I don't think this is a big deal with respect to the gain we have in code maintainability (no more plumbing and easier resource declaration) and reduced code complexity overall. And WADL for JAX-RS will be eventually implemented so it's just a question of time. Here it is my +1 WDYT? Regards, Fabio

16 years, 7 months

4
4
0 0

[xwiki-devs] [VOTE] Remove moderate style filtering option from office importer

by Asiri Rathnayake

Hi Devs, Currently officeimporter application has three levels of style filtering options: 1. Strict: Remove all the styles presented in the original document except for those that can be mapped directly into xwiki syntax 2. None: Keep all the styles (no filtering what so ever) 3. Moderate: Only keep those styles without which the output would be drastically different from the original document (ex: alignments, image widths etc.) As you can see the third option (was my idea) is kind of hard to define and can be confusing to the user as well. The first too options make a lot of sense to the user and after discussing with vincent I decided to ask for a vote to remove it. Plus this is consistent with the officeimporter wysiwyg plugin which only allows either to keep all the styles or remove everything. Also, if we decide to remove the moderate filtering option, we can represent the options by a checkbox (Filter Styles). Which should be the default filtering criterion? I'm thinking it should be not to filter any styles so that the output looks more or less like the original document. Here's my +1. WDYT? Thanks.

16 years, 7 months

5
13
0 0

[xwiki-devs] Could not initialize main XWiki context

by Nishiii

Hi, I have installed the xwiki.war complete all the intructions for Tomcat Servlet and MySQL Database configuration. But my xwiki is not working properly ,its giving me the following error. I have installed the enterprise version of xwiki war. I have gone throught the forum to see if anyone's got a similar error , but looks like its just me, just in case if i have missed this error posted by some user and if there was a solution posted earlier, please point me to that link. Here is the exception what i get type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception javax.servlet.ServletException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3001 in 3: Cannot load class com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from param xwiki.store.migration.manager.class Wrapped Exception: Error number 0 in 3: Exception while hibernate execute Wrapped Exception: Hibernate Dialect must be explicitly set org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535) org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) javax.servlet.http.HttpServlet.service(HttpServlet.java:743) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) root cause com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not initialize main XWiki context Wrapped Exception: Error number 3001 in 3: Cannot load class com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from param xwiki.store.migration.manager.class Wrapped Exception: Error number 0 in 3: Exception while hibernate execute Wrapped Exception: Hibernate Dialect must be explicitly set com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:328) com.xpn.xwiki.XWiki.getXWiki(XWiki.java:515) com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136) org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) javax.servlet.http.HttpServlet.service(HttpServlet.java:743) javax.servlet.http.HttpServlet.service(HttpServlet.java:856) com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) note The full stack trace of the root cause is available in the Tomcat logs. ANd i have installed JDK 1.5. Can please let help me out with this error. Thanks, Nishii -- View this message in context: http://n2.nabble.com/Could-not-initialize-main-XWiki-context-tp534219p53421… Sent from the XWiki- Dev mailing list archive at Nabble.com.

16 years, 7 months

3
3
0 0

[xwiki-devs] [VOTE] Make the MS Office integration a top level project

by Florin Ciubotaru

Hi devs, I would like to release a first version of XWord, but in order to do that we need to move it out of the sandbox. Here is what I propose: * Rename XWord to XOffice since we want to address other Office applications in the future; * Move the code in svn to https://svn.xwiki.org/svnroot/xwiki/xoffice * Rename the jira project to XOFFICE * Create http://xoffice.xwiki.org * in the future we should try to integrate msbuild with our hudson server, to have XOffice under countinuous integration * release XOffice - version 1.0 M1 Here is my +1

16 years, 7 months

5
7
0 0

[xwiki-devs] [Proposal] Add support for bridging Velocity Macros with the new Rendering

by Vincent Massol

Hi, We need to allow users to write macros using Velocity and still use the same mechanism as the new rendering. Basically this means transforming velocity macros into Rendering Macros. Once this is done then the velocity macro will be able to be used as standard Rendering Macros, they'll appear in the new WYSIWYG, etc. Here's a proposal for doing so: * Split xwiki-velocity/ module into 2 - xwiki-velocity-engine/ (the one currently in xwiki-velocity) - xwiki-velocity-macro/ (the new one) * In xwiki-velocity-macro create a VelocityMacroManager class that does the following: - initialize itself at xwiki startup - create a VelocityMacroClass definition in the wiki if it doesn't exist - query the wiki for all objects of type VelocityMacroClass - for each of them register them dynamically (we can already do this) as a Rendering Macro * The VelocityMacroClass has several fields: - macro name, parameter names, parameters description, macro description, usage example, velocity content to execute (the macro content) * The VelocityMacroManager register itself against the Observation component to receive notifications whenever a VelocityMacroClass is modified (added, removed, etc) * Users will then be able to add velocity macros by simply creating a new page, adding the VelocityMacroClass in it, fill the values. * We should also provide a VelocityMacroClassSheet so that the macro page containing the VelocityMacroClass can display the help for the macro (self-standing) The nice thing is that this keeps velocity macro handling in the xwiki- velocity/ module and makes it completely optional (i.e. the wiki will still work and there's no ties with this feature elsewhere). WDYT? Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

16 years, 7 months

3
12
0 0

[xwiki-devs] [PROPOSAL] Remove generated links from backlinks with 2.0 architecture

by Thomas Mortagne

Hi devs, Currently when a document is saved it is rendered with a custom URLFactory to catch links. IMO this is wrong because: - it's impossible to really support generated links since the document is renderer with a specific context in a specific time etc... - it could makes saving document real slow if the document contains big scripts which should not have to worry about that kind of very crappy rendering I understand it was easier to do this that way for 1.0 since it was difficult to parse the document content to find links but the new rendering does not have this issue anymore. It's now very easy to get the XDOM and all the links it contains. So I propose to only take the links found in XDOM before the transformation. Here is my +1 Thanks, -- Thomas Mortagne

16 years, 7 months

5
4
0 0

[xwiki-devs] My presentation

by Hervé Agnoux

Hi, I present myself because I have the intention to participate to the dev of xwiki. I hope xwiki give me a multi-user platform. I construct a swing application with formulaires which modifiates some web pages. My concepts of "content", "forms" and so on are close xwiki. My competences are all commons stufs about web, all commons stufs about net, spring, jdbc, jcr (jackrabbit), swing, freemarker (a little velocity, but I prefer freemarker), xml, a little j2me, etc. I work with netbeans, ant, maven, junit, linux (mandriva). I am in Saint Etienne, France. I work in my very little company (myself, it's all), and the customers are the ultimate immediate chiefs. I dispose of one or two hours by days for xwiki. I suppose the best to begin is to install sources and solve some simple bugs ?... (and sorry for my english)

16 years, 7 months

2
1
0 0

[xwiki-devs] Arvind Gupta wants to share their location with you on Google Latitude

by Arvind Gupta

Arvind Gupta (arvind.bernaulli(a)gmail.com) wants to share their location with you on Google Latitude. You need to sign in to Latitude with a Google Account (eg @googlemail.com) and invite Arvind Gupta. To get started, or to learn more about Latitude, click the link below. http://m.google.com/latitude (c) 2009 Google Inc., 1600 Amphitheathre Parkway, Mountain View, CA, USA. Terms of Service | Privacy Policy

16 years, 7 months

2
2
0 0

[xwiki-devs] gallery of google visualization widgetry (some of which xwiki might want)

by Niels Mayer

http://code.google.com/apis/visualization/documentation/gallery.html Niels http://nielsmayer.com

16 years, 7 months

2
1
0 0

[xwiki-devs] [WIP] Wiki Explorer Widget

by Jean-Vincent Drean

Hi devs, I'm currently doing some experiments about the wiki explorer and I've started to play with smartGWT. My initial plan was to use the new REST APIs to populate the wiki explorer tree, the root node would have called /rest/wikis, wiki nodes would have called /rest/wikis/WIKI/spaces, and so on. Unfortunately it is currently impossible to use multiple sources (REST in our case) to populate smartGWT TreeGrid, there are experiments in the field but this is not yet supported [1]. Note that using a single DataSource works like a charm but as far as I understand it is not designed to lazily load bunch of items after bunch of items from the server (they are lazily parsed/rendered though), in our case it means that we'd have to build a huge XML file describing all the resources in the wikis to feed the wiki explorer; of course this is not an option. Here are the options I'm currently evaluating: 1) Continue with smart(client/GWT) and extend smartGWT TreeGrid to be able to use multiple DataSource (if doable). 2) Develop a dynamic tree on top of GWT Tree widget and: a) use the GWT XWikiService to populate the tree (need new methods, doesn't take advantage of REST operations). b) use restlet GWT REST client [2] to populate the tree from our REST services. c) use sonatype GWT REST client [3] to populate the tree from our REST services. [1]: http://forums.smartclient.com/showthread.php?t=3181 [2]: http://wiki.restlet.org/docs_1.1/13-restlet/144-restlet.html [3]: http://svn.sonatype.org/nexus/trunk/sandbox/nexus-gwt-ui/sonatype-gwt-rest/ Thanks, JV.

16 years, 7 months

5
6
0 0

[xwiki-devs] Arvind Gupta wants to share their location with you on Google Latitude

by Arvind Gupta

Arvind Gupta (arvind.bernaulli(a)gmail.com) wants to share their location with you on Google Latitude. You need to sign in to Latitude with a Google Account (eg @googlemail.com) and invite Arvind Gupta. To get started, or to learn more about Latitude, click the link below. http://m.google.com/latitude (c) 2009 Google Inc., 1600 Amphitheathre Parkway, Mountain View, CA, USA. Terms of Service | Privacy Policy

16 years, 7 months

1
0
0 0

[xwiki-devs] Fwd: [ossgtp] Groovy 1.6-RC-3 is released,

by Vincent Massol

Maybe we could move to RC3? -Vincent Begin forwarded message: > From: Guillaume Laforge <glaforge(a)gmail.com> > Date: February 9, 2009 2:54:57 PM CEST > To: Groovy User <user(a)groovy.codehaus.org>, dev <dev(a)groovy.codehaus.org > >, announce(a)groovy.codehaus.org, Grails Users <user(a)grails.codehaus.org > >, Gant_Users <user(a)gant.codehaus.org> > Subject: [ossgtp] Groovy 1.6-RC-3 is released, > Reply-To: ossgtp(a)yahoogroups.com > > Hi all, > > A quick message to tell you we've just released our third release > candidate for Groovy 1.6. > > Hopefully this will be the last one, unless we uncover anything > critical. > But that's where YOU can help, by testing this RC thouroughly and > report anything odd you may find. > Thanks in advance for your help. > > You can download Groovy 1.6-RC-3 at the usual place: > http://groovy.codehaus.org/Download > > You can see the list of JIRA issues fixed since the last RC here: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10242&fi… > > The Jars will soon hit the Maven repositories -- but are already > available on the Codehaus repository. > > Big thanks to all the developers and contributors for your hard work! > > -- > Guillaume Laforge

16 years, 7 months

1
0
0 0

[xwiki-devs] 1.8M2: suggest public vs private v-hosting option to prevent access to other wikis

by Niels Mayer

In numerous places in the XE1.8m2 interface, the user is exposed to more information than is necessary, when virtualhosting ( http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization ) is enabled. The current virtualhosting implementation seems to assume a shared farm of wikis where one may want to expose other wikis in the farm. However, one may also want to use virtualhosting in implementations where there is no sharing between virtual hosts. So for example, we have: (1) the column 'Wiki' in Main.SpaceIndex ( e.g. http://nielsmayer.com/xwiki/bin/view/Main/SpaceIndex?space=Main ) as well as Main.WebSearch (e.g. http://nielsmayer.com/xwiki/bin/view/Main/WebSearch?text=fedora&x=0&y=0 ) -- shows "host_xe_nielsmayer_dot_com" but it doesn't really need to. (should be optional). (2) in the wysiwyg editor's "link editor" ... there's an option-menu "Choose a wiki: " that exposes the names of all the wikis, and all their database names. (should be optional: if "standalone" default to current wiki). For these, and potentially other cases, I think this behavior should be optional, not default. Most virtual wiki setups would not want their wikis to "see" each other, IMHO. This includes a fairly common scenario -- the private/public wiki setup -- people inserting links via wysiwyg in the public wiki shouldn't see all the link-names and spaces in the private wiki. Likewise, the notion of global and local users having potential access to the wiki should be based on whether the virtual-wiki setup is "shared" or "standalone." Finally, exposing the database name of the virtual-wiki (to all search engines as well) is a small, but unecessary security risk. In #2, for example, the link editor allows people to see the database names of *all* the virtual hosts. Also, if one ends up choosing unsightly but descriptive names like host_xe_nielsmayer_dot_com, users shouldn't need to see it. Niels http://nielsmayer.com

16 years, 7 months

2
1
0 0

[xwiki-devs] Setting and saving Object properties

by Vivian Richard

Hello, I would greatly appreciate a little clarification clarification on the following two points regarding objects. 1. In current wiki page if I access an object attached to a different page and then sets it's value, how do I save the property values programmatically? Apparently the new property values appear in the object view of the corresponding page but a database search does not show the new values unless I manually save the page (to which the object is attached). 2. In current wiki page I created a couple of objects and then set the property values. $doc.save saves the objects but seemingly has some interesting limitations. Number of property values it can save is limited. Say for example: if I have 12 properties and their values set, $doc.save works say, for example, after 6 of those property values are set. If I put $doc.save after one additional obj.set statement it gives error. I also found $doc.save to be dependent on string length of the property values. If string lengths are small it can save , for example, 13 properties. In such cases, again, manual save works fine (although I want to avoid that). A solution/workaround with a little code example will be greatly appreciated..... Thanks

16 years, 7 months

1
1
0 0

[xwiki-devs] listing pages with a keyword in their title

by WILSON Scott

Hi, I need to create a page that lists all of the pages in the wiki with a keyword in its title. For example: List all pages with the phrase 'Class_' in the title. It is important it is only the title that is searched - the body of the pages may contain lots of mentions of 'Class_' but we don't want those returned I found threads that almost answer this but none that get me 100% of the way so... How do I do this? Many thanks, Scott ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender.

16 years, 7 months

2
2
0 0

[xwiki-devs] [Proposal] Use livevalidation.js for client-side validation

by Jerome Velociter

Dear devs, I propose we bundle the "validation as you type" livevalidation.js library [1] in XWiki, and use it to improve user experience on several forms in XWiki Enterprise (I can think of registration form, export wiki form, page creation panel, etc.) There are several advantages I see in livevalidation compared to the other libraries I took a glance at : * It's small (12Kb minified) * It does not have any dependency (but there is version based on prototype available, too) * It is not intrusive. No need to modify the html structure or to add css classes to input fields to add validation. * It has an nice feature which allows you to precise the delay after which the validation should occur once the user stopped typing If you want to see it "live" in XWiki, I added some basic presence, password confirm and email validation on the register form on http://incubator.myxwiki.org CSS-class based validation seems to be in some sort of fashion, though I'm personally not very convince we can express all our validation using only class names (sounds intricate to do cross-field validation for example, or to validate against a custom regular expression), and for us it is not really an option right now, since we would need to make modifications in the core of XWiki for object fields displayer to add the proper class names to the inputs when calling APIs like $doc.display (or do it in javascript, but the CSS-based becomes pointless then). Last, if we really want class based validation, I believe building it with prototype and livevalidation would be very easy. Here are the other alternative I looked at rapidly: * JS-Validate [2] 67 Kb, requires prototype + scriptaculous, CSS-based , licence? * really-easy-field-validation [3] requires prototype, CSS + JS based, MIT licence * wForms [4] 81Kb minified, CSS-based , LGPL Better alternatives you would see? Otherwise, my +1 for livevalidation, Regards, Jerome. [1] http://www.livevalidation.com/ [2] http://www.jsvalidate.com/ [3] http://tetlaw.id.au/view/javascript/really-easy-field-validation [4] http://code.google.com/p/wforms/

16 years, 7 months

2
4
0 0

[xwiki-devs] [VOTE] Support spaces before any "standalone block" syntax

by Thomas Mortagne

Hi dev, We decided that spaces are meaningfull in XWiki 2.0 syntax with some exception for lisibilities issue for lists and headers. With embedded documents, the need for this appear for almost all standalone blocks (tables, macros, etc.). For example in: * list item 1 ((( | cell1 | cell2 ))) * list item 2 the table will not be recognized because of the spaces before the "|" that make the parser think it's a "|" in a paragraph and not a table. We could add another exception for tables lke lists and header but I would prefer to define a rule about all kind of standalone blocks. WDYT ? Here is my +1 -- Thomas Mortagne

16 years, 7 months

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs