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
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!
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
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.
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
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
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
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