xwiki-devs November 2009

xwiki-devs@xwiki.org

43 participants
137 discussions

[xwiki-devs] [VOTE] Add streaming support to parsers

by Thomas Mortagne

Hi, Among other things the goal is to be able to directly do parser -> renderer instead of parser -> XDOM -> renderer Thing is all our parsers (including Doxia and WikiModel parsers) are streaming based. So For example we generate a XDOM from events in theses so instead of converting WikiModel events and generate XDOM all in once we would convert WikiModel events to XWiki events (i.e. org.xwiki.rendering.listener.Listener) and generate the XDOM from XWiki events. Here are some use cases for this new feature: * xml parser read events and need to generate a XDOM from them so it would be nicer to have a common XDOMGeneratorListener to generate XDOM from Listener instead of having one in xml parser another in WikiModel, Doxia... * when we convert from one syntax to another we don't execute transformations so it would be better to have streaming conversion support for this * when we save XHTML content coming form WYSIWYG we don't execute any macro so it would be better to use streaming parser here too * some rendering tests are executed without transformations, could be better to execute them in pure streaming * streaming renders are not really usable without streaming parsers, parser->render is way more common use case than someone calling renderer events by hand * could be useful in wiki importers too where we don't execute macros * It's generally more consistent anyway to have streaming parser since we have streaming renderer Like for renderers I propose to have two different parsers components interfaces for the block parser and the stream parser. Basically all this means introducing: public interface StreamParser { /** * @return the wiki syntax the parser is implementing */ Syntax getSyntax(); /** * @param source the content to parse * @param listener receive event for each element * @throws ParseException if the source cannot be read or an unexpected error happens during the parsing. Parsers * should be written to not generate any error as much as possible. */ void parse(Reader source, Listener listener) throws ParseException; } (and internally refactor most of the parsers to use a common Listener events based XDOMGeneratorListener). Here is my +1 -- Thomas Mortagne

14 years, 10 months

[xwiki-devs] How do I move a space webhome page to another space?

by Vincent Massol

Hi (Guillaume), This is related to the move page which is now using a combo box, thus preventing creation of a new space. I remember I was against this (I'd have preferred an auto suggest). So imagine the following scenario: - I have a MySpace.WebHome page - I'd like to move this WebHome page to a new space: MySpace2.WebHome How do I do this? Thanks -Vincent

14 years, 10 months

[xwiki-devs] Thank you everyone. Here is the Lightbox macro.

by Zhaolin Feng

With the help of Sergiu Dumitriu, Marius Dumitru Florea, Jerome Velociter, Guillaume Lerouge, I finally struggled to create my first XWiki Macro. Thank you. http://code.xwiki.org/xwiki/bin/view/Macros/LightboxMacro But the process is not without dramas. 1. The problem with {{velocity output="false"}} #if($context.action != 'edit') {//velocity}} 2. Especially, http://jira.xwiki.org/jira/browse/XWIKI-4591 I'm new to XWiki. The 2.0 syntax and velocity is great. But the documentation and tutorial is not enough. And there are some gottas. I lose two nights of sleep to the job :( I think it's better to write more documents. And so there will be lesser unhappy newbie developers like me. -- -- Currahee! We stand alone together!

14 years, 10 months

[xwiki-devs] [VOTE] Postpone XE 2.1M1 release to Wednesday 18th

by Vincent Massol

Hi, Today is supposed to be the 2.1M1 release day. However we have 2 big commits waiting: - cleaned Colibri CSS - new action bar (http://82.233.128.14/xwiki/bin/view/Main/AllDocs) I think it's best to wait for these commits since they can be done today and we'll need all the feedback we can from users after they are committed. Thus I'm proposing to commit them now and postpone the release to this coming Wednesday (18th of Nov 2009), without changing the 2.1RC1 date (30th of Nov). Here's my +1 Thanks -Vincent

14 years, 10 months

[xwiki-devs] [Proposal] Adding a new option for the livetable macro: summary

by Vincent Massol

Hi, For WCAG we need to add summary attributes to our tables. I'm proposing to allow the user to pass such a summary to the livetable macro through a new option. For ex: [...] #set($options = { "className":"XWiki.XWikiUsers", "translationPrefix" : "xe.index.users.", "tagCloud" : true, "rowCount": 15, "summary: "the summary here" }) #livetable("userstable" $columns $columnsProperties $options) WDYT? ok? Thanks -Vincent

14 years, 10 months

[xwiki-devs] Protection against Cross-Site Request Forgery?

by Sergiu Dumitriu

Hi devs, Should XWiki protect itself against CSRF? See http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29 and http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Preven… for details. In short: an attacker could use something like: <img src="http://xwikiserver/bin/save/Some/Document?content=Hacked"/> to alter the wiki using another user's account. Protection usually involves embedding tokens in submitted forms and URLs. The good news is that it can be done transparently using a LGPL tool from OWASP. The bad news is that it does not protect against attacks from the same wiki, but only for Cross-Site attacks. And it also breaks direct manipulation using URLs (as an expert user, I do enter URLs directly instead of clicking through the interface, and I won't like it if I couldn't do it anymore). So, WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 10 months

[xwiki-devs] configuration issue

by MOUZELER Cyril

Hi all, I have installed xwiki enterprise manager on Windows in a Jetty Container based on Oracle. It works fine. But i 've got a problem to reach it in my web browser. My Windows server has an IP 10.10.10.10 for example and a name : xwiki-corner.domain.com for example. In my browser, I am not able to access to http://xwiki-corner.domain.com but http://10.10.10.10 works very well. I 've checked nslookup, ping ... this is not the problem: it seems to be a redirect issue... So could you help me ? Cyril -------------------------------------------------------------------------------- This e-mail is intended only for the addressee named above. It does not bind the sender, except in the case of an existing written convention with the addressee. This e-mail may contain material that is confidential and privileged for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender and delete all copies. While reasonable precautions have been taken to ensure that this e-mail and any attachments are free from any computer virus or similar defect, no liability will be accepted in that respect. Anyone accessing this e-mail must take their own precautions as to security and virus protection. KBL European Private Bankers S.A., 43 boulevard Royal L-2955 Luxembourg, R.C.S. Luxembourg B 6395, T (352) 47 97 1

14 years, 10 months

Re: [xwiki-devs] [xwiki-notifications] r25059 - in platform: core/trunk/xwiki-core/src/main/resources web/trunk/standard/src/main/webapp/templates

by Vincent Massol

On Nov 14, 2009, at 2:53 PM, Jerome Velociter wrote: > On 11/14/09 2:52 PM, Jerome Velociter wrote: >> On 11/13/09 5:19 PM, vmassol (SVN) wrote: >>> Author: vmassol >>> Date: 2009-11-13 17:19:01 +0100 (Fri, 13 Nov 2009) >>> New Revision: 25059 >>> >>> Modified: >>> platform/core/trunk/xwiki-core/src/main/resources/ >>> ApplicationResources.properties >>> platform/web/trunk/standard/src/main/webapp/templates/macros.vm >>> Log: >>> XWIKI-4588: Associate labels with livetable filter inputs and >>> improve livetable title attributes >>> >>> * TODO: add labels for lists too >>> >>> Modified: platform/core/trunk/xwiki-core/src/main/resources/ >>> ApplicationResources.properties >>> =================================================================== >>> --- platform/core/trunk/xwiki-core/src/main/resources/ >>> ApplicationResources.properties 2009-11-13 16:18:12 UTC (rev 25058) >>> +++ platform/core/trunk/xwiki-core/src/main/resources/ >>> ApplicationResources.properties 2009-11-13 16:19:01 UTC (rev 25059) >>> @@ -1843,7 +1843,7 @@ >>> xe.livetable._actions.rename=rename >>> xe.livetable._actions.rights=rights >>> xe.livetable._actions.copy=copy >>> -xe.livetable.filters.title=Enter a filter for this field >>> +xe.livetable.filters.title=Filter for the {0} column >>> xe.livetable.loading=Loading... >>> xe.livetable.tags.help=Click on one or more tags to filter the >>> list >>> xe.livetable.tags.help.cancel=and click again on a tag to cancel >>> the filter >>> >>> Modified: platform/web/trunk/standard/src/main/webapp/templates/ >>> macros.vm >>> =================================================================== >>> --- platform/web/trunk/standard/src/main/webapp/templates/ >>> macros.vm 2009-11-13 16:18:12 UTC (rev 25058) >>> +++ platform/web/trunk/standard/src/main/webapp/templates/ >>> macros.vm 2009-11-13 16:19:01 UTC (rev 25059) >>> @@ -1564,6 +1564,11 @@ >>> <tr> >>> #foreach($colname in $collist) >>> #set($colprop = $colprops.get($colname)) >>> + #if(("$!colprop.filterable" == "" || >>> $colprop.filterable != false)&& "$!colname" != "_actions") >>> + #set($isFilterable = true) >>> + #else >>> + #set($isFilterable = false) >>> + #end >>> #if(("$!colprop.sortable" == "" || >>> $colprop.sortable != false)&& "$!colname" != "_actions") >>> #set($isSortable = true) >>> #else >>> @@ -1572,7 +1577,9 @@ >>> #if($colname != "_actions" || $hasAdmin) >>> <th class="xwiki-livetable-display-header-text >>> #if($isSortable)sortable #if($colname == $selectedColumn)selected >>> $defaultOrder#else asc#end#end" #if("$!colprop.type"=="hidden") >>> style="display: none" #end> >>> #if($isSortable)<a rel="${colname}">#end >>> + #if($isFilterable&& ("$! >>> colprop.type"=="text"||"$!colprop.type"=="number"))<label >>> for="xwiki-livetable-filter-${velocityCount}">#end >> >> With this, we'll have ID collision if several live tables are >> displayed >> on the page. >> >> You need to add the table identifier (passed as a parameter of the >> macro >> AFAIR) in the field ID. > > Sorry for the noise, just seen you've fixed it already. Yep :) Thanks for checking! -Vincent >> Jerome. >>> $msg.get("${transprefix}${colname}") >>> + #if($isFilterable)</label>#end >>> #if($isSortable)</a>#end >>> </th> >>> #end >>> @@ -1604,7 +1611,7 @@ >>> </select> >>> </td> >>> #elseif( ("$!colprop.type"=="text"||"$! >>> colprop.type"=="number")&& $isFilterable) >>> -<td class="xwiki-livetable-display-header-filter"><input name="$ >>> {colname}" type="text" #if("!$colprop.size"!="") size="$ >>> {colprop.size}" #end >>> title="$msg.get('xe.livetable.filters.title')" /></td> >>> +<td class="xwiki-livetable-display-header-filter"><input >>> id="xwiki-livetable-filter-${velocityCount}" name="${colname}" >>> type="text" #if("!$colprop.size"!="") size="${colprop.size}" >>> title="$msg.get('xe.livetable.filters.title', [$msg.get("$ >>> {transprefix}${colname}")])"#end /></td> >>> #elseif("$!colprop.type"=="hidden") >>> #elseif($colname != "_actions" || $hasAdmin) >>> <td class="xwiki-livetable-display-header- >>> filter"></td>

14 years, 10 months

[xwiki-devs] More xwiki macro parameter type. boolean, enumeration?

by Zhaolin Feng

I'm learning to implement a macro for Lightbox Application as suggested by Guillaume. So far I've read: http://platform.xwiki.org/xwiki/bin/view/DevGuide/WritingMacros And I have a question. Is it possible to have other macro parameter types besides string? For examples, boolean, enumeration, filename, image, color. And it's even better to have color picker, image picker dialog automatically popped up when clicking. I see the HTML macro have boolean parameters. How is it achieved? Is is possible to reuse the image picker of the WYSIWYG editor? -- -- Currahee! We stand alone together!

14 years, 10 months

[xwiki-devs] [Idea] Post-loaded JSX

by Jerome Velociter

Hello all, I think it would be nice to have the possibility to post-load some of the JavaScript extensions, as a way to ease performance best practices for developers. (See http://developer.yahoo.com/performance/rules.html#postload for example). It would also allow people to easily add hungry third party scripts (like the google analytics tracker) in a non intrusive manner and not sacrificing performance (no need to modify/override htmlfooter.vm for example, a simple SX always-use will do). I see different ways of doing that : 1) Either we say all document JSX are post-loaded, and we move the hook down the DOM just before the closing </body> tag. 2) Either we have 2 hooks and we leave it as an option to be post-loaded. My preference goes to 1), as I don't see any good use case where a extension would need not to be post-loaded; and 2) is not so elegant to implement with the current SX mecanism. WDYT ? (Note: I'm not talking about file-system extensions here (JSFX), though the question could be asked for them as well - I need to give it more thoughts) Jerome.

14 years, 10 months

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

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