xwiki-devs August 2010

xwiki-devs@xwiki.org

29 participants
47 discussions

[xwiki-devs] [proposal] Deprecate XWikiHibernateStore internal methods.

by Caleb James DeLisle

There are a number of public methods in XWikiHibernateStore which are either nolonger used, unused outside of XWikiHibernateStore, or used in only a few places in old code. To make maintainence easier I propose deprecating them to discourage outside code from using them so they can later be removed or made private. Here is a list: saveXWikiObject used 1 place in c.x.x.XWiki#addUserToGroup which appears to be easily fixed. saveXWikiCollection used 3 places in the stats plugin. loadXWikiObject used 1 place in the old query plugin. loadXWikiCollection used 3 places in the stats plugin. deleteXWikiCollection used 1 place in stats plugin. deleteXWikiCollection used 1 place in stats plugin. deleteXWikiClass used nowhere. loadXWikiProperty used nowhere (outside of XWikiHibernateStore). saveXWikiClass used nowhere (outside of XWikiHibernateStore). loadXWikiClass used nowhere (outside of XWikiHibernateStore). saveXWikiClassProperty used nowhere. loadAttachmentList used nowhere (outside of XWikiHibernateStore). saveAttachmentList used nowhere (outside of XWikiHibernateStore). saveAttachment used nowhere (outside of XWikiHibernateStore). injectCustomMappingsInSessionFactory used nowhere (outside of XWikiHibernateStore). injectInSessionFactory used nowhere (outside of XWikiHibernateStore). isValidCustomMapping used nowhere (outside of XWikiHibernateStore). getBatcherStats used nowhere. resetBatcherStats used nowhere. WDYT? Caleb

14 years, 3 months

[xwiki-devs] [proposal] Cancelable events and refactoring script macros

by Alex Busenius

Hello, I'd like to refactor AbstractScriptMacro in order to be able to change script behavior in the future without fanout violations. Here is the plan emerged after several discussions with ThomasM: Introduce a notion of cancelable events. Such events can be canceled by the receiver (providing an optional reason), the actual canceling is performed by the sender. http://dev.xwiki.org/xwiki/bin/view/Design/CancelableEvents Send a cancelable event ScriptEvaluationStartsEvent in AbstractScriptMacro just before evaluating the script and a ScriptEvaluationFinishedEvent right after evaluation has finished (in finally block). Add the following 3 listeners to those events (into rendering.internal.macro.script) and move the corresponding code from AbstractScriptMacro there: ScriptClassLoaderHandlerListener * does class loader manipulations currently performed by AbstractScriptMacro#getClassLoader & Co PermissionCheckerListener * Aborts execution of scripts that need PR if the document is not saved with PR * To distinguish velocity and PR scripts, introduce a new interface PrivilegedScriptMacro extends ScriptMacro and let AbstractJSR223ScriptMacro implement it NestedScriptMacroValidatorListener * Replaces NestedScriptMacroValidator (ScriptMacroValidator component is removed completely) The refactoring will remove the following methods (breaks API): AbstractJSR223ScriptMacro: * protected boolean canExecuteScript() * public List execute(JSR223ScriptMacroParameters, String, MacroTransformationContext) AbstractScriptMacro: * protected boolean canHaveJarsParameters() * protected ClassLoader getClassLoader(String, ClassLoader) WDYT? Alex

14 years, 3 months

[xwiki-devs] [proposal] Remove flickr plugin from CORE

by Sorin Burjan

Hello. It seems that platform/trunks/core/xwiki-core/src/main/java/com/xpn/xwiki/plugin/flickr plugin is not used by anything in XWiki. It seems to be old and deprecated. I propose to remove it from xwiki-core. The things to discuss would be : Topic I. Where to move it: 1.Deprecate it (move it to contrib retired) 2.Remove it from everywhere (delete code) 3.Move it to CORE plugins 4.Rewrite it nicely as a service and have it : 1.as core module 2.in contrib sandbox Topic II. Relation to the platform 1.bundle it by default 2.not bundle it by default I am +1 for I.2 and II.2 . WDYT? Thanks, Sorin

14 years, 3 months

Re: [xwiki-devs] IMPORTANT: WYSIWYG editor language in user interface

by Marius Dumitru Florea

Hi Ramon, First of all sorry for the late reply, I've been in holidays for the past two weeks. On 08/18/2010 09:05 PM, Ramon Gomes Brandão - SERINT wrote: > Hi Marius, > > I’m a long-time enthusiast of XWiki and I think it’s the best wiki tool I'm happy to hear that! > ever. However, I feel some lack of updated documentation on how to > build it. I’m implementing a large instance of XWiki Enterprise 2.4 in > my work here in Brazil, and I’m facing an issue: detailed instructions > on how to build the new WYSIWYG editor. I’ve translated the > Strings.properties file in Portuguese, and I’m trying to use Eclipse > with m2eclipse to build it, but I definitively don’t know how to > proceed. I saw your messages on xwiki-users archives about this build. > Could you help me sending detailed steps on how to do this? Here are my > questions: > > 1) I’ve installed Eclipse+m2eclipse+subclipse and checked out the > platform/web/trunk folder. It contains the following sub-folders (modules): > > -gwt > > -standard > > -xwiki-gwt-dom > > -xwiki-gwt-user > > -xwiki-gwt-wysiwyg-client > > -xwiki-gwt-wysiwyg-server > > Do I need all the modules to proceed? The WYSIWYG editor code is split between xwiki-gwt-wysiwyg-client and xwiki-gwt-wysiwyg-server. The server side depends on the XWiki core, while the client side depends on xwiki-gwt-user and xwiki-gwt-dom. You can ignore the other two modules (gwt and standard). You can ignore xwiki-gwt-dom too if you don't plan to change/enhance the DOM API. > Where should I place > Strings_pt.properties ? Do I need to modify “extended-property …” both > on xwiki-gwt-user and > xwiki-gwt-wysiwyg-client/resources/…/Wysiwyg.gwt.xml or only in this > last one? There are three translation files as indicated on http://l10n.xwiki.org/xwiki/bin/view/Wysiwyg/ . One is included in xwiki-gwt-user and the other two are in xwiki-gwt-wysiwyg-client: http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-user/src/ma… http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-cli… http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-cli… Best is to translate all these files. You should place the translated file (e.g. Strings_pt.properties) in the same directory as the corresponding source file (e.g. Strings.properties). Then you have to modify both: http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-user/src/ma… and http://svn.xwiki.org/svnroot/xwiki/platform/web/trunk/xwiki-gwt-wysiwyg-cli… in order to update the locale property: <extend-property name="locale" values="...,pt"/> > > 2) Which modules do I need to build (with right click - > Run as -> > Maven build or Maven install)? In which order? I don't build from eclipse although I have m2eclpse installed. I prefer the console. The right build order is: xwiki-gwt-user > xwiki-gwt-wysiwyg-client > xwiki-gwt-wysiwyg-server xwiki-gwt-user and xwiki-gwt-wysiwyg-client generate jars that are used by xwiki-gwt-wysiwyg-server which generates a war. Note that building xwiki-gwt-wysiwyg-server takes a long time because GWT compilation is costly. > > 3) Does this build generates a war automatically? Where does it > generates the war (where I can find it)? The war generated by xwiki-gwt-wysiwyg-server is placed in the target directory (e.g. target/xwiki-web-gwt-wysiwyg-server-2.5-SNAPSHOT.war). I know this happens when you build from command line. Might be different when you build from eclipse, but you should be able to find the war anyway. In the worst case, if you run "mvn install" the war will be installed in your local repository: ~/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt-wysiwyg-server/2.5-SNAPSHOT/xwiki-web-gwt-wysiwyg-server-2.5-SNAPSHOT.war > > 4) How to load the new build into my running XWiki Enterprise 2.4 > instance? You have to replace (don't merge!) webapps/xwiki/resources/js/xwiki/wysiwyg/xwe directory from your XWiki installation with the one from the previously generated war. If you change code on the WYSIWYG sever side then you have to update the jars from WEB-INF/lib (copy those from the generated war) but that's not your case from what I can see. Don't forget to clear the browser cache. > How to force always the WYSIWYG editor to be shown in Portuguese? > You can either configure the Portuguese language as the default language in XWiki (the clean way) or, the hard way, you can build the WYSIWYG editor only for Portuguese language by replacing: <extend-property name="locale" values="...,pt"/> with <set-property name="locale" value="pt" /> in the descriptors of the xwiki-gwt-user and xwiki-gwt-wysiwyg-client GWT modules. > Hope you can help me. Note that the best way to contribute a translation is to add it to l10n.xwiki.org . This way all the previous steps are done by us. The downside is that you have to wait for the next release to see the Portuguese translation in action. Hope this mail doesn't come too late, Marius > > Regards, > > *Ramon Gomes Brandão* >

14 years, 3 months

[xwiki-devs] [proposal] Migrate database to store passwords in LargeStringClass and begin using crypto.passwd#protectPassword

by Caleb James DeLisle

Because protectPassword generates a base-64 encoded java serialized form, the size is quite a bit larger than the 255 character limit of StringProperty and thus PasswordProperty. The use of java serialization is central to the upgradability of the password verification function because any new class which implements PasswordVerificationFunction automatically works. Given this, I want to migrate the database to move password hashes into the xwikilargestrings table and change PasswordProperty to extend LargeStringProperty. During this migration, any passwords still stored in plaintext will be ported to the scrypt function, passwords stored as a hash will have an exclamation mark pretended to the text (this is invalid base64) and be inserted into the table as is. PasswordClass will keep the sha-512 hash function for legacy passwords but will port passwords to the new format as users log in. These changes will allow us to close http://jira.xwiki.org/jira/browse/XWIKI-70 and http://jira.xwiki.org/jira/browse/XWIKI-582 WDYT? Caleb

14 years, 3 months

[xwiki-devs] [Proposal] Add new methods for manipulating properties to DocumentAccessBridge

by Alex Busenius

Hi devs, It seems that currently there is no good way to manipulate XWiki objects and properties in documents without depending on old core. DocumentAccessBridge defines some methods for changing properties, but they are very limited, in particular, there is no way to: * add a new property (except the first one) * set a property of n-th object (getting it is possible) * remove an object * get the number of objects Therefore I propose to add the following methods to DocumentAccessBridge: // returns index of the new object int addObject(ObjectReference obj) throws Exception; // returns false if there was no object, throws on access error boolean removeObject(ObjectReference obj, int index) throws Exception; // number of objects of the given class int getObjectCount(ObjectReference obj); // returns index of the object that was modified, adds a new object if // index is out of range int setProperty(ObjectReference obj, int idx, String prop, Object val) throws Exception; // just to have all needed methods taking object reference Object getProperty(ObjectReference obj, int index, String propertyName); I've chosen ObjectReference because it contains (almost) all needed information, including class name and document reference. It would be better to have the object index stored in the reference too, like in org.xwiki.annotation.reference.IndexedObjectReference, but this class is annotation-specific. I need those methods to store certificates in user profile, see https://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-signedscripts WDYT? Thanks, Alex

14 years, 3 months

[xwiki-devs] [Proposal] Code names for XWiki release cycles

by Jerome Velociter

Hello friends, I would like to propose introducing the use of code names for each release cycle of XWiki (2.x, 3.x, etc.), using a agreed-on scheme (a la Ubuntu [1]). The main reason behind this proposal is that : A. it's groovy :) B. there is no B. As for the code name scheme, with regard to recent events involving a fair portion of the XWiki Development team [2], I would like to propose the use of cocktail names as code names. Some examples - for the sake of illustration : XWiki "Cuba Libre" 2.5, XWiki "White Russian" 2.6, XWiki "Bloody Mary" 3.0, etc. you name it! [3]. Virgin cocktails tolerated :) The release manager for each cycle would have the honor to pick up the release code name. Isn't that an awesome incentive ? +1 for all that Jerome. [1] https://wiki.ubuntu.com/DevelopmentCodeNames [2] http://www.xwiki.com/xwiki/bin/view/Blog/XWiki+Seminar'10 [3] http://en.wikipedia.org/wiki/List_of_cocktails

14 years, 3 months

[xwiki-devs] [Vote][Proposal] Action Menus Improvements part 2

by Ecaterina Valica

Hi, After gathering some Action Menus feedback, we decided to go for another iteration for them. Please give your feedback on this proposal and *cast your vote* for this items (described at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal…): 1. New "Add" menu 2. Wiki/Space/Page separation 3. New "Delete" Space entry and relocation of some Page actions 4. Better Wiki/Space naming representation (WIKI: Wikiname) 5. Uppercase menu usage just for top entries/labels 6. "TYPE: Name" pattern Screenshots and proposal: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal2 Partial prototype: http://incubator.myxwiki.org/xwiki/bin/view/Skins/SkinMenu Thanks, Caty P.S. Thanks to Gregory for all opinions / ideas

14 years, 4 months

[xwiki-devs] [UX] Action Menus: What menu items we have into "Simple/Advanced" mode

by Ecaterina Valica

Hi, "Simple/Advanced" mode definition http://platform.xwiki.org/xwiki/bin/view/Features/PageEditing#HSimpleandAdv… After discussing Action Menu Improvements part 2 ( http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal2) we changed the position of "Access rights" from "Edit" submenu to "Page" submenu. Until now, changes done by "Advanced" mode were located only in "Edit" submenu. A. The question is: what other items do you think should go under "Simple"/"Advanced" mode? Do we keep the same items? Do we add more? Do we simplify? B. Another idea is to change "Simple"/"Advanced" mode into "User"/"Developer"/"Admin" in the structure we also have the documentation written. Obs1. The problem with menus is that they don't rely only on these modes, but also on the rights the users has to do some actions (like edit, delete, admin). Obs2. The ideal way for this topic would be to let administrators decide what goes into what mode, but even like that, we should still have some standards values for the modes. Thanks, Caty

14 years, 4 months

[xwiki-devs] [proposal] A separate hudson project for escaping tests

by Alex Busenius

Hi devs, The new escaping tests I recently proposed generate a quite large number of tests and take noticeable amount of time to run. There are currently 782 escaping tests, they need 8 minutes on my core duo (for comparision, there are about 1800 tests in enterprise/ in total, they need 1 hour). Caleb had an idea about adding a separate Hudson project for them, this would make it possible to see the cause of failures or, in ideal case, run functional tests in parallel with escaping tests (if the hardware is good enough). WDYT? Alex

14 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2010