xwiki-devs October 2009

xwiki-devs@xwiki.org

43 participants
147 discussions

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

9 years, 10 months

[xwiki-devs] Redirect to a space

by Bruno Amaro Almeida

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

11 years, 6 months

[xwiki-devs] Pretty Time library

by Vincent Massol

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

12 years, 5 months

[xwiki-devs] How to load GWT application on Xwiki pages?

by Leon Wang

Hi Everyone! I have read this document "Writing GWT applications in XWiki" ( http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki) And I know how to develop GWT module for xwiki now. I also have read the document "WYSIWYG Editor Module" ( http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule). I followed the instruction which tried to integrate the WYSIWYG editor(GWT application) in wiki pages, and I put the following code in my wiki editor: "{{html}} <script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is loaded!'); </script> <textarea id="demo"></textarea> <script type="text/javascript"> Wysiwyg.onModuleLoad(function() { new WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); }); Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId: 'demo'}); }); }); </script> {{/html}}" After saved, it only display a blank text area without any sign of WYSIWYG editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help me figure it out what is wrong with it? I am planing to develop a tree view using GWT to display Design Rationale Element. Could you give me some ideas of after my development, how can I embeded the GWT application into Xwiki pages and interact with the GWT application? Thank you very much! Leon

13 years

[xwiki-devs] [PROPOSAL] Rendering l10n

by Thomas Mortagne

Hi devs, We need to support some way internationalization of everything in the rendering that appear in the UI, for now it's mainly related to macros. What I propose is to introduce the rule that any displayable String returned by the API (MacroDescriptor#getName, ParameterDescriptor#getDescription, etc.) could be a l10n key. Then the API user call the l10n component to get the final String. pros: - no need to touch the current API - it avoid having complex API to support l10n specifics and makes pretty much everything depends on l10n component. It's easier for macro author to write a quick macro with some description without having to create l10n resource and call the l10n component just for english for example. - the displayer can control how to get actual translations the way it wants - we need something like that for wiki macros anyway: XWiki does not support translations of objects yet (and for long I guess since the issue is at database level) and it would be a pain to have to copy the content of the macro by language since most of the time the script of the macro would not be related to the language cons: - it's more work for the API user to filter the String with the l10n component to get the actual final String One detail I'm not sure of is if we introduce some syntax to explicitly indicate it's a l10n key or if we just always give the String to the l10n component which will return it as it is if it can't find any matching key. Having an explicit way to indicate a String is a key would be better to track l10n keys bugs but introduce a syntax is always more complex (what chars to choose, how to escape, etc...). WDYT ? Thanks, -- Thomas Mortagne

14 years, 8 months

[xwiki-devs] [Proposal] XWiki.org horizontal navigation + home page

by Vincent Massol

Hi there, I'd like to start a overhaul of the xwiki.org home page + a first level navigation overhaul. Today: * Home page = list the different products * First level nav = the ecosystem panel Problems: * We now have a single product: XE and all the others are actually modules that plugin into the main products. Hence we shouldn't focus on other products so much IMO. * I'd like to view xwiki.org as a forge of projects. Today our top level projects are the ones listed here: http://svn.xwiki.org/svnroot/xwiki/ * The main page should be more dynamic and show some news and activity instead of being static * People are confused by the top level navigation vs the second level one because they both use panels and it's not easy to differentiate them Proposal: * Use a horizontal top level navigation with the following items (from left to right): - Overview or Home (the main page) - Platform - Projects (when clicked will list all top level projects) - We could have the list of subproject available as submenu items too (as it's done on http://jboss.org/) - Support (when clicked will explain the various ways to get support including mailing list/forum, irc/jabber, FAQ & listing companies offering commercial support) - Contribute or Community (when clicked we'll get dev.xwiki.org) - Playground This means that the panels on the right will become the second level navigation and the content will depend completely on where you are on the site. * Have some facilities links in the header on the right: - News - Downloads (as a visible button maybe) * On the home page: - Have a nice diagram of the xwiki platform that shows how XE, XE modules are positioned on the platform so that people understand right away that xwiki is a collaborative web dev platform - Have a Highlight box with XE so that users looking for a full- fledged wiki can quickly see it and click on it + maybe one featured screenshot of an entry from the References page that would be different every time the page is refreshed (this could encourage people to add references + provide a link to the references directly) - Have a Featured project box and list 3-4 featured projects (XE, XEM, XEclipse, XOffice for ex to start with) - Have some news: -- latest 5 blog post titles -- latest 5 code zone additions (all snippet, plugins, macro, apps, etc included) -- latest 5 mailing list threads subjects (with links to our nabble forum) We could not have any second level navigation for the home page in order to have more space for displaying the elements above. WDYT? If/when we're ok in term of content maybe Cati (or anyone interested) could provide some mockups of what it could look like. Thanks -Vincent PS: Let's not get bogged down with details at this point. I think what's important is to make progress and refine later on. What's important is that we agree on the broad lines at this stage.

14 years, 9 months

[xwiki-devs] [Proposal] Script Bridge

by Vincent Massol

Hi, This is following the proposal done here some time ago: http://markmail.org/message/nnybto3mluvp2rov Since we now have a generic Script notion we need to revisit it in that light. Also we really need to implement it now since more and more components are put in the velocity context (office importer, syntax factory, etc) and we need to bring some order. Here's a new generic proposal: Short term ======== * The variable "services" is bound in the script context. For ex in Velocity: $services * The Services object (ScriptServiceManager) has a ScriptService get(String serviceName) method which returns the service * We use the namespace: services.<module name>.<method>. Each module provides only one service entry point. * ScriptService interface (empty interface) represents a service to be bound in the context * ScriptServiceManager.get() looks for all components of role ScriptService and returns the component matching the the name as the component hint. Ex: @Component("mymodule") public class MyModuleScriptService implements ScriptService, MyModuleBusinessInterface { public void myMethod() {} } In script: {{velocity}} $services.mymodule.myMethod {{/velocity}} Medium term ========== * We handle @authorization(Authorization.PROGRAMMING) annotations to check for access rights. To do this in ScriptServiceManager.get() we use a Dynamic Proxy to implement MyModuleBusinessInterface (we probably need a ScriptService.getInterface() method to make it unambiguous). The Dynamic Proxy checks the annotation before proxying to the real object. WDYT? Thanks -Vincent PS: This is to answer Sergiu's question about where is getAvailableParserSyntaxes() from my other mail... ;) Answer: It would be in RenderingScriptService.

14 years, 10 months

[xwiki-devs] [Proposal] [GSOC] Wiki Importer Enhancement

by Arun Reddy

Hi Devs, As the existing Wiki Importer ( GSOC PROJECT - SANDBOX <http://svn.xwiki.org/svnroot/xwiki/sandbox/gsoc/importexport/>) have few set backs in architecture, i would like to make a proposal to modify and enhance to make it better. Here is my proposal : http://gsoc.myxwiki.org/xwiki/bin/view/Import+Export+other+wikis/Wiki+Impor… - A new Wiki model api ( Wiki, Wiki Page, Wiki Page Revision, Wiki Attachment ) which adheres to XWiki Standards. - Separation of Import process, Parsing the import data into a abstract wiki model will be a component. Clients can use it to make their own custom implementation. This abstract model is used by the other XWiki component / client code (Groovy & velocity ) to load the data into XWiki with standard features and little customization (like Preserving history, default names, attachments etc.. ). - Using the existing XWiki model api or xwiki-bridge rather than coming up with a new one. But the issues here is, i dont have all the things which are needed and it has lot more methods which are of no use in import process. Can i proceed with a custom wiki model like this. ? - As wiki importer process large streams of data, would it be wise to design the API more stream oriented and include few stream oriented methods.? I would like to have your suggestions on this. Thanks -Arun Reddy

14 years, 11 months

[xwiki-devs] [VOTE] Strategy for handling translations

by Vincent Massol

Hi devs, We need to define a strategy for better handling translations. I've had a call with Guillaume and Jean-Vincent and here's the process we'd like to propose: * One person is in charge of http://l10n.xwiki.org/. This means monitoring the work there, coordinating validation of key values and ensuring validated translations are incorporated in the source tree. Guillaume is willing to take that role for now. * The XE release manager has the responsibility of taking the validated keys on l10n.xwiki.org and committing them during the Milestone 2 dev (before the RC1). * The l10n manager should ping the release manager whenever there are translated and validated keys ready to be incorporated or if there have been important changes to be included in the release after M2 has been released. * The l10n manager should test XE and the applications after the keys have been applied to ensure quality. Basically the l10n manager is responsible for the quality of translations in general. Here's my +1 Thanks -Vincent

14 years, 11 months

[xwiki-devs] OfficeImporter API changes - Take 2

by Asiri Rathnayake

Hello Devs, After few discussions I have revised the new officeimporter API to take into account the use of DocumentName instead of plain strings for representing document names. I'll repeat the details of the previous proposal with the new changes applied: Currently we have the following officeimporter API: <code> OfficeImporter::importStream(InputStream is, String documentFormat, String targetDocumentName, Map params):void OfficeImporter::importAttachment(String documentName, String attachmentName, Map params):String </code> Problems with this API: * Loosely typed (params, document names) * Both of the above methods perform almost the same task. * Customizing the import process is implemented in a hackish way. (not visisble on the API) The new API proposed looks like below: <code> OfficeImporter::officeToXHTML(byte[] officeFileData, DocumentName referenceDocument, boolean filterStyles):XHTMLOfficeDocument OfficeImporter::xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument):XDOMOfficeDocument OfficeImporter::officeToXDOM(byte[] officeFileData, DocumentName referenceDocument, boolean filterStyles):XDOMOfficeDocument OfficeImporter::buildPresentation(byte[] officeFileData):XDOMOfficeDocument OfficeImporter::splitImport(XDOMOfficeDocument xdomOfficeDocument, int[] headingLevelsToSplit, NamingCriterion namingCriterion, DocumentName baseDocumentName):Map<TargetPageDescriptor, XDOMOfficeDocument> </code> As you can see, these methods are more granular and the responsibilities are well defined. Customizing the import process can be done from the client code. For an example: 1. Make the initial import from office to XHTMLOfficeDocument - OfficeImporter::officeToXHTML() 2. Perform customizations on the XHTMLOfficeDocument - w3c DOM manipulations. 3. Import the XHTMLOfficeDocument into XDOMOfficeDocument - OfficeImporter::xhtmlToXDOM() 4. Perform customizations on the XDOMOfficeDocument (XDOM) - XDOM manipulations. 5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances - OfficeImporter::splitImport() 6. Perform customizations on these child XDOMOfficeDocument instances - XDOM manipulations. 7. Render the XDOMOfficeDocument instances & save them into wiki pages - XWiki rendering operations. I think this interface will make it easy to extend & maintain officeimporter functionality in the future. Along with this, I would also like to refactor the xwiki-refactoring module a bit to get rid of string based document names from it. This whole refactoring operation would take approximately one day to complete. And since this operation is not adding any new features, I think it can be committed on both trunk and 2.0 branch. Here's my +1 to all of above. Thanks. - Asiri

15 years

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 October 2009