xwiki-devs June 2007

xwiki-devs@xwiki.org

31 participants
65 discussions

by OliverT

Hello, Is there a way to add meta-attributes to a class ? Like BeforeAfterMetaclasses approaches or hooks. The underlying use case is to synchronize XWiki objects with a backend repository. A typical approach is to have the following attributes automatically changed or incremented on object change : lastmodificationdate, lastsynchronization, uptodateSequenceNumber, highwatermark... Or do you see another way for synchronization ? Thanks ! Oliver -- View this message in context: http://www.nabble.com/Changing-BaseClass-to-put-metadatas---tf3946533.html#… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 6 months

[VOTE] Switch to JDK 1.5

by Vincent Massol

Hi, I think it's time to officially decide if we want to standardize on 1.5. Some reasons we may want to do this: * JDK 1.4 is old. 1.5 is mainstream. 1.6 is about to be released. * Most libraries have now switched to 1.5 and it's going to be real hard to stay on 1.4 if we want to get bug fixes/new features from the libraries we use * Radu needs to use some google jars for his GSOC and they seem to require JDK 1.5 * We already require 1.5 I believe (although it's a light dependency) and have been requiring 1.5 for now several months (> 5 months) and we haven't heard complaints from users about this The vote is about officially dropping support for 1.4 and standardizing on 1.5 (and thus allowing us to use the new features of the language too like generics, annotations, etc). Here's my +1 Please cast your votes. Thanks -Vincent

17 years, 6 months

LDAP fix

by dennis.carroll＠dot.state.mn.us

There is a fix (http://jira.xwiki.org/jira/secure/attachment/11161/LDAPAuthServiceImpl-r334…) for http://jira.xwiki.org/jira/browse/XWIKI-238 (1.0 r 3342) to let a user with mixed case username in LDAP login with all lower case. I do not see how to attach file to this so I attached the patch to http://jira.xwiki.org/jira/browse/XWIKI-238. I have tested by adding a DB user both before and after deploying the change. Regards, Dennis

17 years, 6 months

[Fwd: Re: [xwiki-dev] Regarding issue XWIKI-523 (Tags should be shown with comments and attachments)]

by Thomas Drevon

Hi! I never got an answer to this email. Did I miss a point in some way? Were my comments not what you guys actually asked for? Maybe I should add the suggestions and the screenshots to the jira issue XWIKI-523? Anyway, I'll be offline for a month now, so I won't have the chance to follow up on the discussion. I hope all you devoted developers also get the break you want or deserve this summer; you're doing an impressive job on xwiki! best regards :-) Thomas -------- Original Message -------- Subject: Re: [xwiki-dev] Regarding issue XWIKI-523 (Tags should be shown with comments and attachments) Date: Mon, 11 Jun 2007 11:45:28 +0200 From: Thomas Drevon <thomas.drevon(a)intermedia.uio.no> Reply-To: thomas.drevon(a)intermedia.uio.no To: xwiki-dev(a)objectweb.org References: <4665547D.4040408(a)intermedia.uio.no> <C7BC95C2-AF6F-4F77-94E8-D615340B188C(a)massol.net> Vincent Massol wrote: > > Here's how we could work together: you send some emails on the list, > maybe with some GUI mockups about how you think tags should be > integrated. You'll get lots of feedbacks I'm sure, especially if you > show something in a mockup (people love images ;-)). Then you start > sending some emails about how you think it should be done and committers > will comment, tell you if there's a better way. And you can ask for any > question you have along the way. > > WDYT? Sure! Ok here we go: 1. View tags along with a document. It doesn't really matter what kind of document, but for this example I've used a blog entry. See the attached file called blog_entry_view.png. In order to achieve this, just add the following lines to an appropriate place in XWiki.ArticleClassSheet: <code> Tags: #foreach($tag in $doc.getTagList()) <a href="$xwiki.getURL("Main.Tags", "view", "tag=$tag")")">$tag</a> #end </code> This code is tested and works fine. Problem: On docs without a template sheet, this gets a bit more messy, as it seems the above code must be added directly to content.vm. Maybe all docs should inherit from some sort of generic template sheet? This will give users more flexibility by sparing them the messing up of velocity files, and thus making an upgrade of their xwiki version harder. And by the way, is it correct that while viewing this doc, the breadcrumbs read "BLOG: Administration > Samarkand" even though I'm not logged in? "Administration" here seems a bit strange? 2. Intuitive edit of tags while in edit mode. See the attached file called blog_entry_edit.png. In order to achieve this, add the following lines to the correct place in XWiki.ArticleClassSheet: <code> <dt>Tags:</dt> <dd><input type="text" id="tags" name="tags" size="60" value="$!tdoc.tags"/></dd> </code> Though this code produces a nice input field as expected, tags entered here will not be saved along with the doc, unless the servlet engine is restarted between the creation of the docs and the editing of tags. Strange. Well, what do you think? Oh yes, and I'm all for letting users turn on/off the tag functionality in xwiki.cfg, by the way. cheers :-) Thomas

17 years, 6 months

[ArchitectureV2] Model proposal

by Vincent Massol

Hi, Starting from today I'm going to spend some time every week on the V2 Architecture/Redesign. Today I'd like to start at the heart of the topic with the domain model. Here's my proposal: * Model classes are classes representing the XWiki model. The main classes are: - Farm - Wiki - Space - Document - XObject - XClass - (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API) WDYT? Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome. Thanks -Vincent

17 years, 6 months

Trouble with refresh after update from xmlrpc

by Thomas Drevon

Hi! We're experimenting with xmlprc calls to xwiki (using code from http://www.xwiki.org/xwiki/bin/view/UserGuide/XMLRPCExample), and are encountering some strange behaviour: A newly created document will appear directly in xwiki as expected. However, when we update this newly created doc the database is updated, but when we view the page in xwiki, we still see the old doc. If a restart of tomcat is done, the updated doc appears as expected. It seems as if xwiki is sticking more closely to it's cached verion of what's in the database than what we would prefer. And it looks very similar to what I discovered while editing tags on blog entries. Is this behaviour considered a bug? Is there any code that can be invoke in order to re-read the object in question from the database? Once again, any help would be greatly appreciated. cheers :-) Thomas

17 years, 6 months

XWiki-Eclipse plug-in

by tharindu jayasuriya

Hi all, Here I have attached some mock GUIs and a very intuitive requirements spec that illustrate the basic workings of XWiki-Eclipse plug-in. It's better if we can finalize these drafts soon because I need to go on with the development :). I have few doubts on the java package structure as well as about the icon graphics for the plug-in (i thought of re-using eclipse's ones where suitable). I went through XWiki XML RPC APIs and am comfortable with thw way they work (had to sharpen my SWT skills too). I'm looking forward to hear from you.. - Tharindu

17 years, 6 months

Escaping velocity code inside form fields does not work properly on xwiki.org

by Catalin Hritcu

Hi, Escaping velocity code inside form fields does not work properly on xwiki.org. For example any of the following alternatives cause an error when entered inside a form field (but causes no problem when the same text is entered inside the body of a normal document): \#set(\$myfeed=\$xwiki.feed.getFeed(\$feedUrl)) {code} \#set(\$myfeed=\$xwiki.feed.getFeed(\$feedUrl)) {code} #literal() #set($myfeed=$xwiki.feed.getFeed($feedUrl)) #end Surprisingly a third (old) way to do it works, even in form fields: {code} #\set($\myfeed=$\xwiki.feed.getFeed($\feedUrl)) {code} I was not able to reproduce this problem on my local installation of XWiki, however on xwiki.org there are many pages that are affected by this bug: http://www.xwiki.org/xwiki/bin/view/FAQ/HowToListDocumentsWithACertainPrope… http://www.xwiki.org/xwiki/bin/view/FAQ/HowCanIescapeOutQuotationMarksFromA… http://www.xwiki.org/xwiki/bin/view/FAQ/HowDoIFindTheBacklinksForAGivenPage http://www.xwiki.org/xwiki/bin/view/FAQ/HowDoIEmbedXwikiCodeAsText http://www.xwiki.org/xwiki/bin/view/FAQ/HowToSetWebPreferences http://www.xwiki.org/xwiki/bin/view/FAQ/HowDoIIntegrateAnRSSFeedWithinAPage http://www.xwiki.org/xwiki/bin/view/FAQ/PrepopulateQuestionFieldOnFAQClassS… Does any of you have an idea on what might cause this? Regards, Catalin

17 years, 6 months

Feature Request: Maximize edit window

by shivshan

Hi In Albatross skin, by default, the edit window is quite small. A big part of the screen real estate is taken up by the XWiki Document information panel on the right, the header and footer. Some wiki's have a feature by which the editor can be popped into a seperate window which can be maximised. Some others let you increase the editor area as much as you want. This would make edits of larger pages much easier, and you can focus on editing the document rather than scroll continuosly up and down. I had posted a screen shot of this problem sometime back. How easy is it to make this change? And is the popup editor feasible with XWiki architecture? Thanks Shiva -- View this message in context: http://www.nabble.com/Feature-Request%3A-Maximize-edit-window-tf3913467.htm… Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 6 months

[Proposal] New generic Action for calling an API and returning the result as XML

by Vincent Massol

Hi, I'm writing a treeview (using the yahoo treeview javascript api) to display the list of all pages of a wiki and in order to have good performances I need to call a server-side method for getting all children pages of a given page (so that the nodes or the treeview are loaded dynamically). In order to implement this I thus need a new XWiki Action. Now I think it would be good to generalize this common need. As we add more Ajax to our UIs we'll need more and more calls from JS to the server side. I'm thus proposing a generic ExecuteXMLAction (or AjaxAction or another name) that would do the following: * Get the class, method and parameter to execute from the HTTP request * Verify that the class is in the api package (to prevent security issues) * Call the method using introspection * Return the result as XML using XStream (it generates automatically XML from any java object) Note: I'd need to define the format for sending the information in the request. Not sure about which format to use. WDYT? Thanks -Vincent

17 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2007