Hi Devs,
Inspired by the newly launched W3C website, I'd like to introduce the
possibility to choose the display mode: desktop (the current UI),
print (the current print preview UI) and mobile (a 1-column,
margin-free layout). I'd like to group these options in a new action
menu entry, named DISPLAY (or VIEW) and placed between EDIT and EXPORT
(I can't find a good position, suggestions welcome). In the same menu
we can reintroduce the View Wiki Source feature (
http://jira.xwiki.org/jira/browse/XSCOLIBRI-122 ).
So basically, the menu changes are:
- new DISPLAY menu, with the options: Desktop, Mobile, Print, Wiki Source
- the chosen display mode (except wiki source) is sticky, meaning that
it will continue to be used for the following page views
- Print Preview disappears from ACTIONS
Any objections/comments?
--
http://purl.org/net/sergiu
The XWiki development team is (not so) pleased to announce the release
of XWiki Enterprise Manager 2.0.1.1.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This release fix one critical bug found in XWiki Enterprise Manager 2.0.1.
* XAWM-106 - NullPointer Exception on WikiManager.CreateNewWiki page
For more information see the Release notes at
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM2011.
Thanks
-The XWiki dev team
On 10/14/2009 06:59 PM, notifications(a)xwiki.org wrote:
> Hello Developers,
>
> This message is sent by XWiki. Here are the documents in your watchlist
> that have been modified since the last notification:
> XWiki.flavius
>
>
> Between 2009/10/12 15:15 and 2009/10/12 15:17, the document has
> been modified 2 times, by 2 user(s): Flavius Olaru, Jerome Velociter
>
> XWiki.XWikiUsers
> password:
> hash:SHA-512:ee26b0dd4af7e749aa1a8ee3c10ae9923f618980772e473f8819a5d4940e0db27ac185f8a0e1d5f84f88bc887fd67b143732c304cc5fa9ad8e6f57f50028a8ffhash:SHA-512:01ee4ab961b2f3f35fce8412d7facc44cd68782ed1b1810e849f21420583df04bee183d2b740d33417584e14fbc0dfc9d6232d2ce814012146840a69fdb2f31f
> author: XWiki.jvelociter > XWiki.flavius
^^^
This is not right.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi Devs,
This time I'm looking for an experienced XWiki developer in Spain :-)
Ideally I'm looking for a Web / Java developer who speaks both Spanish and
(English OR French) fluently and would be interested in a consulting gig
working on XWiki.
Any pointers?
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
On 10/12/2009 03:48 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-10-12 15:48:22 +0200 (Mon, 12 Oct 2009)
> New Revision: 24360
>
> Modified:
> platform/core/trunk/xwiki-cache/xwiki-cache-jbosscache/src/main/java/org/xwiki/cache/jbosscache/internal/JBossCacheCacheConfiguration.java
> Log:
> XWIKI-4452: Upgrade to last JbossCache 3.x version
> * fix maximum time to live new handling in LRU (used to be 0 for infinite, it's now -1)
Isn't there a constant that can be used instead of a direct number?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
Following our roadmap definition (now on http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap)
here are some date proposals for XE 2.1:
* 2.1 M1: 26 Oct (that's 4 weeks after the 2.0 release)
* 2.1 M2: 16 Nov
* 2.1 RC1: 30 Nov
* 2.1 Final: 7 Dec
Here's my +1 to commit to this schedule.
Note that I propose a not too long release (2 months and 2 weeks)
since 2.1 is meant to be a stabilization release with not many new
things. The new things should be for 2.2 in 2010.
Thanks
-Vincent
Hi Devs,
I've been refactoring OfficeImporter code base to make it more modular and
maintainable. With these refactorings I believe we can improve the main
OfficeImporter API. Currently OfficeImporter component interface exposes
following two methods:
<code>
void importStream(InputStream documentStream, String documentFormat, String
targetWikiDocument, Map<String, String> params) throws
OfficeImporterException;
String importAttachment(String documentName, String attachmentName,
Map<String, String> params) throws OfficeImporterException;
</code>
Problems with these two methods are;
* Loosely typed (params)
* Both of them perform almost the same task.
There is also a problem with how customizations to the normal import process
is implemented.
So, I propose we deprecate these two methods and introduce following
methods:
<code>
XHTMLOfficeDocument officeToXHTML(byte[] officeFileData, String
referenceDocument, boolean filterStyles) throws OfficeImporterException;
XDOMOfficeDocument xhtmlToXDOM(XHTMLOfficeDocument xhtmlOfficeDocument)
throws OfficeImporterException;
XDOMOfficeDocument officeToXDOM(byte[] officeFileData, String
referenceDocument, boolean filterStyles) throws OfficeImporterException;
XDOMOfficeDocument buildPresentation(byte[] officeFileData) throws
OfficeImporterException;
Map<TargetPageDescriptor, XDOMOfficeDocument> splitXDOM(XDOMOfficeDocument
xdomOfficeDocument, int[] headingLevelsToSplit, String namingCriterionHint,
String baseDocumentName) throws OfficeImporterException;
</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.
2. Perform customizations on the XHTMLOfficeDocument (w3c DOM).
3. Import the XHTMLOfficeDocument into XDOMOfficeDocument.
4. Perform customizations on the XDOMOfficeDocument (XDOM).
5. Split the XDOMOfficeDocument into multiple XDOMOfficeDocument instances.
6. Perform customizations on these child XDOMOfficeDocument instances.
7. Render the XDOMOfficeDocument instances & save them into wiki pages.
(saving can be done in client code)
I think this interface will make it easy to extend & maintain officeimporter
functionality in the future. For an example, a preview function can be
implemented with above methods (which is not possible with the previous
interface).
WDYT?
Here's my +1.
Thanks.
- Asiri