Hi devs,
There are many things that could be improved in the XWiki
Administration, but for the moment I would like to discuss the
Presentation part, which is one of those most likely to be accessed by
newbies, and should be easy to deal with.
Currently, the Presentation allows to configure the following topics:
- Header: title bar text and meta information
- Panels: whether to show panels on the right/left, and the list of
panels to display in each column
- Footer: copyright notice and version
- Skin: Skin document, Color theme, Default stylesheet, other stylesheets
Problems:
- IMO, some fields are not really presentation related: title, meta
information, copyright notice, version info
- It is not easy to list the panels you want without any help or suggestion
- The panel columns and panel list configuration feature is also
available in a friendlier form in the Panel Wizard section of the
administration, but there is no reference to it from the Presentation
section
- There is no suggestion about available skins, and the user is not
"warned" that customizing the skin actually means changing templates and css
- "Default stylesheet" and "Other stylesheets" mean nothing to someone
who didn't look in the skin directory; also, as I see it, they are only
useful for the Toucan skin (where there were several pre-defined
stylesheets for different colors), while in the Colibri skin -- and
probably the other skins that will be developed from now on -- we use
Color themes for changing the look.
Proposed changes:
- Move Header and Footer topics to the General section
- Keep 4 topics: Page layout, Panels, Color theme, Advanced skin
configuration, displayed in a horizontal tab bar (like the one in AllDocs)
[Page layout]
- Use something similar to the Page Layout tab form the wizard to
choose if the right/left panels are shown
[Panels]
- Continue to allow listing the panels in input fields, since for
some users it is faster and easier than playing with the panel wizard,
but attach an AJAX suggest to those input fields
- Display the Panel wizard (and remove the panel wizard section form
Administration); Note: the panel wizard will need some adjustments for
this to be possible.
[Color themes]
- Integrate the ColorTheme "application" (or soon to be application):
allow browsing, previewing and selecting available color themes, and
creating a new color theme
[Advanced skin configuration]
- Inform the user that he would need to write his own templates and
stylesheets, either in the provided textareas or in files attached to
the corresponding skin object
- Allow to browse, preview and select skins
There are many changes, and they will require much more than a couple of
days (there won't be time for them to show up in 2.2, for example), but
if we agree, they can be progressively integrated in future versions.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi everyone!
I'm starting on a re-implementation of the LDAP implementation for XWiki, an implementation that performs upward sync instead of downward sync (updating LDAP instead of updating XWiki). This is for a unified platform we (a friend and myself) are working on where XWiki is the "master app".
After reading through (some of) the sources for xwiki-core, it seems to me the entire LDAP infrastructure is located in 2 packages: com.xpn.xwiki.plugins.ldap.* and com.xpn.user.impl.LDAP.*
Before I begin, I'd like to confirm this so I can focus exclusively on the code I need to re-implement and not have any surprise LDAP dependencies creep up later on. So, am I correct that these are the packages that need to be rewritten for upward sync?
Tanks!
Hi devs,
I'm almost done with my entity reference refactoring and I've just
realized I have missed something I think. So far the implementation
only supports Absolute references (i.e the entity reference factory
always return a reference with all parts filled - you choose to use a
default factory or a current entity depending on how you wish to
resolve the names when they have not been provided in the passed
reference string).
I now think we must also support relative references (i.e. when some
parts can be null) and that it's up to the user of the api to decide
if they want to convert a relative reference to an absolute one or not.
Here's a use case: renaming of documents. For exemple documents have
links specified as a string representing the target doc name. If we
don't have relative references then we need to decide if we want to
use the default serializer (all parts printed including wiki name) or
the compact serializer (only parts different from context reference
printed). This doesn't support printing only what the user had decided
to fill. For ex a user might have specified voluntarily the space and
page name and right now with my implementation he'll get only the page
name specified if the new space is the same as the space for the
current doc.
So here's my proposal:
* Entity Reference Factory leaves parts to null when not specified in
the string representation.
* We add a EntityReference.getAbsoluteReference(EntityReference base)
method to return an absolute reference. It's resolved against the
passed base reference (i.e. parts not specified are taken from it)
WDYT?
I'm going to start refactoring my code to do this later today so
please let me know if you see any pb with it.
Thanks
-Vincent
Hi
For the development of the Groovy based Blog I just developed the code in IntelliJ, copied inside a browser and eventually exported the content into a XAR file. Slowly but surely this is getting way to much work especially when doing sweeping changes.
Because I don't use Eclipse I am not able to use the XEclipse tool but I was wondering if anybody knows a way to XML encode text (within Maven2) so that it later could use Ant's copy and filter tool to incorporate the developed code / content inside the XML file that will build up the XAR file.
Thanks - Andy
Hi devs,
We need to define a strategy for better handling translations. I've
had a call with Guillaume and Jean-Vincent and here's the process we'd
like to propose:
* One person is in charge of http://l10n.xwiki.org/. This means
monitoring the work there, coordinating validation of key values and
ensuring validated translations are incorporated in the source tree.
Guillaume is willing to take that role for now.
* The XE release manager has the responsibility of taking the
validated keys on l10n.xwiki.org and committing them during the
Milestone 2 dev (before the RC1).
* The l10n manager should ping the release manager whenever there are
translated and validated keys ready to be incorporated or if there
have been important changes to be included in the release after M2 has
been released.
* The l10n manager should test XE and the applications after the keys
have been applied to ensure quality. Basically the l10n manager is
responsible for the quality of translations in general.
Here's my +1
Thanks
-Vincent