April 2007 - xwiki-devs@xwiki.org

Re: [xwiki-commits] r2810 - in xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki: doc plugin/lucene
by Vincent Massol 15 Apr '07

15 Apr '07

On Apr 15, 2007, at 2:47 AM, Ludovic Dubost wrote: > Author: ludovic > Date: 2007-04-15 02:47:42 +0200 (Sun, 15 Apr 2007) > New Revision: 2810 > > Modified: > xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/doc/ > XWikiDocument.java > xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/plugin/ > lucene/IndexUpdater.java > Log: > XWIKI-966 Fix lucene indexing not correctly deleting and reindexing > in some cases Should jira issue XWIKI-966 be closed or is there something remaining? Thanks -Vincent

1 0

Re: [xwiki-commits] r2809 - in xwiki/trunk/core/src/main/java/com/xpn/xwiki: doc plugin/lucene
by Vincent Massol 15 Apr '07

15 Apr '07

On Apr 15, 2007, at 2:43 AM, Ludovic Dubost wrote: > Author: ludovic > Date: 2007-04-15 02:43:21 +0200 (Sun, 15 Apr 2007) > New Revision: 2809 > > Modified: > xwiki/trunk/core/src/main/java/com/xpn/xwiki/doc/XWikiDocument.java > xwiki/trunk/core/src/main/java/com/xpn/xwiki/plugin/lucene/ > IndexUpdater.java > Log: > XWIKI-966 Fix lucene indexing not correctly deleting and reindexing > in some cases > XWIKI-21 Fix rename regression using copydocument which does not > clean up the attachment list before copying the source attachment list [snip] You can't do that as XWIKI-21 is already closed and released as part of XWiki 1.0 Beta 6.... So this fix won't show up in the release notes of RC1... I've created XWIKI-1085 for this but I need your help to describe the problem from a user point view. I need the answer to: "what happens when a user renames a document with attachments?". Thanks -Vincent

1 0

[Proposal] Use XClass, XObject, XProperty to name the XWiki concepts
by Sergiu Dumitriu 14 Apr '07

14 Apr '07

Hi, Sometimes it's hard to make the distinction (in a conversation) between XWiki classes/objects/properties and the java terms. Thus, we should call them XClass, XObject and XProperty. Of course, class/object/property are still valid, when everybody knows what we're talking about. Sergiu -- http://purl.org/net/sergiu

4 4

Job and internship opportunities at ENST to work on XWiki
by Samuel Tardieu 13 Apr '07

13 Apr '07

See http://tinyurl.com/372zuo for more info. Sam -- Samuel Tardieu -- sam(a)rfc1149.net -- http://www.rfc1149.net/

1 0

[Proposal] Create a new XWiki Flavors subproject on JIRA
by Sergiu Dumitriu 13 Apr '07

13 Apr '07

Hi, I'd like to propose a new subproject on JIRA, called XWiki Flavors. What is a Flavor? A flavor is a custom XWiki-based site, with one specific goal in mind. The XPN team creates such flavors when working for client project. As it is said on http://jira.xwiki.org/jira/browse/XWIKI-356 , by default XWiki comes with a collection of pages, panels, classes, a pre-selected skin, etc, which gives it a "flavor". Right now, it looks like a nice site where you can put some pages (content), articles, documentation, etc. It is a weak flavor, since it's a mixture of different ingredients put all together. An example of a "strong" flavor is a blog-wiki. When you install XWiki and choose the blog-flavor, you will get the full functionality of any blog app (for example blogger or wordpress) without having to customize anything, without having to import one or several xar-s, editing the main page or anything. Of course, after the user gets used to the blog (and XWiki) he can customize the skin (using a friendly skin browser and a skin wizard), the displayed panels (using the panel wizard), and many other things (actually anything a user can change in XWiki, which is everything). Other strong flavors could be content management, OpenSource project website (about, developer guide, user guide, download, ...), or just the documentation for such a project (many projects use wikis now), Social Networking site (link and photo sharing, tagging, reviews), project management, and so many more. Why are flavors necessary? Because XWiki is too powerful. Put it in the hands of some who-knows-what "haskel model checker" developer who only knows about axioms, theorems, proving, model checking and functional programming, and he will run away very fast to a simple wiki engine, or worse, a CMS. But hide all the power behind a simple interface, with only what he needs in order to publish some info about his project, and we have a happy XWiki user. Why do we need a new subproject? Because: - putting all the flavor-specific issues in the "Default database" component is not efficient - neither is putting them in a new "Flavors" component - we don't know how many flavors we will create, so making an XWiki component for each flavor will bloat the component list - flavors don't follow the XWiki platform release plan; they get shipped when they are ready What is the relation between flavors, default database, and xwiki-applications? The default database should be almost empty. It should contain mainly the setup wizard, which can be used to install a flavor. A flavor contains some applications bundled together. It is not enough to put only the individual applications in JIRA, because a flavor is more than that: a custom skin, configuration for the applications, rights setup, other documents outside of applications, java plugins, XWiki configuration, and even more. What should the subproject contain? First, a "global" component, regarding flavor development, deployment, integration, installation. Then a component for each flavor we are currently supporting (or starting to work on). WDYT? Sergiu -- http://purl.org/net/sergiu

2 2

[Proposal] Powered by XWiki logo
by Vincent Massol 13 Apr '07

13 Apr '07

Hi, I think it's high time we get a powered by XWiki logo! :) Laurent Lunati has created 5 variations attached. Does anyone have any feedback in term of size, color, look, etc? The idea is that once we get an agreement on the logo we publish it on xwiki.org and we ask that people using XWiki display this badge on their web site if they want to be good open source citizens :) (and thus we'll also use it on xwiki.org itself). My preference goes to the 80X15.png logo. What about you? Thanks -Vincent

8 10

Google Docs API Developer Documentation
by Radu Danciu 12 Apr '07

12 Apr '07

Does anybody have any hint on where I might get some Google Docs API Developer documentation? (tried google already, nothing relevant came up for several well thought search strings). Thanks in advance, Radu Danciu

2 1

[Proposal] Better handling of patches
by Vincent Massol 12 Apr '07

12 Apr '07

Hi XWiki committers, We need to better handle patch contributions. It's really important that when someone submits a patch we review it quickly and apply it or ask for modifications. Providing a fast answer means that we'll get more contributions and XWiki will soar even higher... Right now we're doing a poor job at handling patches. The first step in improving is in detecting issues with patches. I have thus started tagging issues with patches with "patch" in the keyword field. I propose that we all do this whenever we see an issue with a patch attached. I have also modified the default JIRA dashboard on http:// jira.xwiki.org/ so that the list of issues with patches attached are listed in the right column. If you agree I propose we make it our priority to review and fix issues with patches attached. WDYT? Thanks -Vincent

3 3

[ArchitectureV2] UI Interfaces
by Vincent Massol 12 Apr '07

12 Apr '07

Hi, I'd like to propose the following general principles for the V2 Architecture (http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2) 1) Components can contribute user interface elements. 2) They contribute them through a Java interface. 3) There's one Java interface for each UI contribution (located in a ui package). <example - I'm not asking to vote on this, it's just an example to better visualize what "one Java Interface for each UI contribution" means> For example, we have one interface for contributing Admin Pages (the tabs we have in the administration page when using the albatross skin). For example: public interface org.xwiki.core.ui.AdministrationPage { Page getPage(Context context); } where: Page will return the page's content (the implementation could have a "String getContent()" method, and some other fields, like a page id, etc). The context will contain useful information for returning the page. One interesting information is the skin name if some component want to return a content that is optimized for a given skin The page content could be stored as *.vm file in the component JAR. The returned content is content that has NOT been processed by any renderer. We do not want to make these component renderer-aware as rendering should be done in a centralized manner elsewhere. The content returned by getPage must not be styled at all. It should try to return only Wiki Markup. When this is not possible it should follow general convention that we'll need to publish as an API for HTML class ids for example. </example> 4) There are Java UI Interfaces for skins. These are interfaces used by skins. <example> Continuing the example above we could have the following: public interface org.xwiki.core.ui.skin.AdministrationServices { List getPages(...); } And the component implementing this interface would query the component manager to get all components implementing the org.xwiki.core.ui.AdministrationPage interface, which would be returned as an output of getPages(). Then a skin implementation (*.vm files for example, or JSP pages, or...) would call getPages() to lay out all the administration pages, whether as a tabbed interface or on different physical pages, etc. </example> <example> Another example to illustrate this is the Import/Export feature. This could be packaged as a single component which would implement several interfaces, among which this AdministrationPage interface and provide the content for the import and export pages. </example> WDYT? After we discuss this and once we agree on it, I'll publish the results on http://www.xwiki.org/xwiki/bin/view/Idea/ArchitectureV2 Thanks -Vincent

5 19

Czech localization
by kinslayer 11 Apr '07

11 Apr '07

Hi, I like to create Czech localization of Xwiki. I found that some localization files are situated in xwiki.jar. ApplicationResources_en.properties, ApplicationResources_pl.properties, ApplicationResources_fr.properties etc. So when I create ApplicationResources_cz.properties, where can I config Xwiki to read locating words from this file? Thank you. Jan -- View this message in context: http://www.nabble.com/Czech-localization-tf3558570.html#a9936990 Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 1