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

[xwiki-devs] [Proposal] Front End Architecture

by Vincent Massol

Hi, I've started thinking with Thomas about the new front end architecture and here's our current idea (without details) for the future: http://dev.xwiki.org/xwiki/bin/view/Design/FrontEndArchitecture If you have ideas about this please send them. This message is there so that we can share a common vision for the future. Thanks -Vincent

15 years, 3 months

3
5
0 0

[xwiki-devs] [Proposal] Selective Export UI

by Ecaterina Valica

Hi, Please provide feedback for the Selective Export UI: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MultiExportProposal PS. The HTML+CSS is not final and it's tested only in Firefox. It will be improved if it gets positive feedback. If it doesn't display correctly, please use the IMG to visualize. Thanks, Caty

15 years, 3 months

8
26
0 0

Re: [xwiki-devs] [xwiki-notifications] r29713 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP

by Vincent Massol

On Jun 24, 2010, at 5:47 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-06-24 17:47:52 +0200 (Thu, 24 Jun 2010) > New Revision: 29713 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java > Log: > [misc] More useful debug log > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java 2010-06-24 15:47:15 UTC (rev 29712) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java 2010-06-24 15:47:52 UTC (rev 29713) > @@ -417,7 +417,7 @@ > String passwordField = config.getLDAPParam("ldap_password_field", "userPassword", context); > if (!connector.checkPassword(ldapDn, password, passwordField)) { > LOG.debug("Password comparision failed, are you really sure you need validate_password ?" + > - " If you don't enable it it does not mean use credentiel are not validated." + > + " If you don't enable it it does not mean user credentiels are not validated." + typo: credentials :) -Vincent > " The goal of this property is to bypass standard LDAP bind."); > > throw new XWikiException(XWikiException.MODULE_XWIKI_USER, XWikiException.ERROR_XWIKI_USER_INIT, > >

15 years, 3 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r29712 - platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP

by Vincent Massol

On Jun 24, 2010, at 5:47 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-06-24 17:47:15 +0200 (Thu, 24 Jun 2010) > New Revision: 29712 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java > Log: > [misc] More useful debug log > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java 2010-06-24 15:43:19 UTC (rev 29711) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/user/impl/LDAP/XWikiLDAPAuthServiceImpl.java 2010-06-24 15:47:15 UTC (rev 29712) > @@ -416,6 +416,10 @@ > if ("1".equals(config.getLDAPParam("ldap_validate_password", "0", context))) { > String passwordField = config.getLDAPParam("ldap_password_field", "userPassword", context); > if (!connector.checkPassword(ldapDn, password, passwordField)) { > + LOG.debug("Password comparision failed, are you really sure you need validate_password ?" + typo: comparison. -Vincent > + " If you don't enable it it does not mean use credentiel are not validated." + > + " The goal of this property is to bypass standard LDAP bind."); > + > throw new XWikiException(XWikiException.MODULE_XWIKI_USER, XWikiException.ERROR_XWIKI_USER_INIT, > "LDAP authentication failed:" + " could not validate the password: wrong password for " + ldapDn); > }

15 years, 3 months

1
0
0 0

[xwiki-devs] [VOTE] [wysiwyg] Displaying the macro id and searching for it in the wysiwyg insert macro wizard

by Anca Luca

Hi all, I wanted to insert a macro in a page using the wysiwyg and I noticed that the macros filter (search box on top right) is not searching in the macro ids. For example, if I try to write "toc" I get no results. If I write "table" I get the "Table of contents" macro as result, since its name matches. I found this a bit annoying in my case, since i know the macroid (if I were to write it in the wiki syntax) and I cannot find the macro (still, I'm using the wysiwyg because I can never remember macro params). Also, I use the search function because it's far easier to filter it out then scroll for it in the list. WDYT about searching in the macro ids as well? (1) Also, the macro id is not displayed. This is good for simple users for which it has no meaning, but there can be a situation when 2 macros have the same name and same description (e.g. void description) and users would want to be able to differentiate one from the other in the macros list, even the simple users, I would say (for example because they always want to use one macro of the 2 and they can never tell one from the other only by name). WDYT about displaying the macro is as well? (2) of course pretty small and greyed out, like some advanced metadata. Marius said it's no big deal to implement neither, as long as we agree. My +1 for both (1) and (2). Thanks, Anca

15 years, 3 months

9
9
0 0

[xwiki-devs] Invitation application icon

by Caleb James DeLisle

Hello, Since the invitation application is in XE, I was wondering if anyone wanted to try putting together an icon for the invitation section in the administration interface. Sorry about the short notice, if you're all busy that's fine, I can slap something together but it won't be nearly as good as some of the stuff I've seen (search icon). Any takers? Thanks, Caleb

15 years, 3 months

8
16
0 0

Re: [xwiki-devs] [xwiki-notifications] r29668 - in enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium: . framework

by Vincent Massol

On Jun 23, 2010, at 12:40 PM, mflorea (SVN) wrote: > Author: mflorea > Date: 2010-06-23 12:40:12 +0200 (Wed, 23 Jun 2010) > New Revision: 29668 > > Modified: > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/EditInlineTest.java > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/framework/AbstractWysiwygTestCase.java > enterprise/trunk/distribution-test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/framework/WysiwygTestSetup.java > Log: > Fixed WYSIWYG Selenium tests due to changes in the class editor. [snip] > + > + /** > + * Clicks the add property button in the class editor. > + */ > + public void clickEditAddProperty() > + { > + getSelenium().click("//input[@value = 'Add']"); > + waitForCondition("(window.document.getElementsByClassName('xnotification-done')[0] != null " > + + "&& window.document.getElementsByClassName('xnotification-done')[0].innerHTML == 'Property added')"); > + } Shouldn't this go in the general framework in selenium-tests? Is there anything specific to the wysiwyg? Thanks -Vincent [snip]

15 years, 3 months

2
1
0 0

[xwiki-devs] [Proposal] Package organization for ui-tests

by Vincent Massol

Hi devs, I'm proposing to have org.xwiki.it.ui.elements.<application name> where <application name> is the name of the application containing the page. WDYT? Thanks -Vincent

15 years, 3 months

5
15
0 0

[xwiki-devs] Create User in XWiki from REST Api

by xManish

Hello, I was able to create a wiki page through API but got stuck while trying to create a wiki user following same way. Here is the code on how I created the wiki page. Can you advise me how to create the wiki user in the similiar manner? public void myAddMethod() { final String CONTENT = "Content 101"; final String TITLE = "Title 101"; final String PARENT = "Private.WebHome"; ObjectFactory objectFactory = new ObjectFactory(); Page page = objectFactory.createPage(); page.setContent(CONTENT); page.setTitle(TITLE); page.setParent(PARENT); HttpClient httpClient = new HttpClient(); httpClient.getState().setCredentials(AuthScope.ANY, new UsernamePasswordCredentials("admin", "admin")); httpClient.getParams().setAuthenticationPreemptive(true); JAXBContext context; try { context = JAXBContext.newInstance("org.xwiki.rest.model.jaxb"); Marshaller marshaller = context.createMarshaller(); Unmarshaller unmarshaller = context.createUnmarshaller(); PutMethod putMethod = new PutMethod("http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Private/pages/NewPage01"); putMethod.addRequestHeader("Accept", MediaType.APPLICATION_XML.toString()); StringWriter writer = new StringWriter(); marshaller.marshal(page, writer); RequestEntity entity; entity = new StringRequestEntity(writer.toString(), MediaType.APPLICATION_XML.toString(), "UTF-8"); putMethod.setRequestEntity(entity); httpClient.executeMethod(putMethod); } catch (JAXBException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (UnsupportedEncodingException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (HttpException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } -- View this message in context: http://xwiki.475771.n2.nabble.com/Create-User-in-XWiki-from-REST-Api-tp5209… Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 3 months

1
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r29639 - platform/web/trunk/standard/src/main/webapp/resources/js/xwiki

by Marius Dumitru Florea

On 06/22/2010 08:15 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-06-22 19:15:28 +0200 (Tue, 22 Jun 2010) > New Revision: 29639 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > Log: > XWIKI-5300: Start writing a Javascript mirror of the XWiki data model: Document.getURL > Done. The code below won't work in portlet mode because: * portlet URL format is an implementation detail for portlet containers * portlet URL parameters are not included in clear but rather encoded as a single query string parameter (checked in GateIn and WebSphere) * query string parameters appended to a portlet URL are not accessible to the targeted portlet My question is: do we really need to compute URLs on the client? (even if compute = string replace) Thanks, Marius > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2010-06-22 16:51:34 UTC (rev 29638) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/xwiki/xwiki.js 2010-06-22 17:15:28 UTC (rev 29639) > @@ -1295,6 +1295,69 @@ > } > var browser = new BrowserDetect(); > > +/** > + * XWiki Model access APIs. > + */ > +XWiki.Document = Class.create({ > + /** > + * Constructor. All parameters are optional, and default to the current document location. > + */ > + initialize : function(page, space, wiki) { > + this.page = page || XWiki.Document.currentPage; > + this.space = space || XWiki.Document.currentSpace; > + this.wiki = wiki || XWiki.Document.currentWiki; > + }, > + /** > + * Gets an URL pointing to this document. > + */ > + getURL : function(action, queryString, fragment) { > + action = action || 'view'; > + var url = XWiki.Document.URLTemplate; > + url = url.replace("__space__", encodeURIComponent(this.space)); > + url = url.replace("__page__", (this.page == 'WebHome') ? '' : encodeURIComponent(this.page)); > + url = url.replace("__action__/", (action == 'view') ? '' : (encodeURIComponent(action) + "/")); > + if (queryString) { > + url += '?' + queryString; > + } > + if (fragment) { > + url += '#' + fragment; > + } > + return url; > + }, > + /** > + * Gets an URL which points to the REST location for accessing this document. > + */ > + getRestURL : function(entity, queryString) { > + entity = entity || ''; > + var url = XWiki.Document.RestURLTemplate; > + url = url.replace("__wiki__", this.wiki); > + url = url.replace("__space__", this.space); > + url = url.replace("__page__", this.page); > + if (entity) { > + url += "/" + entity; > + } > + if (queryString) { > + url += '?' + queryString; > + } > + return url; > + } > +}); > + > +/* Initialize the document URL factory, and create XWiki.currentDocument. */ > +document.observe('dom:loaded', function() { > + XWiki.Document.currentWiki = ($$("meta[name=wiki]").length> 0) ? $$("meta[name=wiki]")[0].content : "xwiki"; > + XWiki.Document.currentSpace = ($$("meta[name=space]").length> 0) ? $$("meta[name=space]")[0].content : "Main"; > + XWiki.Document.currentPage = ($$("meta[name=page]").length> 0) ? $$("meta[name=page]")[0].content : "WebHome"; > + XWiki.Document.URLTemplate = "$xwiki.getURL('__space__.__page__', '__action__')"; > + XWiki.Document.RestURLTemplate = "${request.contextPath}/rest/wikis/__wiki__/spaces/__space__/pages/__page__"; > + XWiki.Document.RestSearchURLStub = "${request.contextPath}/rest/wikis/__wiki__/search"; > + XWiki.Document.getRestSearchURL = function(wiki) { > + wiki = wiki || XWiki.Document.currentWiki; > + return XWiki.Document.RestSearchURLStub.replace("__wiki__", wiki); > + }; > + XWiki.currentDocument = new XWiki.Document(); > +}); > + > /* > * Small JS improvement, which automatically hides and reinserts the default text for input fields, acting as a tip. > * > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

15 years, 3 months

2
2
0 0

[xwiki-devs] [VOTE] Put XWiki Invitation Manager Plugin jira project in XWiki Retired Projects section

by Thomas Mortagne

Hi devs, Since the new invitation application is not based on it doubt we will ever work on this plugin. WDYT ? Here is my +1 -- Thomas Mortagne

15 years, 3 months

5
5
0 0

[xwiki-devs] Modify page creation details without causing an update.. :S

by JoannaD

Hi all Is there any way of modifying the creation details (or any other property) of a page/doc without really causing/trigerring an update? What I intend to do is modify the creator and the creation date as they were messed up during import but I need the author and the date to remain unchanged.. Any ideas? Thank you! Joanna D. ----- Joanna -- Please consider the environment -- -- View this message in context: http://xwiki.475771.n2.nabble.com/Modify-page-creation-details-without-caus… Sent from the XWiki- Dev mailing list archive at Nabble.com.

15 years, 3 months

2
3
0 0

Re: [xwiki-devs] [VOTE] (Results) Apply code style to imports

by Denis Gervalle

4 +1, 1 +0, 0 -1; applied XTVERIFICATIONS-10 in r29627 Denis On Tue, Jun 22, 2010 at 10:07, Vincent Massol <vincent(a)massol.net> wrote: > +0 > > Thanks > -Vincent > > On Jun 22, 2010, at 9:17 AM, Denis Gervalle wrote: > > > Well, > > > > Based on your feedback, the easiest and probably best solution is to keep > > the default for Eclipse (so, no need for a special config file) and to > > configure IntelliJ code style (it is the same file for all) to do the > same > > as Eclipse, which will avoid confusion: > > > > import java.* > > > > import javax.* > > > > import org.* > > > > import com.* > > > > This choice already have a +1 from Marius, a +1 from Sergiu and here is > my > > +1. > > I do not think we need long discussion on this, just an agreement, please > > could you cast your vote on this. > > > > Denis > > > > On Mon, Jun 21, 2010 at 16:13, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote: > > > >> On 06/21/2010 04:04 PM, Marius Dumitru Florea wrote: > >>> On 06/21/2010 02:36 PM, Denis Gervalle wrote: > >>>> On Mon, Jun 21, 2010 at 13:24, Marius Dumitru Florea< > >>>> mariusdumitru.florea(a)xwiki.com> wrote: > >>>> > >>>>> Hi Denis, > >>>>> > >>>>> On 06/21/2010 01:55 PM, Denis Gervalle wrote: > >>>>>> Hi Devs, > >>>>>> > >>>>>> Currently we do not have any code style specification for imports. > To > >>>>>> improve clarity of our commits, I propose that we decide once for > all > >> how > >>>>> we > >>>>>> would like to have imports. Of course, normalisation of existing > code > >>>>> will > >>>>>> come with normal commit, I do not intend to update it only for that. > >>>>> > >>>>> Are you saying that > >>>>> > >>>>> > >> > http://svn.xwiki.org/svnroot/xwiki/platform/xwiki-tools/trunk/xwiki-verific… > >>>>> doesn't include information about import styles? > >>>>> > >>>> > >>>> Sorry, I do not have Eclipse, maybe Thomas could precise this point. > >>>> What I am saying is that we do not have any written code style for > that, > >> and > >>>> we use the default of the IDE. > >>>> > >>>>> > >>>>>> > >>>>>> Currently, > >>>>>> > >>>>>> Eclipse does java.*, org.*, com.* separated by blank lines > >>>>>> IntelliJ IDEA does com.*,org.* together, than a blank line and > java.* > >>>>> > >>>>> So you're saying that codestyle-eclipse.xml and codestyle-idea.xml > are > >>>>> not consistent? > >>>>> > >>>> > >>>> There are not, probably because we have never look at it and their > >> defaults > >>>> differ. > >>> > >>> I see. It's clear now. > >>> > >>>> > >>>> > >>>>> > >>>>>> Old existing code has there own ordering... > >>>>>> > >>>>>> I propose the following style: > >>>>>> > >>>>>> import java.* > >>>>>> > >>>>>> import org.* > >>>>>> import com.* > >>>>>> import<anything else> > >>>>>> > >>> > >>>>>> import org.xwiki.* > >>>>>> import com.xpn.* > >>> > >>> I don't think separating this imports from org.* and com.* makes them > >>> much more visible. Also, for classes that don't depend on the old core > >>> (com.xpn.*) moving org.xwiki.* out of org.* breaks the order. Since > >>> we'll eventually drop the com.xpn.* package in favor of org.xwiki.* I > >>> think we should keep XWiki's imports under org.* and com.* . > >>> > >>> I'm +1 for enforcing a style for imports. I'm -0 for separating > >>> org.xwiki.* and com.xpn.* from org.* and com.* respectively. > >>> > >> > >> Same as Marius. > >> > >>> > >>>>>> > >>>>>> import static<any> > >>>>>> > >>>>>> If we agree on this, necessary IDE setup for both Eclipse and > IntelliJ > >>>>>> should be prepare/updated. I will take IntelliJ in charge, a > volunteer > >>>>> for > >>>>>> Eclipse is welcome (Thomas?) > >>>>> > >>>>> You mean update codestyle-eclipse.xml and codestyle-idea.xml ? > >>>>> > >>>> > >>>> Yes, and if this is not part of codestyle-eclipse, provide what is > >> required > >>>> to have both IDE in sync. > >>>> > >>>> Denis > >>>> > >>>> > >>>>> > >>>>> Thanks, > >>>>> Marius > >>>>> > >>>>>> > >>>>>> WDYT ? > >>>>>> > >>>>>> Denis > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

15 years, 3 months

1
0
0 0

[xwiki-devs] [VOTE] Templates Administration Icon

by Jean-Vincent Drean

Hi, For the moment the templates administration section [1] uses the default icon. Ciprian made a bunch of proposals for it and I'd like to commit one of them asap: http://incubator.myxwiki.org/xwiki/bin/view/Ciprian/Template%20icon Here's my +1 for 5a. [1] http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication… Thanks, JV.

15 years, 3 months

11
11
0 0

[xwiki-devs] [Idea] "Modern" skin for "modern" browsers

by Ecaterina Valica

Hi, When the CSS3 fever began, Raluca Stavro came to me and asked me what I think about making a HTML5+CSS3 skin. My first answer was that is not gonna happen. We invest very much in making our skins have cross-browser support (especially old versions of IE). This is one of our strengths, but also the reason we limit ourselves from innovation. When I'm talking about a "modern" skin I'm not only referring about HTML, JS, CSS (having transparency, corners, multiple backgrounds, shadows without having to triple the code and the number of hacks), but it's about all cool/experimentation features, that boosts productivity, minimize code lines, etc. but lack all/old browser support (SVG, location awareness, CSS3 calc etc). So, in my opinion this would be an experimentation/shiny skin that by comparison would make old browsers supporters and lovers to quit their old behaviors and embrace the future :) :p So, the questions I have are: 1) would this be possible? would anyone want to do this sort of thing? I know the biggest problem is gonna be the maintenance, but could bring lots of innovation and productivity. 2) what feature/improvement/thing do you think it would be the most needed for a new "modern" "skin" (the topic somehow go beyond the skin boundaries)? Thanks, Caty

15 years, 3 months

4
3
0 0

[xwiki-devs] [PROPOSAL] Use openoffice server when its enabled to do PDF/RTF export

by Thomas Mortagne

Hi devs, Really fixing http://jira.xwiki.org/jira/browse/XWIKI-5251 as it is is a real pain, i.e. using FOP. That would need a XSLT wizard and anyway RTF support is not very good in FOP (according to FOP documentation). And seriously for a format like RTF it's a waste of time IMO. So what i propose for 2.4 is to do a small modification to PDF/RTF exporter to use openoffice server when it's connected. There is already everything needed for that in openoffice component which is used for office import currently. That would be a good POC for the future office exporter which will need a lot of refactoring and API to be clean. For this proposal I'm just modifying PdfExportImpl is a as clean as possible way to have this in 2.4. The only limitation currently is that OpenOffice does not really support XHTML and parse the content as it was HTML but since we have the same constraint with IE6 it's OK for now I guess. See http://qa.openoffice.org/issues/show_bug.cgi?id=69635 for more. WDYT ? We should probably not show RTF export in the menu when openoffice server is not connected since it does not work at all even with empty content or remove the table generated by the XSLT filter for the cover. -- Thomas Mortagne

15 years, 3 months

9
16
0 0

Re: [xwiki-devs] [Idea] "Modern" skin for "modern" browsers

by Jerome Velociter

----- "Ecaterina Valica" <valicac(a)gmail.com> wrote: > Hi, > > When the CSS3 fever began, Raluca Stavro came to me and asked me what > I > think about making a HTML5+CSS3 skin. My first answer was that is not > gonna > happen. We invest very much in making our skins have cross-browser > support > (especially old versions of IE). This is one of our strengths, but > also the > reason we limit ourselves from innovation. > > When I'm talking about a "modern" skin I'm not only referring about > HTML, > JS, CSS (having transparency, corners, multiple backgrounds, shadows > without > having to triple the code and the number of hacks), but it's about > all > cool/experimentation features, that boosts productivity, minimize > code > lines, etc. but lack all/old browser support (SVG, location awareness, > CSS3 > calc etc). > > So, in my opinion this would be an experimentation/shiny skin that by > comparison would make old browsers supporters and lovers to quit their > old > behaviors and embrace the future :) :p > > So, the questions I have are: > > 1) would this be possible? would anyone want to do this sort of thing? > I > know the biggest problem is gonna be the maintenance, but could bring > lots > of innovation and productivity. For lot of cases (that is at least everything that includes JS, and maybe more) we should be able to add such new features on top of the existing UI, i.e. without the need to create a dedicated skin. Take for example attachment Drag & Drop in the attachment footer tab. We just detect the feature and offer it if supported (do nothing if not). > > 2) what feature/improvement/thing do you think it would be the most > needed > for a new "modern" "skin" (the topic somehow go beyond the skin > boundaries)? Right now I think of - attachments D&D - upload with progress bar - growl-like client notifications (w/ WebSocket) - local drafts (with localStorage) - a profile picture sizing/cropping tool using canvas - ... I'm sure a lot more :) Jerome. > > Thanks, > Caty > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

15 years, 3 months

1
0
0 0

[xwiki-devs] [VOTE] Apply code style to imports

by Denis Gervalle

Hi Devs, Currently we do not have any code style specification for imports. To improve clarity of our commits, I propose that we decide once for all how we would like to have imports. Of course, normalisation of existing code will come with normal commit, I do not intend to update it only for that. Currently, Eclipse does java.*, org.*, com.* separated by blank lines IntelliJ IDEA does com.*,org.* together, than a blank line and java.* Old existing code has there own ordering... I propose the following style: import java.* import org.* import com.* import <anything else> import org.xwiki.* import com.xpn.* import static <any> If we agree on this, necessary IDE setup for both Eclipse and IntelliJ should be prepare/updated. I will take IntelliJ in charge, a volunteer for Eclipse is welcome (Thomas?) WDYT ? Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

15 years, 3 months

6
10
0 0

Re: [xwiki-devs] [xwiki-notifications] r29596 - platform/web/trunk/standard/src/main/webapp/resources/js/prototype

by Vincent Massol

On Jun 21, 2010, at 10:24 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-06-21 10:24:46 +0200 (Mon, 21 Jun 2010) > New Revision: 29596 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js > Log: > XWIKI-4183: Improve page load speeds via parallel JavaScript download > Fixed most race condition failures occuring in IE > > Modified: platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js 2010-06-21 08:24:35 UTC (rev 29595) > +++ platform/web/trunk/standard/src/main/webapp/resources/js/prototype/prototype.js 2010-06-21 08:24:46 UTC (rev 29596) > @@ -4687,8 +4687,11 @@ > document.addEventListener('DOMContentLoaded', fireContentLoadedEvent, false); > } else { > document.observe('readystatechange', checkReadyState); > + // Disabled in XWiki since it conflicts with defered scripts > + /* > if (window == top) > timer = pollDoScroll.defer(); > + */ So we'll loose this change (ie we'll have to remember it) when we upgrade to a new version of prototype? Thanks -Vincent

15 years, 3 months

3
3
0 0

Re: [xwiki-devs] Gadgets & Dashboard roadmap

by Jerome Velociter

----- "Anca Luca" <lucaa(a)xwiki.com> wrote: > Hi all, > > I am now restarting the work on the gadgets & dashboard project, > documented here > http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration (however > > documentation needs to be slightly revised). > > What is done already can be summarized as: > * gadgets are implemented as macros and there is a script to import > google gadgets as xwiki macros, > * also, right now, gadgets are implemented as xwiki macros and can be > > used anywhere just like a regular wiki macro, and any wiki macro can > be > seen/used as a gadget so **there is no difference between macros and > gadgets** . WDYT about this? should we keep it like that? (A) If I understand correctly, it means XWiki will not be an OpenSocial container, but will provide a "conversion" layer to make OpenSocial gadgets work with the XWiki gadget (= macros) system. I'm not sure it's the proper approach. It will not encourage developers of XWiki application / macros etc. to write their gadgets as OpenSocial gadgets, since writing XWiki macros will be enough (so it will not be possible to display a XWiki gadget in say JIRA). Plus, if we make XWiki an OpenSocial container, it does not prevent us from writing a generic XWiki gadget that can wrap any macro thus not adding too much weight on developers. Jerome. > * there is a dashboard macro responsible with layouting a gadgets > dashboard, which also provides specific editing features in inline > mode > (gadgets can be dragged around, toolboxes for gadgets in the top > right) > * there is a minimal macros directory, where one can see all the > existing macros, descriptions, details about the parameters. > * there is an PanelMacro macro, that displays an xwiki panel inside a > > document, which can be used to display xwiki panels as gadgets in a > dashboard. > > The big picture of the roadmap is that we should: > > 1/ have a fully working dashboard, that is implement add gadget and > edit > gadget settings > 2/ implement the main dashboard (Main.Dashboard) as a dashboard and > fill > it with the appropriate gadgets by default, and also to add a user > specific dashboard ("My dashboard") where each user can configure > his/her dashboard, and is available to a user from his / her profile > or > the user menu > 3/ have a nice macros directory where a user can navigate through > existing gadgets and add one to a dashboard > 4/ have a "dashboard template", integrated with the document templates > > system to easily allow a user to create a dashboard > 5/ also, since the xwiki panels can be seen as gadgets / macros, and > can > be implemented as such, somewhere in the future a refactoring should > be > made to integrate the 2 notions > 6/ be able to publish the gadgets in the wiki such that other apps can > > integrate this in their content > > WDYT about the order above? (B) with the mention that points 5 and 6 > could eventually be infinitely postponed. > > Also, after points 1 and 2 are implemented, the feature could be > available with xwiki platform and integrated in XE by default. WDYT? > (C) > > my +1 for (A), (B) and (C). > > Happy hacking, > Anca > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs

15 years, 3 months

1
0
0 0

[xwiki-devs] [Proposal] Changing the RightService API

by Andreas Jonsson

I will make two proposals for changing the RightService API: The first does not actually change any code, but it is a preparation for future changes. I want to be sure that the methods checkAccess and hasAccessLevel aren't used interchangeably; it should be well defined when to use one or the other. The second proposal is a complete rework of the API, which might be a bit further into the future. 1. Change the semantics of hasAccessLevel slightly. Currently the method hasAccessLevel is defined as: /** * Verifies if the user identified by {@code username} has the * access level identified by {@code right} on the document with * the name {@code docname}. I would like to make a change the describing text into: /** * Decides whether the access level given by {@code right} should * be granted during rendering of the document identified by * {@code docname} by request of the user identified by {@code * username}. In other words, the rights queried for is tied to the thread executing a request on behalf of the user. In contrast, the checkAccess method queries for the configured rights of a particular user. This suggests that the underlying implementation may choose to base its decision on more things than the given user and document, and thus opens up for more possibilities to change the security policy. For instance, hasAccessLevel("programming", context.getUser(), docname, context) could be made equivalent to hasProgrammingRights(context.getWiki().getDocument(docname), context) In the current implementation, XWikiRightServiceImpl, the methods checkAccess and hasAccessLevel can be used interchangeably once the user have been authenticated. But it seems that the current usage pattern more or less matches the above change in semantics already. 2. Deprecate all methods in the current API and introduce the following new ones: boolean checkAccess(String action, EntityReference entity); boolean userHasRight(DocumentReference userIdentity, Right right, EntityReference entity); boolean hasAccessLevel(Right right); Iterable<Right> getEnabledRights(EntityType entityType); The differences are: 1. The context parameter is dropped. The right service can have an Execution instance injected instead. 2. No exceptions are thrown. Instead, on error, log and deny access. 3. Identify users by the DocumentReference of their profile page. 4. Introduction of the enum 'Right'. 5. The rights are controlled against entities identified by EntityReferences that may be of type WIKI, SPACE or DOCUMENT. 6. Add a new method, userHasRight, for querying for the specific rights of a given user on a given entity, where the entity may be wiki, space or document. This method replaces the method hasAdminRights. I guess this method will be primarily used by the user interface. 7. hasAccessLevel have the same change in semantics as mentioned above, and could thus replace the hasProgrammingRights methods. In other words, hasAccessLevel provides the answer to the question "should access for an operation that requires the specified right be granted given the current context?" Within the lifecycle of a request, first a call should be made to checkAccess to authenticate the user and to grant access to the specific action. Subsequent security checkpoinst should normally use hasAccessLevel. 8. The listAllLevels-method is moved to the Right enum class. The right service could instead provide a method that lists what rights are enabled at a particular level in the document hierarchy, i.e., the getEnabledRights method, which I guess is relevant for the rights manager. So, what do you think? Best regards, Andreas Jonsson

15 years, 3 months

2
2
0 0

[xwiki-devs] [Proposal] Why don't we use XWQL and the Query Manager + ScriptService

by Vincent Massol

Hi devs, I'm wondering why we haven't moved to using XQL instead of HQL. Any reason? If not, I'd like to suggest we start using it everywhere we currently use HQL since XWQL since is much nicer. Also since we don't use it our users don't use it. Additionally I'd like to propose that we move to a ScriptService to access the query manager. From Velocity you'd write the following to get a Query: $services.query.xwql("....") Note that the ScriptService implementation would replace the SecureQueryManager implementation. We would also deprecate XWiki.getQueryManager. WDYT? Thanks -Vincent

15 years, 3 months

5
11
0 0

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

by Vincent Massol

On Jun 21, 2010, at 9:28 AM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2010-06-21 09:28:46 +0200 (Mon, 21 Jun 2010) > New Revision: 29588 > > Modified: > platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java > Log: > [cleanup] Updated deprecated method call > > Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java > =================================================================== > --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java 2010-06-21 07:28:40 UTC (rev 29587) > +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/web/Utils.java 2010-06-21 07:28:46 UTC (rev 29588) > @@ -65,8 +65,8 @@ > Utils.class.getCanonicalName() + "_placeholders_enabled"; > > /** > - * The component manager used by {@link #getComponent(Class)} and {@link #getComponent(Class, String)}. It is > - * useful for any non component code that need to initialize/access components. > + * The component manager used by {@link #getComponent(Class)} and {@link #getComponent(Class, String)}. It is useful > + * for any non component code that need to initialize/access components. > */ > private static ComponentManager componentManager; > > @@ -150,7 +150,7 @@ > // the content is fully rendered. The rendering code can use Utils.createPlaceholder. > // Initialize the placeholder map > enablePlaceholders(context); > - String content; > + String content = ""; > try { > content = context.getWiki().evaluateTemplate(template + ".vm", context); > // Replace all placeholders with the protected values > @@ -163,8 +163,12 @@ > } > > // get Error template "This template does not exist > - content = context.getWiki().parseTemplate("templatedoesnotexist.vm", context); > - content = content.trim(); > + try { > + content = context.getWiki().evaluateTemplate("templatedoesnotexist.vm", context); > + content = content.trim(); > + } catch (IOException ex) { > + // Cannot write output, can't do anything else Shouldn't we log a warning/error? Thanks -Vincent

15 years, 3 months

2
2
0 0

Re: [xwiki-devs] [xwiki-users] Templates Provider

by Guillaume Lerouge

Hi, On Mon, Jun 21, 2010 at 10:04, Adriana Escamilla Alvarado < adriana.escamilla.alvarado(a)gmail.com> wrote: > Hello guys, I want to tell u first that all of XWiki is awesome °¬° (and > the developers too =D ) > > But, I need to know when you (you mean XWiki org) are going to liberate > the XEnterprise 2.4M2, I need... really I need the Templates Pages =( > this is the URL if u doest'n know what I mean > http://code.xwiki.org/xwiki/bin/view/Applications/AdministrationApplication > in the sub-section "Easy Templates Creation and Administration (Starting > with XWiki Enterprise 2.4M2)" ... > > Maybe I'm wrong and this is a User-Application maybe not, but I want to > know if this "templates" are going to be in the Milestone 2, if not, > then tell me if that "Templates" are a User-Application (and if u can > tell me how to make it please =( ) > Templates are already available for testing. You can get a snapshot of the release here: http://maven.xwiki.org/snapshots/com/xpn/xwiki/products/xwiki-enterprise-we… Guillaume Also, I have a little problem with the Import of Documents in > OpenOfficeServer, I tried to set up a OOffice in a Linux Server, but i > cant to make it a service D=!!! I was looking for a tip of "How to make > OpenOffice a Service in Linux" and what i found doesnt work =(. My > server details are: > > - SO: OpenSuse 10, Server > - XWiki: Enterprise 2.3 > - OpenOffice: 3.2 > > If someone can help me please with this 2 Issues I'll be really happy. > Thank you for your time!!!! > > Adriana Escamilla Alvarado > Ing. Tecnologías Computacionales > Particular: (614) 260-0732 > Móvil: (614) 219-7213 > Contact Me Facebook > <http://www.facebook.com/#%21/adriana.escamilla.alvarado>Twitter > <http://twitter.com/Ing_Patito> > > --- @ WiseStamp Signature > < > http://my.wisestamp.com/link?u=6qp9k36s775m7jfq&site=www.wisestamp.com/emai… > >. > Get it now > < > http://my.wisestamp.com/link?u=6qp9k36s775m7jfq&site=www.wisestamp.com/emai… > > > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users

15 years, 3 months

1
0
0 0

[xwiki-devs] Support skin inheritence for file system skin

by Ludovic Dubost

Hi, I believe we need to implement skin inheritence for file system skins. We do have skin inheritence for skins stored in Wiki pages but we don't have it for FS skins. So we cannot have albatross <-> colibri <-> myskin <-> wiki page skin To implement this we could just use a file called "parent" which would contain the name of the parent skin. WDYT ? Ludovic -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

15 years, 3 months

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