June 2009 - xwiki-devs@xwiki.org

[xwiki-devs] Document Type Manager
by Chathura Prabuddha 22 Jun '09

22 Jun '09

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.

1 0

[xwiki-devs] [Proposal] Extension Manager
by Vincent Massol 21 Jun '09

21 Jun '09

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

2 4

[xwiki-devs] [PROPOSAL] JSR223 (Scripting for the Java Platform) and XWiki context
by Thomas Mortagne 21 Jun '09

21 Jun '09

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

5 7

[xwiki-devs] [Wild Idea] Live Search
by Vincent Massol 21 Jun '09

21 Jun '09

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

6 7

[xwiki-devs] [Rendering] Two ideas using Transformation
by Vincent Massol 20 Jun '09

20 Jun '09

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

3 3

[xwiki-devs] [VOTE] Logging rules
by Vincent Massol 20 Jun '09

20 Jun '09

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

3 3

[xwiki-devs] base url
by glenn_engel＠agilent.com 19 Jun '09

19 Jun '09

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

3 2

[xwiki-devs] Please re-index XWiki.org website, search engine returns only release pages...
by Pascal Voitot 19 Jun '09

19 Jun '09

Thanks Pascal

3 2

[xwiki-devs] Build now works with Maven 2.1.0 and 2.2.0
by Vincent Massol 19 Jun '09

19 Jun '09

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

1 0

Re: [xwiki-devs] [xwiki-notifications] r21332 - in sandbox/xwiki-annotation/xwiki-application-annotation/src/main/resources: . Panels
by Jerome Velociter 18 Jun '09

18 Jun '09

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

1 0