xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

Start a nNew thread

Job and internship opportunities at ENST to work on XWiki

by Samuel Tardieu

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

17 years, 7 months

[Proposal] Create a new XWiki Flavors subproject on JIRA

by Sergiu Dumitriu

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

17 years, 7 months

[Proposal] Powered by XWiki logo

by Vincent Massol

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

17 years, 7 months

Google Docs API Developer Documentation

by Radu Danciu

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

17 years, 7 months

[Proposal] Better handling of patches

by Vincent Massol

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

17 years, 7 months

[ArchitectureV2] UI Interfaces

by Vincent Massol

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

17 years, 7 months

Czech localization

by kinslayer

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.

17 years, 7 months

I18N patch for "Allowing non ascii chars in document names and URLs" (XWIKI-951)

by Vincent Massol

Hi Gilles, I have commented on http://jira.xwiki.org/jira/browse/XWIKI-951. Could you please let me know if it's ok to apply your patch as is or if you still need to submit and updated version of it. Thanks -Vincent

17 years, 7 months

Trying to understand I8N...

by Vincent Massol

Hi, I admit it: I'm not an expert in I8N. However I realize that XWiki being a wiki we need to have strong I8N features so I'm trying to catch up with I8N knowledge... I started yesterday by reading this excellent short tutorial http:// www.joelonsoftware.com/articles/Unicode.html (The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)). It's very good and an easy read. I recommend it to everyone. This led me to a few questions: 1) Is UTF8 supported on all platforms? Is it supported on mobile platforms for example? 2) I see in our encoding guide on http://www.xwiki.org/xwiki/bin/view/ AdminGuide/Encoding that we need to set the encoding for the container. Why is that required? The servlet container reads pages which have the encoding specified (using Content-Type meta data), so why does it need to be told about the encoding to use? 3) I see that in our standalone installation we use - Dfile.encoding=iso-8859-1. Now that I've read Joel's tutorial it seems to me this is not going to work for everyone and that we should rather use -Dfile.encoding=UTF-8 by default. WDYT? 4) Should we use the platform encoding or default to using UTF-8 all the time? (this question is related to 1)). I think we should use the platform encoding but I'm curious to know what others think. 5) Jackson Wang is proposing in a patch to modify readPackage like this: private Document readPackage(InputStream is) throws IOException, DocumentException { - byte[] data = new byte[4096]; + //UTF-8 characters could cause encoding as continued bytes over 4096 boundary, + // so change byte to char. ---Jackson + char[] data = new char[4096]; + BufferedReader in= new BufferedReader(new InputStreamReader (is)); StringBuffer XmlFile = new StringBuffer(); int Cnt; - while ((Cnt = is.read(data, 0, 4096)) != -1) { + while ((Cnt = in.read(data, 0, 4096)) != -1) { XmlFile.append(new String(data, 0, Cnt)); - } + } return fromXml(XmlFile.toString()); } However with my new understanding I'm not sure this would help as char are stored on 2 bytes in Java and UTF-8 encoding can store on up to 4 bytes. Am I correct? However, I would rather use http://jakarta.apache.org/commons/io/api- release/org/apache/commons/io/IOUtils.html#toString (java.io.InputStream) than code it ourselves... Sounds safer, shorter, less maintenance, etc to me... :) Thanks for your help -Vincent

17 years, 7 months

Reorganization the documentation content on XWiki.org

by Guillaume Lerouge

I am currently working on improving the documentation about the default XWiki on XWiki.org. In the process, a lot of information is added, but Vincent pointed out to me that this information is sometimes related to the default behavior of any XWiki (eg, "a page is edited when clicking on the "edit" button) and at some other times related to a particular XWiki (eg, "the search page looks like this if you are using the XWiki 1.0 B6 XAR"). The problem lies in the fact that a new user might get confused when accessing the documentation and not be able to distinguish between necessary features (which are included in XWiki's core, hence present on every XWiki) and contingent features (which depend on the XAR used for instance). It would be useful to find a solution in order to separate the different kinds of documentation on XWiki.org. In the process, it might be necessary to keep in mind that we could someday release different XARs aiming at different purposes ("XWiki for developers", "XWiki for architects", ...) with a new release of the core. There are different types of potential solutions to this: - Creating badges saying "this refers to the default XWiki instance / XWiki 1.0B5 Xar / Another XAR only" and placing it where needed; - Creating an entirely different section to document features present only on a specific XWiki instance / xar; - Another type of solution - original input welcome :-) And then the whole thing needs to be clear and easy to browse for users seeking for a specific piece of information... Any suggestions? Guillaume -- http://wikibc.blogspot.com/

17 years, 7 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs