xwiki-devs December 2009

xwiki-devs@xwiki.org

32 participants
100 discussions

[xwiki-devs] Add currentPage to the XWiki object in javascript

by Anca Luca

Hi devs, right now we have 2 ways to get (some) information about the current document in javascript: * the meta tags (which store the page, the space, the wiki, version, etc) -- set in htmlheader.vm * the XWiki object set in xwiki.js and filled in with info in javascript.vm which contains currentWiki, mainWiki, currentSpace, action, etc, but *not* the currentPage. Between the two, I propose to use the second as the 'recommended' way to get information about XWiki in some javascript in a document (the action, the wiki, the space, etc) and, to make it complete, to add a currentPage to it. WDYT? Thanks, Anca

14 years, 8 months

[xwiki-devs] [Suggestion] separate interface language and page content language settings

by Zhaolin Feng

Hi, everyone: As discussed in XE-552 <http://jira.xwiki.org/jira/browse/XE-552>, Thomas Mortagne and I agreed that interface language and page content language are two unrelated dimensions. With the new Colibri skin in XE2.1, I think we are in a good position to seperate them. 1. Move the content language switcher from the site title bar to the page title bar. 2. In register page and personal profile page, add a "preferred language" setting. It's the interface language as well as the default content language. WDYT? I've created a suggestion in JIRA: http://jira.xwiki.org/jira/browse/XSCOLIBRI-169 -- -- Zhaolin Feng -- www.mapbar.com -- Currahee! We stand alone together!

14 years, 8 months

[xwiki-devs] [Proposal] Gadgets Integration

by Anamaria Stoica

Hi devs, I'd like to start working on Gadgets Integration. (this is a new feature) I've been working on the specs with Guillaume, and you can see the Design page here: http://dev.xwiki.org/xwiki/bin/view/Design/GadgetIntegration The aim of the gadget integration is to provide XWiki users with a dashboard-like page that will display a list of gadgets. These gadgets can be either internal gadgets (similar to XWiki panels) or external gadgets (coming from the Google Gadget repository for instance). Users can select which gadgets to display on their dashboard from a gadget directory located on the wiki. I've also created a few Mockups here http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GadgetsIntegration for the Dashboard, Gadget Windows and Gadgets Directory. List of features: Dashboard - Dashboard for each user with drag&drop for Gadget Windows - Display both Google Gadgets and XWiki Gadgets (Panels) Directory - An internal directory with Gadgets in the wiki divided in 3 parts: * XWiki Gadgets defined in the wiki / in the farm (current Panels) * Google Gadgets selected out of the global Google Directory by wiki admins * If allowed by wiki admins: full Google Gadgets Directory I'd like to include all of the above with basic functionalities into 2.2M1. One thing is not clear at this point >> The relationship between XWiki Gadgets and current Panels: They are basically the same thing (same content), but they will have different containers (drag&drop window with edit settings on Dashboard and present containers for the side menu Panels). Will all Panels make sense as XWiki Gadgets? If no, when a new Panel is created, how do you know it's meant to be only a side menu Panel and not also a XWikiGadget? (this applies for current Panels as well) Also, very important: where should the interface for the Gadgets Directory be placed? Appended to Panels.WebHome or new directory Gadgets.WebHome? In my opinion it needs a different interface from the Panel Wizard Interface. The Panel Wizard is in the Wiki Preferences (administration space) open only to Admins, but the Directory will have to be available to all users (even browsable by everyone). An admin interface for picking Google Gadgets from iGoogle Directory and/or XWiki Panels for the Gadgets Directory might be needed. How should I treat the 2 of them (XWiki Gadgets vs side menu Panels)? Thanks, Anamaria

14 years, 8 months

[xwiki-devs] Authentication with Active Directory

by Fabio Puglisi

Hi, I'm trying to configure my xwiki installation to authenticate users using Microsoft Active Directory. If I try to login the result is a continuous reload of the login page without error message. No error message in log files too. Our login standard use dot between First name and Last name (eg: fabio.puglisi), could be this a problem? Anyone can help me? Thanks Here my wiki.cfg #----------------------------------------------------------------------- -------------- # LDAP #----------------------------------------------------------------------- -------------- #-# new LDAP authentication service xwiki.authentication.authclass=com.xpn.xwiki.user.impl.LDAP.XWikiLDAPAut hServiceImpl #-# Turn LDAP authentication on - otherwise only XWiki authentication xwiki.authentication.ldap=1 #-# LDAP Server (Active Directory, eDirectory, OpenLDAP, etc.) xwiki.authentication.ldap.server=10.239.1.169 xwiki.authentication.ldap.port=389 #-# LDAP login, empty = anonymous access, otherwise specify full dn #-# {0} is replaced with the username, {1} with the password xwiki.authentication.ldap.bind_DN=ldaptest\\administrator xwiki.authentication.ldap.bind_pass=Password #-# Force to check password after LDAP connection #-# 0: disable #-# 1: enable xwiki.authentication.ldap.validate_password=0 #-# only members of the following group will be verified in the LDAP #-# otherwise only users that are found after searching starting from the base_DN xwiki.authentication.ldap.user_group=cn=Users #-# [Since 1.5RC1, XWikiLDAPAuthServiceImpl] #-# only users not member of the following group can autheticate # xwiki.authentication.ldap.exclude_group=cn=admin,ou=groups,o=MegaNova,c= US #-# base DN for searches xwiki.authentication.ldap.base_DN=dc=ldaptest,dc=semplatest,dc=local #-# Specifies the LDAP attribute containing the identifier to be used as the XWiki name (default=cn) xwiki.authentication.ldap.UID_attr=sAMAccountName #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# Specifies the LDAP attribute containing the password to be used "when xwiki.authentication.ldap.validate_password" is set to 1 xwiki.authentication.ldap.password_field=userPassword #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# The potential LDAP groups classes. Separated by commas. # xwiki.authentication.ldap.group_classes=group,groupOfNames,groupOfUnique Names,dynamicGroup,dynamicGroupAux,groupWiseDistributionList #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# The potential names of the LDAP groups fields containings the members. Separated by commas. xwiki.authentication.ldap.group_memberfields=member,uniqueMember #-# retrieve the following fields from LDAP and store them in the XWiki user object (xwiki-attribute=ldap-attribute) xwiki.authentication.ldap.fields_mapping=name=sAMAccountName,last_name=s n,first_name=givenName,fullname=displayName,email=mail,ldap_dn=dn #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# on every login update the mapped attributes from LDAP to XWiki otherwise this happens only once when the XWiki account is created. xwiki.authentication.ldap.update_user=1 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# mapps XWiki groups to LDAP groups, separator is "|" xwiki.authentication.ldap.group_mapping=XWiki.XWikiAdminGroup=cn=Adminis trators #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# time in s after which the list of members in a group is refreshed from LDAP (default=3600*6) # xwiki.authentication.ldap.groupcache_expiration=21800 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# - create : synchronize group membership only when the user is first created #-# - always: synchronize on every login xwiki.authentication.ldap.mode_group_sync=always #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# if ldap authentication fails for any reason, try XWiki DB authentication with the same credentials xwiki.authentication.ldap.trylocal=0 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# SSL connection to LDAP server #-# 0: normal #-# 1: SSL xwiki.authentication.ldap.ssl=0 #-# [Since 1.3M2, XWikiLDAPAuthServiceImpl] #-# The keystore file to use in SSL connection # xwiki.authentication.ldap.ssl.keystore= #-# [Since 1.5M1, XWikiLDAPAuthServiceImpl] #-# The java secure provider used in SSL connection # xwiki.authentication.ldap.ssl.secure_provider=com.sun.net.ssl.internal.s sl.Provider Le informazioni contenute in questo messaggio sono riservate e confidenziali ed e vietata le diffusione in qualunque modo eseguita. Qualora Lei non fosse la persona a cui il presente messaggio e destinato, La invitiamo ad eliminarlo e a non leggerlo, dandocene gentilmente comunicazione. Per qualsiasi informazione si prega di contattare (informazioni(a)sempla.it). Rif. D.L. 196/2003 This e-mail (including attachments) is intended only for the recipient(s) named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not the named recipient, please contact (informazioni(a)sempla.it) and delete the e-mail from your system. Rif. D.L. 196/2003.

14 years, 8 months

[xwiki-devs] OfficeImporter API changes - Take 2

by Asiri Rathnayake

Hello Devs, After few discussions I have revised the new officeimporter API to take into account the use of DocumentName instead of plain strings for representing document names. I'll repeat the details of the previous proposal with the new changes applied: Currently we have the following officeimporter API: <code> OfficeImporter::importStream(InputStream is, String documentFormat, String targetDocumentName, Map params):void OfficeImporter::importAttachment(String documentName, String attachmentName, Map params):String </code> Problems with this API: * Loosely typed (params, document names) * Both of the above methods perform almost the same task. * Customizing the import process is implemented in a hackish way. (not visisble on the API) The new API proposed looks like below: <code> OfficeImporter::officeToXHTML(byte[] officeFileData, DocumentName referenceDocument, boolean filterStyles):XHTMLOfficeDocument OfficeImporter::xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument):XDOMOfficeDocument OfficeImporter::officeToXDOM(byte[] officeFileData, DocumentName referenceDocument, boolean filterStyles):XDOMOfficeDocument OfficeImporter::buildPresentation(byte[] officeFileData):XDOMOfficeDocument OfficeImporter::splitImport(XDOMOfficeDocument xdomOfficeDocument, int[] headingLevelsToSplit, NamingCriterion namingCriterion, DocumentName baseDocumentName):Map<TargetPageDescriptor, XDOMOfficeDocument> </code> As you can see, these methods are more granular and the responsibilities are well defined. Customizing the import process can be done from the client code. For an example: 1. Make the initial import from office to XHTMLOfficeDocument - OfficeImporter::officeToXHTML() 2. Perform customizations on the XHTMLOfficeDocument - w3c DOM manipulations. 3. Import the XHTMLOfficeDocument into XDOMOfficeDocument - OfficeImporter::xhtmlToXDOM() 4. Perform customizations on the XDOMOfficeDocument (XDOM) - XDOM manipulations. 5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances - OfficeImporter::splitImport() 6. Perform customizations on these child XDOMOfficeDocument instances - XDOM manipulations. 7. Render the XDOMOfficeDocument instances & save them into wiki pages - XWiki rendering operations. I think this interface will make it easy to extend & maintain officeimporter functionality in the future. Along with this, I would also like to refactor the xwiki-refactoring module a bit to get rid of string based document names from it. This whole refactoring operation would take approximately one day to complete. And since this operation is not adding any new features, I think it can be committed on both trunk and 2.0 branch. Here's my +1 to all of above. Thanks. - Asiri

14 years, 8 months

[xwiki-devs] [Proposal] Resource vs Item vs ItemResource vs Model & Name vs Path vs Reference

by Vincent Massol

Hi devs, We need to decide if we want to keep the current: ResourceName, DocumentName, SpaceName, WikiName, AttachmentName or instead use a variation. There are 2 things to decide: - The prefix for the base object (Resource, Item, Model, etc) - The suffix (Name, Path, Reference, etc) Proposal ======= I'd like to propose ModelReference for the base object and then DocumentReference, SpaceReference, WikiReference, AttachmentReference. Note: This is different from Identity which is unique (a UUID). References do not point to unique objects. Reference makes sense to me since it means what it means... :) For example the API: Document getDocument(DocumentReference) is pretty clear IMO. Path is too physical to me. In JCR it's called getPath() but it returns a string with a path, for ex "/wiki/space1/space2/document". This is not our case. IMO our Reference would transform into a path when serialized only. Name isn't too bad, it would be my second choice. But it doesn't show the fact that it's a ... reference... ;) WDYT? Thanks -Vincent

14 years, 8 months

[xwiki-devs] [Proposal][Model] ResourceName refactoring

by Vincent Massol

Hi, I'd like to propose a refactoring for org.xwiki.model.DocumentName/ AttachmentName. There are currently 2 problems with the current implementation: - DocumentName doesn't support nested spaces (we need that for the future) - We need to generalize the concept of resource names so that we can use the generic concept in the Model in some APIs Thus I'd like to propose: enum ResourceType - WIKI, DOCUMENT, SPACE, ATTACHMENT ResourceName - ResourceName(String name, ResourceName parent) - get/setName() - get/setParent(ResourceName) - get/setType(ResourceType) DocumentName extends ResourceName - DocumentName(String pageName, SpaceName parent) AttachmentName extends ResourceName - AttachmentName(String fileName, DocumentName parent) WikiName extends ResourceName - WikiName(String wikiName) SpaceName extends ResourceName - SpaceName(String spaceName, SpaceName parent) - SpaceName(String spaceName, WikiName parent) Open questions and comments ======================== - Should we replace "Name" by "Reference", i.e. DocumentReference instead of DocumentName, WikiReference instead of WikiName? - Note: A name (or reference) isn't resistant to change. Resources (Document, Space, Wiki, etc) must also have an Identifier (unique id) to uniquely identify them. For example a Document can be moved from one space to another (the DocumentName changes in this case). - The scheme above allows to map this easily to the JCR API - Do we want helper methods for locating the wiki in which a DocumentName is? That would mean adding: WikiName DocumentName.getWiki() (algo: getParent() till getType == WIKI or null) Same question for getting the last Space or Wiki from AttachmentName - Do we want a helper constructor to make it easier to create a DocumentName? With the proposal above it means: new DocumentName("page", new SpaceName("space", new WikiName("wiki"))); A helper constructor could be: DocumentName(String page, String space, String wiki). Problems: a) we would need another constructor to support a list of spaces and b) if there are fields other than the name to set on ResourceNames later on, it's not going to work as smoothly) Factory and Serializer ================= This is a big question I haven't yet solved. We have 2 options: 1) have specialized Factory/Serializer. For ex: DocumentNameFactory, DocumentNameSerializer 2) have generic ones: ResourceNameFactory/ResourceNameSerializer 2) seems nicer initially but the problem with 2) is that we need a global String representation of any resource in the system. There are 2 problems with that: - we may not want that. For example when the user is asked to enter a document name in a field, we may not need/want to parse this as a general resource that could for example point to an attachment (and btw as a consequence allow entering "@" which is our separator for attachments) - it's very hard to add new Resource types later on (since we'd need more special characters to separate them and this means these chars wouldn't be allowed in names for pages for ex) The other option is to have 2) but with the type passed as parameter: ResourceName ResourceNameFactory.create(String stringRepresentation, ResourceType) However this simply means that ResourceNameFactory would be a factory for actual factories (DocumentNameFactory, AttachmentNameFactory, etc) so I don't really see the added value in our component-based world (we can look up the right factory directly). Thus IMO we want 1). WDYT? Thanks -Vincent

14 years, 8 months

Re: [xwiki-devs] [xwiki-notifications] r25832 - in platform: core/trunk/xwiki-core/src/main/resources xwiki-applications/trunk/panels/src/main/resources/Panels

by Jean-Vincent Drean

The fact that it uses translations with the panels.* prefix is wrong, we need to use a core.search.* (or platform.search.* ?) prefix for the text in the header. About the label itself having a voice reader reading "search query" to describe the input is better than "search", WDYT ? Any other opinions about this ? I'll commit the fixes when we'll find an agreement. Thanks, JV. On Thu, Dec 17, 2009 at 11:39 AM, Ecaterina Valica <valicac(a)gmail.com> wrote: > The Search label in the global.vm uses panels.search.inputLabel > > <label class="hidden" > for="headerglobalsearchinput">$msg.get('panels.search.inputLabel')</label> > > > On Thu, Dec 17, 2009 at 12:08, jvdrean <platform-notifications(a)xwiki.org> > wrote: >> >> Author: jvdrean >> Date: 2009-12-17 11:08:18 +0100 (Thu, 17 Dec 2009) >> New Revision: 25832 >> >> Modified: >> >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> Log: >> XAPANELS-106 : Missing label for search input field in Panels.Search >> >> + removed tag object >> >> Modified: >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> =================================================================== >> --- >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> 2009-12-17 09:58:26 UTC (rev 25831) >> +++ >> platform/core/trunk/xwiki-core/src/main/resources/ApplicationResources.properties >> 2009-12-17 10:08:18 UTC (rev 25832) >> @@ -919,6 +919,7 @@ >> panels.translation.existingTranslations=Existing translations: >> >> panels.search.title=Search >> +panels.search.query=Search query >> panels.search.inputLabel=Search >> panels.search.inputText=search... >> panels.search.submit=Go >> >> Modified: >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> =================================================================== >> --- >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> 2009-12-17 09:58:26 UTC (rev 25831) >> +++ >> platform/xwiki-applications/trunk/panels/src/main/resources/Panels/Search.xml >> 2009-12-17 10:08:18 UTC (rev 25832) >> @@ -22,39 +22,6 @@ >> <comment></comment> >> <object> >> <class> >> -<name>XWiki.TagClass</name> >> -<customClass></customClass> >> -<customMapping></customMapping> >> -<defaultViewSheet></defaultViewSheet> >> -<defaultEditSheet></defaultEditSheet> >> -<defaultWeb></defaultWeb> >> -<nameField></nameField> >> -<validationScript></validationScript> >> -<tags> >> -<name>tags</name> >> -<prettyName>Tags</prettyName> >> -<unmodifiable>0</unmodifiable> >> -<relationalStorage>1</relationalStorage> >> -<displayType>input</displayType> >> -<multiSelect>1</multiSelect> >> -<size>30</size> >> -<separator> </separator> >> -<cache>0</cache> >> -<separators> ,|</separators> >> -<values></values> >> -<number>1</number> >> -<classType>com.xpn.xwiki.objects.classes.StaticListClass</classType> >> -</tags> >> -</class> >> -<name>Panels.Search</name> >> -<number>0</number> >> -<className>XWiki.TagClass</className> >> -<property> >> -<tags/> >> -</property> >> -</object> >> -<object> >> -<class> >> <name>Panels.PanelClass</name> >> <customClass></customClass> >> <customMapping></customMapping> >> @@ -138,7 +105,8 @@ >> <content>#panelhiddenheader($msg.get("panels.search.title")) >> <form action="$xwiki.getURL('Main.WebSearch')"> >> <div class="globalsearch"> >> - <input class="globalsearchinput" type="text" name="text" >> value="$msg.get('panels.search.inputText')" size="15" onfocus="if >> (this.value == '$msg.get('panels.search.inputText')') value=''; >> this.select();" onblur="if (this.value == '') >> value='$msg.get('panels.search.inputText')'; this.blur()"/> >> + <label for="globalsearchinput" >> class="hidden">$msg.get('panels.search.query')</label> >> + <input id="globalsearchinput" class="globalsearchinput" >> type="text" name="text" value="$msg.get('panels.search.inputText')" >> size="15" onfocus="if (this.value == '$msg.get('panels.search.inputText')') >> value=''; this.select();" onblur="if (this.value == '') >> value='$msg.get('panels.search.inputText')'; this.blur()"/> >> &nbsp; >> <input class="button" value="$msg.get('panels.search.submit')" >> type="image" src="$xwiki.getSkinFile('go.png')" >> alt="$msg.get('panels.search.submit')"/> >> </div> >> >> _______________________________________________ >> notifications mailing list >> notifications(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/notifications > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications > >

14 years, 8 months

[xwiki-devs] Update XWiki Hall Of Fame

by Marius Dumitru Florea

Hi devs, I just looked at the XWiki Hall of Fame ( http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame ) and I think it is a bit outdated. 1) I think we should make Artem Melentev and Stéphane Laurière emeritus committers since they haven't been active for a long time now. 2) I was surprised to see that Eduard is not listed among the XEclipse committers. 3) I think we should add Caty to http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame#HOthers ("Others" sounds bad though; we should find a better name for this category of special contributors). Caty has worked on improving the UI and UX of XWiki Enterprise. She also helped improving the XWatch UI one year ago when she participated in the GSoC program. 4) I think we should add to the list of Contributors: Oana Tabaranu * http://code.xwiki.org/xwiki/bin/view/Macros/Video20Macro * http://code.xwiki.org/xwiki/bin/view/Applications/BulletinBoardApplication * http://code.xwiki.org/xwiki/bin/view/Applications/LightboxApplication * http://code.xwiki.org/xwiki/bin/view/Applications/WatchListLayoutApplication Thibaut Deveraux for his participation to the UI/UX related discussions on the XWiki mailing lists and Raluca Stavro for her contribution to XWiki Workspaces, Rating Application (on sandbox right now) and, recently, Colibri skin. Thanks, Marius

14 years, 8 months

[xwiki-devs] [Proposal] Use a modifier key with click to collapse/expand macros inside the WYSIWYG editor

by Marius Dumitru Florea

Hi devs, Currently we have this behavior: * simple click to select a macro * simple click to toggle between collapsed and expanded state of a previously selected macro * double click to edit the macro properties The problem is that the double click event consists, as its name suggests, in two consecutive click events. As a consequence, when you double click to edit a macro you also toggle its visibility state. Besides being annoying, this can lead sometimes to an unexpected result: ----- <details> ----- I inserted a really long code macro (paste an entire Java source file). and them selected the macro and double clicked somewhere in the middle to edit its properties. This is what happened: * The first click event collapsed the macro * The second click event was not fired on the macro but on document body, because after the macro collapsed the place where I clicked was in the middle of nowhere. As a result the macro was unselected. * the (logical) double click event was still fired on the macro (I guess because the target of the first click was the macro container) and thus the edit macro dialog opened * I changed the macro properties and closed the dialog. As a result the macro was duplicated. The edit dialog should have replaced the selected macro but there was no selected macro.. ----- </details> ----- Therefore I propose to use a modifier key with click to collapse/expand a macro. I'm not sure which modifier key is the best. I think we should choose between Alt and Meta. The behavior would become: * simple click to select a macro * [Alt or Meta] + simple click to toggle the collapsed and expanded state * double click to edit I'm +1 for Alt key. WDYT? Thanks, Marius

14 years, 8 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs December 2009