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

by Chathura Prabuddha

Hai... I would like to apologize that I haven't communicate well during last few weeks. I need some feedback regarding the document type manager demo http://gsoc.myxwiki.org/xwiki/bin/view/DocTypeManagerDemo/ its still in the initial stage.Its just provide the basic sketch of the UI. Currently I'm creating the "Description" pannel. I'm trying to load the details of the documents of the left side in to the description form as a start and to create a class using the description pannel. But I'm still not clear about how to list the document types in the left side tree. Currently it loads the list of classes relevant to specific spaces.Is it ok to continue wiith the current UI. Hoping to catch up my work in next few weeks. Thank you.

16 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] Extension Manager

by Vincent Massol

Hi, We need to start working on the new module to install wiki pages, components, UI extensions, etc. I propose to call it Extension Manager instead of the Application Manager name we had used till now. If ok I'll rename the existing page at http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationManager Thanks -Vincent

16 years, 3 months

2
4
0 0

[xwiki-devs] [PROPOSAL] JSR223 (Scripting for the Java Platform) and XWiki context

by Thomas Mortagne

Hi devs, In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context). The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that. I can see several general rules: 1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext) 2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs. 3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity. There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding If think the best is 4) for now. WDYT ? -- Thomas Mortagne

16 years, 3 months

5
7
0 0

[xwiki-devs] [Wild Idea] Live Search

by Vincent Massol

Hi, I think the new search results page (the main search one not the lucene one) has some limitations that could be improved: - it doesn't scale with large number of documents (if you do a search that returns a lot of documents) - it doesn't allow refining your search easily - the information presented take up more vertical space than needed (currently 3 lines instead of one) and thus less results can be presented - it could be reused by other pages which require listing documents such as the SpaceIndex which lists all pages in a given space. It's actually currently reused but as a consequence the SpaceIndex page isn't nice at all and doesn't scale. Would it make sense to: - have a livetable - display all docs by default when you arrive on the search page (ie no filter set) - make the current search field a field bound to the livetable and that filters that table when text is typed inside - remove the need for the spaces combo box since it would be a filter field in the livetable already - same for the wiki field Pros: - all the limitations listed above are resolved - the search becomes live (that's a + compared to other solutions since I haven't seen other apps do this) - it unifies the way we use livetable across XE - if we do this we could also modify the AllDocs page to have the global search field. Basically wherever we display documents we could also include this search field. Main Question: - would the live search be costly? With Lucene search probably not, with the DB search, it could (for ex if document content isn't indexed). WDYT? Thanks -Vincent

16 years, 3 months

6
7
0 0

[xwiki-devs] [Rendering] Two ideas using Transformation

by Vincent Massol

Hi, Need 1: Be able to prevent some macros from execution in some contexts. For example in the comments field prevent usage of script and html macros Proposed solution: Use a Rendering Transformation with a high priority that removes (or that generate an error) those macros (the list of macros can be retrieved from a config file or from some execution context) Need 2: Ensure that renderers generate valid content (eg valid XHTML for the WYSIWYG editor). For example if the user uses the HTML macro and puts invalid HTML the WYSIWYG editor should still work Proposed solution: Use a Rendering Transformation with a low priority that traverses the XDOM to validate it (for example remove inline elements that are placed in a standalone context). WDYT? Thanks -Vincent

16 years, 3 months

3
3
0 0

[xwiki-devs] [VOTE] Logging rules

by Vincent Massol

Hi, We've already discussed this a long time ago but just want to raise the topic again and document it. Do we agree that: * info is used for logs that should be printed by default (default logging configuration) * logs that are informational but that shouldn't be printed by default should be debug logs * warnings are not critical problems but raised so that the users sees them and remedies the problem, shown by defaut too * error are critical problems that cause the application to misbehave and should most of the time have an associated stack trace As a consequence I'd like to modify the default log4.properties file so that info level logs are printed by default (at least for all org.xwiki.* code). Here's my +1 Thanks -Vincent

16 years, 3 months

3
3
0 0

[xwiki-devs] base url

by glenn_engel＠agilent.com

Is there a convenient way to obtain the base url? e.g. http://localhost:8080/xwiki or http://mysite.com -- Glenn

16 years, 3 months

3
2
0 0

[xwiki-devs] Please re-index XWiki.org website, search engine returns only release pages...

by Pascal Voitot

Thanks Pascal

16 years, 3 months

3
2
0 0

[xwiki-devs] Build now works with Maven 2.1.0 and 2.2.0

by Vincent Massol

Good news, I've fixed the issue we had with the GWT maven plugin anr our build nows works with Maven 2.1.0 and 2.2.0 Enjoy -Vincent

16 years, 3 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r21332 - in sandbox/xwiki-annotation/xwiki-application-annotation/src/main/resources: . Panels

by Jerome Velociter

Hi Lucien, see below lpereira (SVN) wrote: > Author: lpereira > Date: 2009-06-18 12:52:07 +0200 (Thu, 18 Jun 2009) > New Revision: 21332 > > Added: > sandbox/xwiki-annotation/xwiki-application-annotation/src/main/resources/Annotation.js > Modified: > sandbox/xwiki-annotation/xwiki-application-annotation/src/main/resources/Panels/AnnotationManager.xml > Log: > client side cleaning up. > > Added: sandbox/xwiki-annotation/xwiki-application-annotation/src/main/resources/Annotation.js > =================================================================== > --- sandbox/xwiki-annotation/xwiki-application-annotation/src/main/resources/Annotation.js (rev 0) > +++ sandbox/xwiki-annotation/xwiki-application-annotation/src/main/resources/Annotation.js 2009-06-18 10:52:07 UTC (rev 21332) > @@ -0,0 +1,472 @@ > > -function getLeftDocument(node, xwikicontent) > +function onDOMLoaded() > { > [snip] > + if(typeof(annotationFeatureEnabled) != 'undefined' && annotationFeatureEnabled == true) > + { > + annotation = new Annotation(); > + } > } > > [snip] > +document.observe('dom:loaded', function(event) {onDOMLoaded();});</code> You should namespace this function, or better, hide it as an anonymous callback function or in an anonymous scope, like : document.observe('dom:loaded', function(event) { if(typeof(annotationFeatureEnabled) != 'undefined' && annotationFeatureEnabled == true) { annotation = new Annotation(); } }); (annonymous callback), or : (function(){ function onDOMLoaded(){ if(typeof(annotationFeatureEnabled) != 'undefined' && annotationFeatureEnabled == true){ annotation = new Annotation(); } } document.observe('dom:loaded',onDOMLoaded);</code> })(); (named function in an anonymous scope) This way, if an other library comes with a onDOMLoaded function, it will not erase yours (or vice-versa). You can check http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiNa… for more info Jerome. > </property> > <property> > <name>Annotation Feature Client Side Code</name> > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

16 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] Refactoring of xwiki-configuration module

by Vincent Massol

Hi, I'd like to modify the configuration module so that it can support adding dynamic configuration data (located in XWikiPreferences, WebPreferences or other). I'd like to propose: * We remove the notion of ConfigurationManager * We make ConfigurationSource components * We create a XWikiPropertiesConfigurationSource (hint = "xwikiproperties") * (future) We create XWikiPreferencesDocumentConfigurationSource, SpacePreferencesDocumentConfigurationSource, UserPreferencesDocumentConfigurationSource components * Create a DefaultConfigurationSource component (hint = "default") which has @Requirement("xwikiproperties") (and other sources later on). It's a composite ConfigurationSource which calls the various internal sources in the right order. In term of usage here's what you'd write. For example for DefaultRenderingConfiguration: @Component public class DefaultRendernigConfiguration implements RenderingConfiguration { @Requirement ConfigurationSource source; private static final String PREFIX = "rendering."; private static final String DEFAULT_LINK_LABEL_FORMAT = "%p"; public String getLinkLabelFormat() { return (String) this.source.getProperty(PREFIX + "linkLabelFormat", DEFAULT_LINK_LABEL_FORMAT); } } WDYT? Thanks -Vincent

16 years, 3 months

3
2
0 0

[xwiki-devs] Add me

by Jeremy Mason-Herr

Hello please add to list. thanks!

16 years, 3 months

1
0
0 0

[xwiki-devs] Reusing Office Importer code

by Cristina Scheau

Hello! For the XOO project, I would need a conversion module which has two components: 1. converter from the swriter html in pure html. 2. bidirectional converter wiki syntax - html. Is this already done in the Office Importer project? If yes, I would be grateful if you tell me where can I find this components. Best regards, Cristina Scheau

16 years, 3 months

7
12
0 0

Re: [xwiki-devs] [xwiki-notifications] r21328 - platform/xwiki-applications/trunk/blog/src/main/resources/Blog

by Vincent Massol

Does this mean our blog application doesn't work for non admins in XE 1.9? If so it's a big problem that may require releasing 1.9.1 sooner than we wanted IMO and do a 1.9.2. WDYT? Thanks -Vincent On Jun 17, 2009, at 3:20 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2009-06-17 15:20:27 +0200 (Wed, 17 Jun 2009) > New Revision: 21328 > > Modified: > platform/xwiki-applications/trunk/blog/src/main/resources/Blog/ > Publisher.xml > Log: > XABLOG-49: Publishing blog posts does not work for non-admin users > Fixed. > Patch from Marta Girdea applied without changes. > > Modified: platform/xwiki-applications/trunk/blog/src/main/resources/ > Blog/Publisher.xml > =================================================================== > --- platform/xwiki-applications/trunk/blog/src/main/resources/Blog/ > Publisher.xml 2009-06-17 13:17:12 UTC (rev 21327) > +++ platform/xwiki-applications/trunk/blog/src/main/resources/Blog/ > Publisher.xml 2009-06-17 13:20:27 UTC (rev 21328) > @@ -30,7 +30,7 @@ > #end > #set($entryName = "$!{request.entryName}") > #if($entryName != '') > - #if($xwiki.hasAccessLevel('edit', $context.user, > $entryDoc.fullName)) > + #if($xwiki.hasAccessLevel('edit', $context.user, $entryName)) > #set($entryDoc = $xwiki.getDocument($entryName)) > #if ($entryDoc) > #getEntryObject($entryDoc $entryObj)

16 years, 3 months

2
1
0 0

[xwiki-devs] wiki manager - URL path access - problem with editor form buttons

by Pascal Voitot

Hello, I tried using the URL path based wiki access as described in Manager Admin Guide: http://localhost:8080/xwiki/wiki/mydomain.com/view/Main/WebHome It works perfectly but then I click on the "Edit" menu for any content from such an URL. Finally I try to click on a bottom button "Cancel", "Preview" etc... It redirects me to : http://127.0.0.1:8080/xwiki/bin/login/XWiki/XWikiLogin?srid= So apparently with URL based notation, the form action is badly managed and redirect to 127.0.0.1 and then to the login as I'm not logger on 127.0.0.1... Do you know this issue? Pascal

16 years, 3 months

2
3
0 0

[xwiki-devs] [GSoC] Reminder: midterm evaluation in less than 3 weeks

by Sergiu Dumitriu

Hello GSoC students, Time flies fast when you're having fun: only 3 weeks left until the midterm evaluation. Don't forget that, by July 6th, you should all have a project with at least 30% of the functionalities proposed in your application, which will help us estimate whether you will be able to finish your work according to the plan or not. Also, don't forget about the (at least) weekly commits requirement, very important for getting proper feedback, and about updating the wiki when you have news. Note that we believe some of the projects are not really advancing as expected, but it's probably not too late to catch up. Please communicate with one of the mentors in case you get stuck. Hoping to see some nice code committed this week, -- Sergiu Dumitriu http://purl.org/net/sergiu/

16 years, 3 months

5
4
0 0

[xwiki-devs] [VOTE] XE 1.9.1 release date

by Vincent Massol

Hi, I'd like to propose that we release a XE 1.9.1 on the 29th of June. It'll contain bug fixes. We currently have the following planned/done for core: http://jira.xwiki.org/jira/browse/XWIKI/fixforversion/11150 Note that this is one week after the 2.0M1 planned release. Here's my +1 Thanks -Vincent

16 years, 3 months

4
3
0 0

Re: [xwiki-devs] [xwiki-users] [Proposal] XWiki Enterprise 2.0 Roadmap

by Vincent Massol

Hi Richard, On Jun 16, 2009, at 9:31 AM, goldring, richard wrote: > Hi, > > Maybe not in the next build, but: > > * more wysiwyg page layout tools (instead of hand coding css) would > be good > to enable users to rapidly and quickly knock up good looking pages, I think this could be solved with the new 2.0 macros we're planning to add: - http://jira.xwiki.org/jira/browse/XWIKI-2965 - http://jira.xwiki.org/jira/browse/XWIKI-2963 - http://jira.xwiki.org/jira/browse/XWIKI-2966 - http://jira.xwiki.org/jira/browse/XWIKI-1689 WDYT? > * also better table creating/editing (resizing, etc) and formatting > (grid > lines hidden/shown) would also be good. ok > > * facility to email in content (text, images, rich text, word/open > docs, > etc) to automatically create wiki pages would be good (think can do in > Confluence?) Yes that would be handy. Actually I thought that we had done this at some point but maybe it was only done on some specific instance and not in the core. > * some sort of automated work flow facility This would need to be discussed more since this is too generic and the needs might be various. Right now there are 2 solutions for simple workflows: - use spaces with permissions and some velocity to move pages from one space to another - add a Status object to pages and use HQL (or XWQL) to perform queries based on the status > * some sort of dashboard/home page mashups for users to provide user > customised access to wiki content You mean ability to insert widgets? Meaning that it's the user that chooses the widgets he'd like to see. Something like http://incubator.myxwiki.org/xwiki/bin/view/Gadgets/WebHome maybe? Now you mention "wiki content". Do you have ideas about content widgets you'd like to see? Thanks -Vincent > Regards, > > Richard > > -----Original Message----- > From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org]On > Behalf > Of Guillaume Lerouge > Sent: 15 June 2009 16:45 > To: XWiki Users; XWiki Developers > Subject: [xwiki-users] [Proposal] XWiki Enterprise 2.0 Roadmap > > > Hi XWiki Devs & Users, > here's the current proposal for the XWiki Enterprise 2.0 roadmap. > Please > give us your feedback about it and tell us whether you think we missed > anything important. Please note that this roadmap covers the next 3 > months > of development work. Improvements not included here will be > discussed at the > beginning of the next roadmap (in September 2009). > > Shout if you think we forgot something ;-) > > The list of tasks is divided in 3 parts: tasks we have already > planned to > have people working on, tasks that we would like to complete during > the > course of the release but have nobody planning to work on yet and > tasks that > will have to be postponed until the next release cycle. > > *Tasks with people already planned to work on:* > > - Rendering (Thomas) > - Fix bugs > - Make sure the XWiki 2.0 syntax doesn't move any more once XE > 2.0 is > out > - WYSIWYG editor (Marius, Anca) > - Fix bugs > - Implement search in the link insertion dialog box > - Improve the macro insertion dialog box > - CAPTCHA integration (Jérôme) > - Clustering (Thomas) > - Write a clustering component based on XWiki events > - Activity Stream integration (JV) > - Watchlist (JV) > - Rewrite the watchlist feature based on the activity stream > - Make the watchlist work in XEM > - Macros (Asiri) > - Write the velocity macro bridge > - Write a number of velocity macros > - UI Improvements (Caty) > - Blog > - User Profile > - Architectural Improvements (Vincent) > > *Tasks with nobody planned to work on as of today:* > > - Migrate all XWiki Enterprise pages to use the XWiki 2.0 syntax > (Collective effort?) > - Rewrite XWiki's Lucene Search backend (Sergiu?) > - Improve XWiki's default skin (Laurent?) > > *Tasks that will have to be postponed to the next release cycle:* > > - Application Manager > - Document Type Manager > - Invitation Manager > > The current roadmap dates are the following: > > - XE 2.0 M1: June 22 > - XE 2.0 M2: July 13 > - XE 2.0 M3: August 3 > - XE 2.0 RC: August 17 > - XE 2.0: August 31 > > Thanks in advance for your feedback. > > Guillaume, on behalf of the XWiki Development Team

16 years, 3 months

4
8
0 0

[xwiki-devs] logout redirection problem with XWiki server behind an apache proxy

by Pascal Voitot

Hello, I wonder whether this is a error in my servers configurations or this is a bug... I have an XWiki server running behind an Apache server and the link between them is performed using the simple mod_proxy with some pass such as: ProxyPass /xwiki/ http://localhost:8080/xwiki/ It works perfectly except when I logout... I get redirected to an URL looking like: http://localhost:8080/xwikihttp://mydomain/xwiki/bin/login/XWiki/XWikiLogin… Do you have an idea of the reason of this behavior? regards Pascal

16 years, 3 months

1
1
0 0

[xwiki-devs] Do we still need ApplicationContextInitializer?

by Vincent Massol

Hi, Since I've now introduced events for XWiki App start/stop and since listeners to those events can have the Container injected in them, do we still need the notion of ApplicationContextInitializer? Thanks -Vincent

16 years, 3 months

1
1
0 0

[xwiki-devs] [VOTE] Remove shared-test-tools jira project

by Vincent Massol

Since we have moved the module to the core module. Here's my +1 Thanks -Vincent

16 years, 3 months

4
4
0 0

[xwiki-devs] [Proposal] Create JIRA project for Macro Archetype module

by Vincent Massol

Hi, I've added a maven archetype for creating macros here: http://jira.xwiki.org/jira/browse/XWIKI-3977 I'd like to add a jira project for it now. WDYT? Thanks -Vincent

16 years, 3 months

5
4
0 0

[xwiki-devs] [Proposal] Change tools groupId to org.xwiki.platform.tools

by Vincent Massol

Hi, I'd like to propose changing the tools groupId for all tools projects to org.xwiki.platform.tools WDYT? Thanks -Vincent

16 years, 3 months

6
5
0 0

[xwiki-devs] shortcut capture interferes with flash app

by glenn_engel＠agilent.com

Hi, For IE, I have a flash app embedded on a page but when a text field is active in the flash app keystrokes are being captured and treated as shortcuts so suddenly I find myself in the history section after typing an 'h' for example in a 'in focus' flash app entry box. Firefox seems to be OK in this regard. I notice that the shortcut setup has something like 'disable_in_input':true. Is there by chance a way to tell it to disable in object or embed tags (or a named/classed div)? Probably not from looking at the shortcut.js home page. Alternatively, is there a way to disable shortcuts in xwiki? -- Glenn

16 years, 3 months

2
1
0 0

[xwiki-devs] Plugin generated menus

by glenn_engel＠agilent.com

I would like to add a menu selection for a plugin similar to the Watch menu. However, I cannot figure out where this is done. I initially thought the WatchListPlugin would be a good example but I don't see any code there dealing with menus. How would a plugin go about adding to system menus? Thanks, Glenn

16 years, 3 months

3
2
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