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

[xwiki-devs] [proposal] Stop saving documents in the cache when they are stored in the database.

by Caleb James DeLisle

Hi, There are 2 reasons I want to stop caching documents when they are stored. 1. Coherence, it should be impossible for the cache to have a different entry than the store. Suppose a document is stored and the storage fails without throwing any error, the document will appear to be stored correctly until the cache is purged. Another more likely scenario is that the document loaded from the store is slightly different than the document saved to the store and thus the cache will be lying. 2. Performance, when an attachment is added to a document, the document contains all of the attachment's content. My analysis tells me switching to holding the content with a soft reference would be quite complex and proving that nothing depends on the attachment content not being null is very difficult. The proposed change will prevent the attachment content from ever being stored in the cache and provide an improvement in allowable cache capacity and memory footprint. WDYT? Caleb

15 years

3
3
0 0

[xwiki-devs] [Proposal] Start introducing XWiki Syntax 2.1 (experimental)

by Vincent Massol

Hi everyone, In the rendering module we need to progress on some issues. For example I'd like to implement support for relative URLs: http://jira.xwiki.org/jira/browse/XWIKI-3611 This means introducing XWiki Syntax 2.1 which will a point release after XWiki Syntax 2.0. Of course any page in XWiki Syntax 2.0 will be able to be converted in 2.1 syntax. FTM we haven't fully defined yet the full list of changes in XWiki Syntax 2.1. The idea is to introduce in 2.5 an experimental XWiki Syntax 2.1 syntax to show it's not finished yet (in the UI the syntax name will be "XWiki Syntax 2.1 (experimental)") and start introducing changes, the first one being support for relative URLs. WDYT? Thanks -Vincent

15 years

6
7
0 0

[xwiki-devs] XEM, Workspaces and Wiki3.0

by Fabio Mancinelli

Hi everybody, I am writing to the list in order to discuss an architectural choice which I had the chance to talk about with Vincent. In the framework of the Wiki3.0 [1] projects we are building a social extension of XWiki that will introduce social-oriented functionalities in the platform. One of these functionalities are related to "Workspaces" which have been defined as a "virtual place where a group of users can collaborate on a given topic. A workspace implicitly defines a social-network which consists of the users that participate to the activities in the context of a given workspace." A workspace, besides having a set of users subscribed to it, has also a set of applications that are related to the type of the interactions that are carried in the workspace itself (e.g., a blog, a meeting manager, etc.) This is the abstract picture. At the architectural level this could be implemented in different ways. What we briefly discussed with Vincent is that workspaces could be easily handled by using XEM. In this case, instead of having a mapping Workspace <-> space in a single Wiki we would have a Workspace <-> wiki in a multiwiki setup managed by XEM. This has several advantages since the current features can be already leveraged and extended in order to implement workspace functionalities: 1) existing applications are already ready-to-deploy 2) rights management is already enough to manage subscriptions 3) being a workspace a full wiki this gives the users more flexibility (e.g., they are not constrained to a single space for organizing their content) In this picture the main wiki could be used only as a "user container" and will have all the functionalities (UI + code) to manage workspaces' lifecycle (i.e., creation, deletion). Additional functionalities will the be present in the workspace wiki for actually managing the workspace (i.e., adding/removing members, subscription management for open workspaces, workspace attributes management and so on). Initially I haven't thought about workspaces as wikis in a XEM context by the idea is very powerful and I think we should build it in this way. WDYT? Thanks, -Fabio [1] https://wiki30.xwikisas.com

15 years

5
6
0 0

[xwiki-devs] [proposal] Remove the old rights UI

by Alex Busenius

Hi devs, I propose to remove the old rights interface (called "stable"). This interface was replaced by the current version (the one with livetable) in XWiki 1.2 several years ago, but the old code is still there. The following files are affected: web/standard/**/templates/rightsUI.vm applications/administration/**/XWiki/AdminGroupsSheet.xml applications/administration/**/XWiki/AdminUsersSheet.xml applications/administration/**/XWiki/XWikiGroupSheet.xml applications/panels/**/Panels/GlobalRightsEditorWelcome.xml applications/panels/**/Panels/RightsEditorWelcome.xml core/xwiki-core/**/plugin/rightsmanager/RightsManagerPluginApi.java The Java file contains the method getDefaultUi() to read the xwiki.rights.defaultui configuration property, the rest has parts of the interface. WDYT? Alex

15 years

8
7
0 0

[xwiki-devs] [Proposal] Roadmap for XE 2.5

by Sergiu Dumitriu

Hi devs, I just realized that there was no official roadmap proposal for XE 2.5 yet, since Vincent, the usual release manager, is on holidays. I volunteered for performing the releases, so I'll assume the release manager role as well until Vincent returns. Proposed features for the 2.5 release: - Improved wiki dashboard - Improved edit modes UI - Office Preview - Action menu improvements (Caty, JV, Sergiu) - Export UI improvements (Caty, Sergiu) - "Email this page" feature (Sergiu) - User Directory Generic stuff: - More UI standards (avatars, icons, forms) - Improved performance - Improved security - WYSIWYG bugfixing and optimization - More 2.0 macros Possible new features: - Portlet integration (Marius) - Layout Themes (Sergiu) - Gadgets (Anca) - Wiki Import (Thomas) Proposed dates: - 2.5M1: 30 Aug - 2.5M2: 27 Sep - 2.5RC1: 11 Oct - 2.5RC2/Final: 25 Oct -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years

12
20
0 0

[xwiki-devs] Status of the includeMacros macro in XE 2.4

by Luis Arias

Hi, I posted http://jira.xwiki.org/jira/browse/XE-700 a couple of days ago and am writing now because more and more of the Balsamiq Mockups for XWiki users are attempting or would like to migrate to 2.4 but have pages with mockups embedded using #includeMacros. I'd like to know if #includeMacros is definitely not going to be supported from 2.4 onwards or if this is a bug that will be fixed at some point. We can update the plugin (already have actually) to use the recommended syntax for new mockups but still have the issue of dealing with existing pages. I would also like your thoughts on a simple workaround which ideally we could ask our users / wiki admins to do. Thanks, Luis

15 years

4
9
0 0

[xwiki-devs] Apurv gupta is using discount coupons of Khojguru

by apurv.gpt＠gmail.com

[1]Khojguru - Helping You Save Money Hi XWiki Developers Your friend Apurv Gupta has invited you to join Khojguru so that you can also benefit from the discount coupons available for more than 100 brands. Check out a few: [2]Goibibo : Rs 200 Additional Off Tour & Travel Rs 200 Additional Off on all domestic flights. [3]Yatra.com : Rs 200 Off Tour & Travel Rs 200 Extra Off on every domestic flight booking. [4]Dominos: 25% Off Restaurants Get upto 25% Off on Domino's Pizza [5]Vibes : Upto 90% Off Beauty Salon Services worth Rs. 5500/- free (Pay Only Service Tax) include Rejuvenating Facial, Manicure/Pedicure, Hair Cut, Blow Dry, Weight Loss/Body Shaping Session, Body Analysis, Diet Counseling; 50% Off on Slimming Packages, Skin & Hair Treatment Packages & Permanent Laser Hair Removal Packages; 20% Off on Salon Services. [6]eBay : Rs 150 Voucher Big Retail Stores Rs 150 Off on a bill of Rs 500 or over. Valid only for new registrations on eBay.in. Users who have downloaded eBay coupon from Khojguru before will not be allowed to download again. Khojguru saves you money and time by providing you with discount coupons and updates on sale/offers at any brands. See the entire list of [7]khojguru discounts available at over 100 brands. See the entire list of [8]sales and offers running at different brands in the city. Check for yourself today! Visit this link to accept the invitation: http://khojguru.com/join/56a5e01a6f3ee3bd9e27e2fc5adca8711fb8374a?ref= invite Cheers Team Khojguru You are receiving this email because Apurv gupta sent you an invitation from khojguru.com. To unsubscribe from further emails, [9]click here. This email is auto-generated, please do not reply. References 1. http://delhi.khojguru.com/?ref=invite 2. http://khojguru.com/online-offers/goibibo-tour-travel-discount-coupons-rs-2… 3. http://khojguru.com/online-offers/yatra-com-tour-travel-discount-coupons-rs… 4. http://khojguru.com/delhi/restaurants-in-delhi/dominos-restaurant-discount-… 5. http://khojguru.com/delhi/beauty-salons-in-delhi/vibes-beauty-salon-discoun… 6. http://khojguru.com/online-offers/ebay-big-retail-store-discount-coupons-rs… 7. http://khojguru.com/delhi/discount-coupons?ref=invite 8. http://khojguru.com/delhi/sale-offers?ref=invite 9. http://khojguru.com/dnd/ZGV2c0B4d2lraS5vcmc=%0A

15 years

1
0
0 0

Re: [xwiki-devs] [Proposal][UX] Recent Changes Improvements

by Jerome Velociter

Great ! I like it a lot. I think Fabio's remark about the "changed status" being useless (implied) still holds. Also that user updates should somehow "stand out" compared to other entries (because it's human content vs. generated updates) that's why initially I've kept the big double quotes. Anyway those are minor tweaks, I agree with the general idea. Thanks, Jerome. ----- Original Message ----- From: "Ecaterina Valica" <valicac(a)gmail.com> To: "XWiki Developers" <devs(a)xwiki.org> Sent: Thursday, September 2, 2010 5:38:35 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [xwiki-devs] [Proposal][UX] Recent Changes Improvements Changed: - User / Application View http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ActivityStream… - Page Items Collapsed View (shows not just the last change, but all the changes for the current day ) http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ActivityStream… - Page Items Expanded View http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ActivityStream… - Prototype (lots of things broken) - press the arrow to expand http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamP31D Thanks, Caty _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

15 years

5
5
0 0

Re: [xwiki-devs] [Proposal][UX] Recent Changes Improvements

by Jerome Velociter

----- "Fabio Mancinelli" <fabio.mancinelli(a)xwiki.com> wrote: > On 09/02/2010 11:13 AM, Ecaterina Valica wrote: > > >>> Another little remark: I think that user (and application) > updates > >>> should be expanded by default without needing the user to click in > order > >>> to show the actual message. > > > > If we gonna have in the future something like this > > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/AvatarsProposa… > > where we can put also the status in, then in order to see the status > message > > you could just hover the name of the user and you are not gonna have > to > > click on it. > > > > For me, expanding statuses and application and not pages is > inconsistency. > > > > Also, we can have in the filters (don't know where) an "Expand / > Collapse > > All" option for people that have a certain preference in > displaying. > > > > > > IMHO, I think that the information and functionality of the "Changed > status" toggle adds unneeded complexity: when the user sees the avatar > > icon in the activity stream she already knows that a "status has > changed", this information is already conveyed by the fact that an > entry > of that type exists! Moreover a status update will contain, il 90% of > > the cases, a single message so 90% of the "Changed status" expansion > will contain only 1 item. > > For documents is different because changes can be a lot so the "4 > changes by 3 contributors" conveys additional information. > > What could be done to solve the "consistency" issue is to always > display > the first item and hide the others in the collapsed list. > > * So for single status updates you will have the status update > directly > displayed. +1 And it would not shock me either if the style differs a little from the document updates : no icon but directly the user picture, a bit bigger than icons. Jerome. > > * For multiple status updates by the same user you will have the last > > one + a "3 more..." hidden behind the toggle > > * For document updates with a single change you will just have the > change that has been done > > * For documents with multiple changes you will have just the latest > change + "X more changes by Y contributors" toggle with the rest. > > This would also solve the problem of having an activity stream > filtered > only by "status updates" where the user has to click every time on > "expand all" in order to actually have the information which should be > > available (and expected) by default. > > WDYT? > > -Fabio > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

15 years

3
2
0 0

Re: [xwiki-devs] [Proposal] Roadmap for XE 2.5 (Status as of 2010/09/02)

by Jerome Velociter

----- "Vincent Massol" <vincent(a)massol.net> wrote: > Thanks Sergiu for taking over during my holidays. > > Now let's see where we stand today. Could everyone with tasks to be > implemented for 2.5 please provide a one line summary under each item > below stating the status and whether there'll be issues to complete > the implementation during the defined timeframe? > > - Improved edit modes UI (Sergiu/Marta) > - Office Preview (Marius) > - Action menu improvements (Caty, JV, Sergiu) > - Export UI improvements (Caty, Sergiu) > - "Email this page" feature (Sergiu) > - User Directory (JV or Jerome - can't remember - to commit Raluca's > work) > - Portlet integration (Marius) > - Dashboards/Gadgets (Anca) > - More UI standards (avatars, floating document menu, icons, forms) > (Caty + Sergiu/Marta) > - Improved performance (Caleb, Alex?) > - Improved security (Caleb, Alex) > - WYSIWYG bugfixing and optimization (Marius) > - More 2.0 macros (JV) > - Rendering bugfixing and improvements (Thomas) > - Extension Manager 1st very basic version (Thomas) > - Recent changes (Caty, JV) > - Localization module (Sergiu or Thomas?) > > Possible New features (optional): > - Layout Themes (Sergiu) > - Wiki Import (Thomas) > - spotlight like search (Jerome) I can't promise anything since I will be off most of the remaining 2.5 timeframe, BUT I will try as much as I can to make it happen, at least I will commit what we have already in the sandbox and start cleaning it. Will keep you informed, Jerome. > > Also, we need to release 2.5M1 ASAP (waiting for JV to come back from > holiday tomorrow. > > Thanks > -Vincent > > On Aug 24, 2010, at 12:17 AM, Sergiu Dumitriu wrote: > > > Hi devs, > > > > I just realized that there was no official roadmap proposal for XE > 2.5 > > yet, since Vincent, the usual release manager, is on holidays. I > > volunteered for performing the releases, so I'll assume the release > > > manager role as well until Vincent returns. > > > > Proposed features for the 2.5 release: > > > > - Improved edit modes UI (Sergiu/Marta) > > - Office Preview (Marius) > > - Action menu improvements (Caty, JV, Sergiu) > > - Export UI improvements (Caty, Sergiu) > > - "Email this page" feature (Sergiu) > > - User Directory (JV or Jerome - can't remember - to commit Raluca's > work) > > - Portlet integration (Marius) > > - Gadgets (Anca) > > > > Generic stuff: > > - More UI standards (avatars, icons, forms) (Caty + Sergiu/Marta) > > - Improved performance (Caleb) > > - Improved security (Caleb, Alex) > > - WYSIWYG bugfixing and optimization (Marius) > > - More 2.0 macros (JV) > > > > Possible New features: > > - Layout Themes (Sergiu) > > - Wiki Import (Thomas) > > > > Proposed dates: > > > > - 2.5M1: 30 Aug > > - 2.5M2: 27 Sep > > - 2.5RC1: 11 Oct > > - 2.5RC2/Final: 25 Oct > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

15 years

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] r30796 - platform/web/trunk/standard/src/main/webapp/WEB-INF

by Vincent Massol

On Aug 30, 2010, at 5:15 PM, abusenius (SVN) wrote: > Author: abusenius > Date: 2010-08-30 17:15:09 +0200 (Mon, 30 Aug 2010) > New Revision: 30796 > > Modified: > platform/web/trunk/standard/src/main/webapp/WEB-INF/web.xml > Log: > Updated SetCharacterEncodingFilter class in web.xml after moving > > Modified: platform/web/trunk/standard/src/main/webapp/WEB-INF/web.xml > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/WEB-INF/web.xml 2010-08-30 14:31:45 UTC (rev 30795) > +++ platform/web/trunk/standard/src/main/webapp/WEB-INF/web.xml 2010-08-30 15:15:09 UTC (rev 30796) > @@ -22,7 +22,7 @@ > without affecting the whole container (and the other applications hosted). --> > <filter> > <filter-name>Set Character Encoding</filter-name> > - <filter-class>com.xpn.xwiki.web.SetCharacterEncodingFilter</filter-class> > + <filter-class>org.xwiki.container.servlet.filters.internal.SetCharacterEncodingFilter</filter-class> This is going to cause problems to users when they upgrade... We need to make it as easy as possible: - deprecate the old class but keep it - add what needs to be done in the release notes. WDYT? Thanks -Vincent >  > <init-param>

15 years

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r30768 - enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui

by Vincent Massol

Cool to have a test for this, thanks Alex. However I think that in the near future we need to find a way to write these type of tests as unit tests instead of functional tests since otherwise we're going to have too many functional tests, which will lead to the following problems: - take a lot of time to execute (and hence are not executed often + need more machines, etc) - are hard to debug when they fail (since they're not unit tests) - do not make us improve the design of the code WDYT? Thanks -Vincent PS: I haven't looked at this example in particular and my comment is general. Maybe this is testing old code which would need some heavy refactoring before we can write a unit test for it. On Aug 27, 2010, at 11:33 AM, abusenius (SVN) wrote: > Author: abusenius > Date: 2010-08-27 11:33:57 +0200 (Fri, 27 Aug 2010) > New Revision: 30768 > > Modified: > enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/LoginTest.java > Log: > XWIKI-5434: Added a functional test > > Modified: enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/LoginTest.java > =================================================================== > --- enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/LoginTest.java 2010-08-27 09:30:38 UTC (rev 30767) > +++ enterprise/trunk/distribution-test/ui-tests/src/test/it/org/xwiki/it/ui/LoginTest.java 2010-08-27 09:33:57 UTC (rev 30768) > @@ -26,6 +26,7 @@ > import org.xwiki.it.ui.administration.elements.GlobalRightsPage; > import org.xwiki.it.ui.framework.AbstractTest; > import org.xwiki.it.ui.framework.elements.LoginPage; > +import org.xwiki.it.ui.framework.elements.editor.WikiEditPage; > import org.xwiki.it.ui.xe.elements.HomePage; > > /** > @@ -114,4 +115,31 @@ > rights.unforceAuthenticatedView(); > } > } > + > + @Test > + public void testRedirectPreservesPOSTParameters() throws InterruptedException > + { > + String test = "Test string " + System.currentTimeMillis(); > + final String space = "Main"; > + final String page = "POSTTest"; > + LoginPage loginPage = this.homePage.clickLogin(); > + loginPage.loginAsAdmin(); > + // start editing a page > + WikiEditPage editPage = new WikiEditPage(); > + editPage.switchToEdit(space, page); > + editPage.setTitle(test); > + editPage.setContent(test); > + // emulate expired session: delete the cookies > + getDriver().manage().deleteAllCookies(); > + // try to save > + editPage.clickSaveAndView(); > + // we should have been redirected to login > + Assert.assertTrue(getDriver().getCurrentUrl().startsWith(getUtil().getURL("XWiki", "XWikiLogin", "login"))); > + loginPage.loginAsAdmin(); > + // we should have been redirected back to view, and the page should have been saved > + Assert.assertTrue(getDriver().getCurrentUrl().startsWith(getUtil().getURL(space, page))); > + editPage.switchToEdit(space, page); > + Assert.assertEquals(test, editPage.getTitle()); > + Assert.assertEquals(test, editPage.getContent()); > + } > } > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

15 years

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r30697 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util

by Vincent Massol

IMO we'll need to find a better place than Util for this since Util is meant to be deprecated and we should slim it down instead. Thanks -Vincent On Aug 18, 2010, at 11:44 PM, abusenius (SVN) wrote: > Author: abusenius > Date: 2010-08-18 23:44:07 +0200 (Wed, 18 Aug 2010) > New Revision: 30697 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util/Util.java > Log: > Added Util.normalizeLanguage(String) > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util/Util.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util/Util.java 2010-08-18 19:11:05 UTC (rev 30696) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/util/Util.java 2010-08-18 21:44:07 UTC (rev 30697) > @@ -37,7 +37,9 @@ > import java.util.HashSet; > import java.util.Hashtable; > import java.util.List; > +import java.util.Locale; > import java.util.Map; > +import java.util.MissingResourceException; > import java.util.Set; > import java.util.Vector; > > @@ -880,4 +882,54 @@ > > return Thread.currentThread().getContextClassLoader().getResourceAsStream(resource); > } > + > + /** > + * Normalize the given language code. Converts the given language code to lower case and checks its validity (i.e. > + * whether it is an ISO 639 language code or the string "default"). > + * <p><pre> > + * Util.normalizeLanguage(null) = null > + * Util.normalizeLanguage("") = "" > + * Util.normalizeLanguage(" ") = "" > + * Util.normalizeLanguage("default") = "default" > + * Util.normalizeLanguage("DeFault") = "default" > + * Util.normalizeLanguage("invalid") = "default" > + * Util.normalizeLanguage("en") = "en" > + * Util.normalizeLanguage("DE_at") = "de_AT" > + * </pre></p> > + * > + * @param languageCode the language code to normalize > + * @return normalized language code or the string "default" if the code is invalid > + */ > + public static String normalizeLanguage(String languageCode) > + { > + if (languageCode == null) { > + return null; > + } > + if (StringUtils.isBlank(languageCode)) { > + return ""; > + } > + // handle language_COUNTRY case > + final String separator = "_"; > + String[] parts = languageCode.toLowerCase().split(separator); > + String result = parts[0]; > + if (parts.length > 1) { > + parts[1] = parts[1].toUpperCase(); > + // NOTE cannot use Locale#toString(), because it would change some language codes > + result = parts[0] + separator + parts[1]; > + } > + // handle the "default" case > + final String defaultLanguage = "default"; > + if (defaultLanguage.equals(result)) { > + return defaultLanguage; > + } > + try { > + Locale l = new Locale(parts[0], parts.length > 1 ? parts[1] : ""); > + // Will throw an exception if the language code is not valid > + l.getISO3Language(); > + return result; > + } catch (MissingResourceException ex) { > + LOG.warn("Invalid language: " + languageCode); > + } > + return defaultLanguage; > + } > }

15 years

3
2
0 0

[xwiki-devs] [Contrib] Log Application

by Flavius Olaru

Hi devs, I would like to contribute on svn an application i have developed that logs messages from velocity and groovy code blocks. It uses XWiki objects and does not require changes in XE installation to work. Only requires PR rights for groovy scripts to work. Currently the application can be found at http://flavius.myxwiki.org/xwiki/bin/view/Log/. I only require commit rights to contrib sandbox to get started. SVN username: flavius Thanks, -- XWiki SAS Web Developer Flavius Olaru

15 years

2
1
0 0

Re: [xwiki-devs] [Proposal][UX] Recent Changes Improvements

by Jerome Velociter

I still strongly believe that user photos should appear in the stream before any click. Especially for user updates instead of the "user.gif" icon. Thanks Jerome. ----- "Ecaterina Valica" <valicac(a)gmail.com> wrote: > Added: > - Application + User Changes > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ActivityStream… > > - Feed + Filters > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ActivityStream… > > Prototype: > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamP3D > > Thanks, > Caty > > > On Tue, Aug 31, 2010 at 11:35, Fabio Mancinelli > <fabio.mancinelli(a)xwiki.com>wrote: > > > On 08/30/2010 07:16 PM, Jerome Velociter wrote: > > > > >> The "user centric" view, imho, is also useful because a "user" > could > > >> also be an application that sends events (e.g., meeting or > deadlines > > >> reminders, etc.) that can be shown in a more natural way in a > user > > >> centric view. Basically even applications might share their > thoughts > > >> through the activity stream ;) > > > > > > I completely agree with the last sentence. BUT I think it's not > > incompatible with a document/user mixed-approched (I don't think > either full > > document-centric or full user-centric can embrace the versatility of > XWiki) > > > > > > I see two types of entries : > > > > > > * Document updates. Basically what is currently in latest > proposal > > (though I would add little user pictures here as well, even before > the > > click). This is KM, collaboration, etc. > > > * Users/applications updates. Those are less structured, more > a-la > > facebook. > > > > > > I see something like > > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamMixe… > picture, would have to be refined) > > > (Note I also have right-padded a bit more the > > comment/annotation/pencil/etc icons that are on top of user photos, > I think > > they were a bit too masked by them) > > > > > I would have called that version "user centric" as well since > documents > > updates might be seen as posts done by the "XWiki system" user :) > > > > Anyway, I think that the mixed approach is fine. > > > > -Fabio > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

15 years

4
6
0 0

[xwiki-devs] Supress contents from PDF export

by Luiz Marcelo Serique

Hu guys, there is any way to supress content parts from the pdf report? Here is the problem: Most of pages have a toc macro with this code {{box cssClass="floatinginfobox"}} {{toc depth="3"/}} {{/box}} As we know, the pdf report also puts a toc page. My reports are getting two tocs, one from report and one from content. But i do not want to remove de pdf toc because some wiki pages do not have the content toc. There is a way to supress the content toc from appearing in the pdf report? thanks -- L. Marcelo Serique

15 years

4
8
0 0

Re: [xwiki-devs] [xwiki-notifications] r30816 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api

by Sergiu Dumitriu

On 09/01/2010 12:13 PM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-09-01 12:13:53 +0200 (Wed, 01 Sep 2010) > New Revision: 30816 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/Document.java > Log: > XWIKI-1962: $doc.removeObject causes changes to other objects to be discarded > Replaced this.doc with this.getDoc() in places where the document might be changed. You shouldn't reuse closed issue identifiers. -- Sergiu Dumitriu http://purl.org/net/sergiu/

15 years

2
2
0 0

[xwiki-devs] [discussion] Macro categories usage & multiple categories per macro

by Anca Luca

Hi guys, Short story: 1/ glorify macro categories and use them for more than presentational purposes (e.g. using a category to differentiate "gadgets" macros from other macros) 2/ allow a macro to be part of multiple categories at the same time WDYT? Long story: I have read http://markmail.org/thread/wwv56pojo6rix5zv about the current implementation for macro categories and I noticed that the discussion / approach there focuses on the presentational use of categories for macros, how to display them grouped to the user. I would say there's an important additional usecase, the usage of categories as macros metadata, describing their semantic, to allow some apps to implement different behaviour for macros in a category or another. For example, in the case of gadgets / dashboard, if a gadget would be implemented as a macro, then we'd need some sort of method to differentiate the macros that can be used as gadgets. The most 'semantic' way would be to use a gadgets category to mark the gadgets, and the dashboard implementation will allow only macros from this category to be added in the dashboard. However this approach would mean that macro category gains importance, and we need to think if it's still ok that an admin can change the category of a macro and the macro category declared by the author can be completely overwritten. WDYT about using the macro categories for much more than grouping for presentation? I'm +1, and I think that ftm there's no need to strategy change wrt to who establishes the category of a macro. Also, because of this, it's very possible that we might need a macro to be part of more than one category, because, to continue the example, we might want gadgets to also be grouped in several categories (of gadgets), or a gadget to also be included in the, say, "presentation" category of macros to be used in plain xwiki documents. WDYT? I am +1 for this as well, and ready to start building the patch (modulo some macros API changes) as soon as we all agree. Thanks, Anca

15 years

3
2
0 0

Re: [xwiki-devs] [xwiki-notifications] r30693 - platform/web/trunk/standard/src/main/webapp/templates

by Vincent Massol

Hi Alex, Great serie of commits Alex (just looking at them now since I'm back from holidays)! Just a little comment: re the svn commit comment, could you always refer to a jira issue? (I've seen several commits where there were no jira issues mentioned). Thanks a lot -Vincent On Aug 18, 2010, at 6:23 PM, abusenius (SVN) wrote: > Author: abusenius > Date: 2010-08-18 18:23:50 +0200 (Wed, 18 Aug 2010) > New Revision: 30693 > > Modified: > platform/web/trunk/standard/src/main/webapp/templates/editclass.vm > Log: > Added missing escaping to class editor. > > Modified: platform/web/trunk/standard/src/main/webapp/templates/editclass.vm > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/templates/editclass.vm 2010-08-18 16:12:24 UTC (rev 30692) > +++ platform/web/trunk/standard/src/main/webapp/templates/editclass.vm 2010-08-18 16:23:50 UTC (rev 30693) > @@ -36,10 +36,10 @@ > #if($prevSpace != '') > </optgroup> > #end > - <optgroup label="${classdoc.space}"> > + <optgroup label="${escapetool.xml($classdoc.space)}"> > #set($prevSpace = ${classdoc.space}) > #end > - <option value="$classdoc.getURL('edit', 'editor=class')">${classdoc.name}</option> > + <option value="$classdoc.getURL('edit', 'editor=class')">${escapetool.xml($classdoc.name)}</option> > #end > #end > #if($prevSpace != '') > @@ -60,9 +60,9 @@ > * Display a class property > *# > #macro(displayProperty $field) > - <div id="xproperty_$field.name" class="xproperty #if($field.disabled)disabled#end"> > + <div id="xproperty_${field.name}" class="xproperty #if($field.disabled)disabled#end"> > <div id="xproperty_${field.name}_title" class="xproperty-title ${field.type}"> > - <h2>$doc.displayView($field.xWikiClass.get('prettyName'), "${field.name}_" , $field) > + <h2>$!{escapetool.xml($doc.displayView($field.xWikiClass.get('prettyName'), "${field.name}_" , $field))} > ($doc.displayView($field.xWikiClass.get('name'), "${field.name}_" , $field): $xwiki.metaclass.get($field.classType).prettyName)</h2> > <div class="tools propertyTools"><a href='$doc.getURL('propdelete', "propname=${field.name}")' title="$msg.get('core.editors.class.deleteProperty.tooltip', [${field.name}])" class="tool delete">$msg.get('core.editors.class.deleteProperty.text')</a></div> > </div> > @@ -76,9 +76,9 @@ > #set($propDef = $field.xWikiClass.get($classprop)) > #if($hiddenProperties.indexOf($propDef.name) == -1) > #if($propDef.type.indexOf('Boolean') != -1) > - <dt class="boolean-property"><label class="hidden" for="${field.name}_$classprop">$propDef.getPrettyName()</label>$doc.displayEdit($propDef, "${field.name}_" , $field) $propDef.getPrettyName()</dt> > + <dt class="boolean-property"><label class="hidden" for="${field.name}_$classprop">${escapetool.xml($propDef.getPrettyName())}</label>$doc.displayEdit($propDef, "${field.name}_" , $field) $propDef.getPrettyName()</dt> > #else > - <dt><label for="${field.name}_$classprop">$propDef.getPrettyName() $!{propertyDetails.get($classprop)}</label></dt> > + <dt><label for="${field.name}_$classprop">${escapetool.xml($propDef.getPrettyName())} $!{propertyDetails.get($classprop)}</label></dt> > <dd>$doc.displayEdit($propDef, "${field.name}_" , $field)</dd> > #end > #end > @@ -99,7 +99,7 @@ > <label for="proptype" class="property-type-label">$msg.get('core.editors.class.addProperty.type.label'):</label> > <select id="proptype" name="proptype" size="1"> > #foreach($prop in $xwiki.metaclass.properties) > - <option value="${prop.name}">${prop.prettyName}</option> > + <option value="${prop.name}">${escapetool.xml($prop.prettyName)}</option> > #end > </select> > <span class="buttonwrapper"> > @@ -140,10 +140,10 @@ > #editActionButton('preview', 'preview') > </div> > <div id="xwikiclassproperties"> > - <div id="xclass_${class.name}" class="xclass"> > - <div id="xclass_${class.name}_title" class="xclass-title"><h2>$class.name</h2></div> > + <div id="xclass_${escapetool.xml($class.name)}" class="xclass"> > + <div id="xclass_${escapetool.xml($class.name)}_title" class="xclass-title"><h2>${escapetool.xml($class.name)}</h2></div> > #addPropertyForm() > - <div id="xclass_${class.name}_content" class="xclass-content"><div id="xclassContent"> > + <div id="xclass_${escapetool.xml($class.name)}_content" class="xclass-content"><div id="xclassContent"> > #foreach ($field in $class.properties) > #displayProperty($field) > #end > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

15 years

1
0
0 0

[xwiki-devs] [VOTE] Alex Busenius as a committer.

by Caleb James DeLisle

Hello, I have been working with Alex on security related code and have been impressed with his abilities as well as dedication to consistent improvement of the project and his own code. Alex has worked on some complex changes to difficult code such as: XWIKI-5275: Prevent nested script macros. http://jira.xwiki.org/jira/browse/XWIKI-5275 As well as a large quantity of cross site script related patches such as: XWIKI-5161: Using XML symbols (<, >, &, ") inside the document title/name/space breaks various parts of the UI and causes the PDF export to throw exceptions http://jira.xwiki.org/jira/browse/XWIKI-5161 A full list is here, most are not viewable by the public. http://jira.xwiki.org/jira/secure/ViewProfile.jspa?name=nickless#selectedTa… Alex has developed an automated cross site script fuzzing test which can be seen here: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-enterprise-test-es… He is also responsible for parts of xwiki-crypto including PKCS7 signing and validation and X509 certificate handling. see: http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-crypto/src/mai… http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-crypto/src/mai… http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-crypto/src/mai… As far as write access to the main repository, I think there is no question that he will be a good committer. It should be noted that I would be +1 for giving write access to anyone who demonstrates a need. The remaining issue is the responsibility of being on the "steering committee", having the power to -1 a vote. Alex and I agree on a lot of issues where we hold the minority position so my opinion should be taken with the salt it deserves. That said, he has the courage to voice disagreement when he has it, he takes an interest in decisions regarding the core rather than being concentrated on the user interface, and he has the ability to spot problems in design which will not become obvious until later. I think Alex Busenius will be a great committer. +1 Caleb

15 years

8
8
0 0

[xwiki-devs] Email application

by Sales, G. (Grant)

My send page by email panel isn't functional. I get a error telling me that there might be an error in the email address I've entered. This panel was installed correctly with a user that has programming rights. Any thoughts on the settings that I need to play with? Or is my version of xwiki not capable of doing this? I've been reading some of these emails and it looks like maybe in a new version of xwiki this panel will come standard, is this true? If so I can I update to the current version and also be able to delete properties in a class? Thanks for your help ~Grant Grant Sales Security Operations Analyst ING 111 Washington Ave South Minneapolis, MN 55401 Tel: 612.342.7889 Fax: 612.342.3428 Cell: 320.761.0966 Email: grant.sales(a)us.ing.com www.ing-usa.com ING. Your future. Made easier. (r) --------------------------------------------------------- NOTICE: The information contained in this electronic mail message is confidential and intended only for certain recipients. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying or disclosing it. ============================================================================================

15 years

1
2
0 0

[xwiki-devs] Wysiwyg editor and macro accessing to Alfresco (or other external tool)

by jurevert

Hi, Our goal is to develop a wysisyg macro allowing to : - Insert an Image stored on Alfresco - Insert a link to a document stored on Alfresco To do this; we have develop a small browser on Alfresco in order to choose the image to insert (img src) or the file to link (a href). After selecting the Alfresco file; we need to generate a macro like : [[Lien vers le doc toto>>http://alfresco.airfrance.fr/alfresco/.../toto.doc||rel="__blank" title="Ouvrir le doc toto..."]] or [[image:http://alfresco.airfrance.fr/alfresco/..../image.jpg]] Using the wiki editor and the old Wysiwyg editor; we had no problem to do this. (Openning popup and populate les link field with alfresco file path.) With the new editor; I can't find the way to do this. In fact my problem could be resume to add a picto in the 'link' and 'image' macro GUI allowing to open my alfresco browser in order to populate the path ! Any idea to do this ? Thanks, Julien -- View this message in context: http://xwiki.475771.n2.nabble.com/Wysiwyg-editor-and-macro-accessing-to-Alf… Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years

2
4
0 0

[xwiki-devs] [Proposal][UX] Recent Changes Improvements

by Ecaterina Valica

Hi, This is a page centric proposal for "Recent Changes": * Partial Prototype (Firefox) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamP3D * Some screenhots http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamV3 Any feedback is greatly appreciated. Thanks, Caty P.S: Older user centric proposal was http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActivityStreamV2

15 years

2
3
0 0

[xwiki-devs] [proposal] Move servlet filters out of the core

by Alex Busenius

Hi devs, I propose to move servlet filters out of the old core to xwiki-container-servlet. There are 3 filters, com.xpn.xwiki.web.SetCharacterEncodingFilter com.xpn.xwiki.web.SavedRequestRestorerFilter com.xpn.xwiki.web.ActionFilter They are almost self-contained (except for ActionFilter, see a note later) and are easy to move. Moreover, SavedRequestRestorerFilter offers functionality to save the request, that might also be useful in other places (like csrf-token). There is (currently) no need for portlet filters, so moving filters into a separate module doesn't seem to be worth it. Since the filters are not used directly, I'd move them into org.xwiki.container.servlet.filters.internal and public methods used elsewhere into org.xwiki.container.servlet.filters. Note that xwiki-core would become dependent on xwiki-container-servlet (it currently depends on container-api), but it shouldn't be a problem. In more detail, * SetCharacterEncodingFilter would be moved as is to filters.internal. * SavedRequestRestorerFilter would be split into the actual filter and SavedRequestManager that would contain the static methods String getOriginalUrl(HttpServletRequest) String saveRequest(HttpServletRequest) String getRequestIdentifier() SavedRequestManager could also be a component, but it would make it more complicated to use from the filter. * ActionFilter should be moved to filters.internal too, but it uses XWiki.stripSegmentFromPath(String, String) to parse the URL and replace the action part by the stored value. There are 2 other copies of the URL parsing code that uses stripSegmentFromPath(...), in XWiki.getDocumentReference(...) and XWiki.getXWiki(...), I can think of 3 alternatives: 1. Leave ActionFilter in the core 2. Move URL parsing code into xwiki-url, i.e. add/implement missing methods to create XWikiURL from string representation and extract host, action, document reference and parameters from it. 3. Move stripSegmentFromPath(...) to xwiki-container-servlet too I'm +1 for 2, since it's the cleanest option. WDYT? Thanks, Alex

15 years

5
7
0 0

[xwiki-devs] [Proposal] Stop logging errors when a wiki macro cannot be registered due to insufficient privileges for the asked visibility

by Jerome Velociter

Hi friends, I'm proposing a patch (see http://jira.xwiki.org/jira/browse/XWIKI-5439) to stop logging a full exception at error level when the wiki fails to register a wiki macro due to insufficient privileges for the asked visibility. This is currently what happens, and it can trash your log, for example if you initialize a farm with hundreds of wikis throwing couple of times such error :) Thing is this is not a real error, in the sense "something went wrong" so it should be logged at the debug level. The patch introduce a new exception : org.xwiki.rendering.macro.wikibridge.InsufficientPrivilegesException, which when caught by the wiki macro initializer is logged at debug level, by opposition of the more generic org.xwiki.rendering.macro.wikibridge.WikiMacroException that remains logged at error level. I'm calling for a vote since the patch introduce a API signature change. Though I tend to think it's internal enough not to go through deprecation cycle. My +1 Jerome.

15 years

6
6
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